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

The answer is “yes”. I can think of plenty of situations where hard-coded values aren’t ideal and where a configuration file makes perfect sense.

The trouble is that, once you go down the “config file for everything” route, you quickly end up with something that looks suspiciously like Symfony.

We’re trying to build something that’s fast, stable and easy to learn. Personally, I struggle to get excited about “a config file for everything”. It feels unnecessarily heavy and, frankly, a little uninspiring. Even if you make all of the configs optional, you end up with a framework that's loaded with IF statements. It's all just... kinda rubbish, isn't it?

Rather than present people with a configuration file that’s two miles long, I’d much rather show them how to build their own modules. In that world, they can structure validation and behaviour exactly how they like, without wading through endless settings.

Now, on a slightly different note.

Unless I’m mistaken, you come from a COBOL background. That’s no small thing. It means you understand the infrastructure that quietly powers much of the world’s economy. Those are serious, battle-tested engineering skills, and they’re still incredibly valuable.

I’m not suggesting you go back to COBOL. I’m simply saying that, with a background like that, your time and talent are worth more than getting bogged down in minor validation details. I think you’re capable of tackling much bigger, more interesting problems.

So, while I’m going to pass on this particular idea, I say that with respect. I know you’re capable of far more ambitious thinking.

I just want to positively encourage people to aim for the stars - to tackle problems that make jaws drop.

DC

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

Codemonkey - Can you show us an example of that being used? I'd like to take a look.

That's not valid CSS.

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.

The page you've made is amazing. That's for sure. Well done!

However, please do allow me to push back and forgive me if I dish out one or two slightly dumb questions and comments.

If the user has normal, old-school validation then it's a list. Clearly. But, if they use in-line validation it's not a list, is it? So, I'm curious to know, what would be the justification for choosing list item elements if they're not really part of a list?

DC