Hi y'all,

I posted this here, because I don't believe it's version specific. Perhaps even trivial, but worthy of a discussion.

I noticed that on a form with inline field specific validation errors, each one is displayed with a bullet for a prefix. like this...
● The event name field is required.

The bullet is a hardcoded Unicode geometric shape, value = &#9679.
Reference: engine / tg_helpers / form_helpers.php line 612.


I would prefer to alter the bullet code to this value: 🞫

I proved that by replacing the Unicode on line 612 with a constant,
VALIDATION_ERRORS_BULLET, defined it on the config/config.php as such...

that I could set that bullet to whatever Unicode value that I want it to be.

Additionally, I didn't think such values belong in the config/config.php file; and so I moved it to a file that I defined... config/custom_config.php and added it to the list of "require_once" config files in the "engine/ignition.php" file.

Seems like a faff to go thru for a trivial modification, but chances are that this approach would work in other instance where a developer should be given choices. Can any one think of other situations where hardcode is not the answer?
However, unless there is consensus, such a change would not last past the next engine update. :)

Ciao for now,
Charles

This is the kind of thing where adding bullets with CSS would be preferable as it's more of a stylistic choice to have them there. Then it's very easy to customise your choice of bullet style.

+1 CodeMonkey.
Using CSS to define the content of list-item is a common solution. Probably Simplest right now.

I think it could be taken a step further, by delegating the values of $error_str to a template.

That way the developer can easily override any of the error partials in the templates module

Apologies for misremembering disc as bullet, I wrote it on phone while shopping with fiancé.

You can get the same as the current html entity using ::before pseudo selector

Here you go DC:

https://code.monkeys.ooo/trongate-validation-demo.html

Includes a range of bullet styles and CSS for both existing <div> based strings as well as unordered lists as per sasin91's example (which would be a more semantically correct way of doing it as soon as you have more than one validation error).

Also note the use of role="alert" for assistive technology in the example PHP code. You could change this for aria-live="polite" if you want the errors announced but without interrupting users mid-typing.

You can also use flexbox

Re: list vs not a list.

It's the kind of nuance that you could argue either way when there's only a single validation failure to alert the user to. Either would make sense semantically (a single input could potentially have more than one validation failure so a single list item isn't necessarily wrong), and CSS can make them visually indistinguishable.

Perhaps the deciding factor is whether to code for one version that can be used in all situations, or have multiple types? That would probably make me lean towards an unordered list.

Hey DC,

Heads up on the way I did the benchmarks (assume NinjaBalazs did the same)

A fresh install of Trongate v2 with only `BASE_URL` configured and the test run against the default app means no custom pages or validation logic were executed. As a result, any changes suggested by codemonkey or sasin91 would not be reflected in those benchmark results that measured average requests per second.

Another way to correctly measure page load time, timing must start as early as possible - specifically when index.php is first executed via .htaccess.

1. in index.php2. In the view you want to measure (e.g. welcome.php):
With the app in its default state, this measurement will be effectively near zero, which is expected and does not represent real-world performance once routing, validation, database access, or custom modules are involved.

You could even add timing to certain parts of the page lifecycle to measure each level of the framework.

Re benchmark testing: it wouldn't ordinarily include stylesheet loading (unless your styles were embedded in the HTML in a <style> element).

OPcache means that small additions to existing files have no measurable impact unless they're actually being used in the code path. With OPcache, PHP files are not repeatedly loaded and compiled; instead, their compiled opcode arrays are stored in shared memory and executed directly, with only the relevant execution paths run at request time.

But obviously OPcache isn't a miracle worker. OPcache removes the parsing/compilation cost, but it doesn’t make the execution of your PHP logic free. If your request forces PHP to walk through hundreds of tiny “clean code” methods, that execution overhead is still very real.

OPcache accelerates startup cost, not runtime cost.

That's where Trongate shines: an ultra lightweight path from request start to end.

So don't let concern over benchmarks hold back genuinely useful additions that don't actually impact performance.

Not saying that the above is or isn't useful - just that it's something to be aware of in the future.