Hi Simran --
> I have a template where i really need to use "else if" conditions? How
> do you all handle places where you need to use "else if"?
>
> A sample of my situation is:
>
> <tmpl_if name="error1">
> Error one occured
> <tmpl_elseif name="error2">
> Error two occured
> <tmpl_else>
> No error could be determined...
> </tmpl_if>
>
> If if was just two error messages, i could nest the if's but i have a
> situation where i might have hundreds!!!
There are a couple different aspects of your question I'd like to speak to.
Let me start by describing how I generally implement error messages in
templates:
<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.
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?
2. Thrown to user. Do all of the "hundreds" of possible error messages
actually need to be displayed to the user?
3. Designer-configurable. Do all of the "hundreds" of possible error
messages actually need to be changeable by an HTML designer?
Many errors are screen-scoped. If a user fails to enter their name on a
form which asks for their name, then I would set "error_name_invalid" and
return the user to the form. The "error_name_invalid" state doesn't have
any meaning on the screen where they select which item to purchase, so it's
not needed there.
Many applications have hundreds of possible errors. Everything from a user
failing to enter their name to failure to connect to the database can be
considered an error. But not every error needs to be thrown to the user.
User failure to enter data into a field is probably something you want the
designer to be able to configure because it is highly likely that someone
may want to finesse the text a bit. This is a good example of a
design-configurable error which should be in the template.
OTOH, if an application fails to access a resource, such as a database, a
particular file, RAM, or hard-drive space, an internal server error is
probably all you need to share with the user. If you wanted to make a
pretty message for internal errors there are other mechanisms. As a user,
what is the good of knowing that the database is inaccessible? These errors
should be recorded in the web server error log for an administrator.
Showing errors like that to the user is not very user-friendly. In fact, in
some cases it may even be a security liability. Imagine a hacker probing
your system and getting SQL errors with SQL code. (I've done it myself --
I've used too-verbose display of internal errors on a site to
reverse-engineer how they are transforming form input into SQL queries.)
Sometimes you might want to display an error message to the user so that
they can report the error to a customer support rep. My on-line bank
does that. This is a third case: Internal errors you want to publish to
the user, but messages which are NOT required to be edited by a designer.
In this case all you need to do is:
<tmpl_if internal_errors>
An internal server error has occurred. Please call
customer service and give them the following error codes:
<tmpl_var internal_errors>
</tmpl_if>
There is no need for the designer to change the actual error codes. In
fact, it is undesirable. Internal errors refer to internal structure which
needs to be linked to subroutines. This is clearly the domain of the
programmer. In this case, it is entirely correct use of HTML::Template to
simply display the codes output by the application.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-------------------------------------------------------
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
