Hi Jesse,
Thankyou for your email, they were very insightful.
I am actually doing it a way that is not too dissimilar to your way now.
On some of your points:
> Now, you describe a situation where you have "hundreds" of possible errors.
> Let's break that down a couple ways:
>
> 1. Per screen. Do you have "hundreds" of possible errors on every screen?
Nope.. but the same "Error Template file" is used by many many perl
modules (there is only one file to keep it easy to maintain the
look/feel the way any error is displayed) - ie. there can be hundreds of
"error variables" - some of which will be set to true.
>
> 2. Thrown to user. Do all of the "hundreds" of possible error messages
> actually need to be displayed to the user?
Nope... usually only one of two are relevant and have their error
variables set.
>
> 3. Designer-configurable. Do all of the "hundreds" of possible error
> messages actually need to be changeable by an HTML designer?
In most cases, i pass an "error string" as well as setting a "error
variable" to true. Usually the error string is sufficient and good, but
in rare cases, the HTML designer should be able to control the message
and needs to use the variable.
> <tmpl_if error_invalid_date>The date you entered is invalid.</tmpl_if>
> <tmpl_if error_invalid_widgetid>There is no such widget by that
> name.</tmpl_if>
> <tmpl_if error_some_other_case>Error with XYZ.</tmpl_if>
> Essentially, error messages which need to be configurable in the template
> are given some name, and a Boolean TRUE is passed to the template if that
> error is active. As you can see, there is no use of <tmpl_else> -- all
> logic is on the application-side.
>
The reason i need an elsif is because:
* The designer should be able to chose to NOT print the error string
if they are using the error variable.
* All error strings are in _one_ loop structure no matter which
perl module they are from.
My friend reminded me the basic fact (which i can't believe i had
forgotten :-) that an elsif is just a convinent way of writing an if and
a else (there is nothing special about it) so now i do:
<tmpl_if name=error_one>
This is error one
<tmpl_else>
<tmpl_if name=error_seven>
This is error seven
<tmpl_else>
<tmpl_if name=error_three>
This is error three
<tmpl_else>
<tmpl_loop name=errors>
Error: <tmpl_var name=msg>
</tmpl_loop>
</tmpl_if>
</tmpl_if>
</tmpl_if>
I think the above could have been "easier written" as:
<tmpl_if name=error_one>
This is error one
<tmpl_elsif name=error_seven>
This is error seven
<tmpl_elsif name=error_three>
This is error three
<tmpl_else>
<tmpl_loop name=errors>
Error: <tmpl_var name=msg>
</tmpl_loop>
</tmpl_if>
As you can see, the loop is "only" used if the designer has not setup a
custom message for a particular error (in the above example i only take
care of the error variables one, seven and three - although others could
be set).
The reason its important for the designer to be able to control the
message is:
* Designers are designing for different platforms (Web, HandHeld,
Custom Browsers, etc...) and they should when appropriate
be able to customise the error and give additional help
(i also set variables indicating what platform people are using)
* Designers design for different cultures and languages - so in those
cases they should be able to customise every error message (labrious
- but necessary as they do the translations) - in this case, without
the elsif (having to use only if's and else's) we would start
getting very very deep nested if structures, but they work :-)
Thanks again for the time you took to write your email, i got quite a
few ideas from it and it helped a lot.
cheers,
simran.
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Html-template-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/html-template-users
