John Siracusa wrote:
...cut...
Warning! Localization alert! :) Like I said before, I don't think
you really want to be passing things to the view at that granularity.
It makes for some vary hairy form templates--one for each locale, to
boot.
If you whip up all this stuff *before* passing it off to the template,
you get templates like this (shown using Mason with a
"designer-friendly" syntax for the form/fields which just translates
deterministically into the corresponding method calls at runtime):
<% '/messages.mc', %ARGS %>
<% 'START_FORM' |fm %>
<table>
<tr>
<td class="label"><% 'USERNAME:LABEL' |f %></td>
<td class="field"><% 'USERNAME:FIELD' |f %></td>
</tr>
<tr>
<td class="label"><% 'PASSWORD:LABEL' |f %></td>
<td class="field"><% 'PASSWORD:FIELD' |f %></td>
</tr>
<tr>
<td colspan="2"><% 'LOGIN_BUTTON:FIELD' |f %></td>
</tr>
</table>
<% 'END_FORM' |fm %>
That's one form template for all supported languages, complete with
extremely granular, localized error messages. (e.g., "The username
'whatever' is already taken. Please choose another.") The form-wide
messages go in the message box produced (or not, if no messages) at
the top by messages.mc. The per-field errors are returned by the
"USERNAME:FIELD" calls and go under each field.
Even ignoring localization, you will save much sanity by constructing
all this stuff "perl-side" before passing it off to a template.
-John
This all makes excellent sense, since localisation is another thing to
worry about on my agenda!
Leaving aside my original question, I do however have the following
observations.
1) The contents of USERNAME:LABEL and USERNAME:FIELD have to be created
somewhere. I assume that this is in the controller, which creates some
HTML (using widgets or the like) and which inserts the localised text?
2) I don't like the idea of there being *any* html code produced in the
controller since in principle the same controller could be used for
different output media.
3) ISTM that there should be another layer between the controller and
the Template to perform the localisation. Perhaps this is where the View
needs to actually have code rather than taking the passive approach that
I see in all the Catalyst examples. So the controller would generate
some generic error flag (e.g. a flag to warn that the username field is
already taken, or is too long) and the localisation 'layer' would
convert this into the appropriate language version.
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
