Because templating systems are meant to remove all application/business logic and just focus on the appearance and presentation.
But this is kind of a Bauhaus thing. Remember: form follows function (Bauhaus was some sort of German art institute... not to mention a pretty cool new wave band:)
If you accept input > 25 characters, then you are providing a value which does not mesh with the database constraints... there need to be front end checks to ensure that bad data is never presented to the backend.
DBSchema::Sample
| [reply] |
That's certainly true, but at the risk of getting off-topic, you'd be... living dangerously, let's say... to trust the form to check your data integrity. So you're likely going to be checking it server side anyway.
Personally, I like to see that included in forms, not for any application logic or dubious security reasons, but for the general level of ill will you'll generate by silently and ruthlessly obliterating the input from valid users. Preventing such behavior strikes me as a goal of both the presentation and business logics anyway.
| [reply] |
Thats the trouble with html it's not always just about appearance. You know I'm sure I read somewhere that forms will be extended to include validation using xml schmas can't quite remember.
I do recognise that javascript and html validation usually creeps into templates and thus puts logic and code into them.
You can usually use file includes to extract most of the javascript out though and generate form fields server side using CGI.pm.
I know maxsize annoys me if it truncates my form input so yep you should usually tell the user on client side with javascript.
| [reply] |
If you accept input > 25 characters, then you are providing a value which does not mesh with the database constraints... there need to be front end checks to ensure that bad data is never presented to the backend.
Exactly. Apps built with bOP only get constraint violations for non-uniqueness or exists. Other constraint violations indicate a bug in the application.
The form field meta data is used in two ways: client side validation and server side validation. We never trust what the client sends us, but we try to give as much feedback as is reasonable (without resorting to JavaScript). That's what the maxsize argument is about. You know it, so might as well encode the HTML with it.
| [reply] |
Because templating systems are meant to remove all application/business logic and just focus on the appearance and presentation.
I disagree. While most business logic is contained elsewhere, there is still some logic in the presentation layer of the web application I am currently working on. It's along the lines of "If the current user has the privileges to do 'X', show the following link".
The graphic artist types don't need to concern themselves with any of that logic (if there were any on this project); they just need to know that the condition may be true, in which case a link may appear on the page.
--t. alex
Life is short: get busy!
| [reply] |
A | B | C
where A, B, and C are conditional links, and the vertical bars are visual separators. It's actually tricky to code this in HTML where A might exist, but B might not, and C might. Or for some other arbitrary combination. We usually encode this in a widget, which tests whether A, B, or C are rendered (see below), and then fills in with a separator. In bOP, it might look like:
NavBar(' | ', ['TASK_A', 'TASK_B', 'TASK_C']);
The NavBar widget's render function would looks something like this (not tested :-):
sub render {
my($self, $source, $buffer) = @_;
my($sep) = $self->render_attribute('separator'. $source);
my($need_sep) = 0;
foreach my $w (@{$self->get('values')}) {
my($b);
$self->unsafe_render_value($w, $source, \$b);
$$buffer .= ($need_sep++ ? $sep : '') . $$b
if $$b;
}
return;
}
This delegates the task of knowing how TASK_* is rendered to the widgets that know how to render tasks. In this case, it would be the Link() widget which looks up the permissions and the label based on the task name dynamically.
The question I have is how would this look in other template languages. And, where do the labels come from? How are permissions determined? Who evaluates if the current user's role and the role's authorized permissions.
That's where the "graphic designer" model breaks down. Either the designer has to know Perl to deal with the missing element problem, or the programmer has to work with the designer. There's no simple solution, but if the templating language doesn't offer ways to ask those questions (and most don't in my experience), you are left making things up as you go. That makes for funky websites where links lead to errors as opposed to using the meta data to ensure links don't get rendered unless you have the permission to execute them. | [reply]
[d/l]
[select] |
Good points. For the particular issue you raise, I'd probably pass in an array of items and have the template figure out how to add the 'thing in the middle' in between items, doing The Right Thing if there are 0, 1 and more than one items.
--t. alex
Life is short: get busy!
| [reply] |
