[Catalyst] todo list for FormBuilders (was the l10n thread)

John Napiorkowski jjn1056 at yahoo.com
Tue Feb 20 16:38:36 GMT 2007


----- Original Message ----
From: Jonathan Rockway <jon at jrock.us>
To: The elegant MVC web framework <catalyst at lists.rawmode.org>
Sent: Tuesday, February 20, 2007 11:04:34 AM
Subject: Re: [Catalyst] todo list for FormBuilders (was the l10n thread)

Christopher H. Laco wrote:
> FormBuilder is nice when it comes to localizing the messages via
> messages.$lang. It totally sucks when it comes to localizing the form
> labels themselves. It looks like I either have to manually loop through
> teh fields and localize the labels, or use a different .frm config for
> each language...which means duplicating major parts of the config.

This doesn't really answer your question, but raises another good point.
 FormBuilder's definition files are great.  The fact that they're
magically parsed by the secret internals FormBuilder isn't.  In your
case, you really want something like this:

Form:
  foo:
    name: _[1]
  bar:
    name: _[2]
...

and then you want to apply a filter that properly maps _[1] to the
localized string as expected.

The way this should work is that form definition files should be
retrieved from a Model.  The default model would parse the YAML and then
pass the result to FormBuilder.  This would give you the opportunity to
reuse an existing model (maybe you want your forms to come from a
database), and give you the opportunity to subclass the model to do
l10n, use XML instead of YAML, etc.  The idea is to use a Catalyst model
instead of a FormBuilder "model".  This would solve your problem, and
many others that people haven't had yet :)

Interestingly (now that I think about it) FormBuilder is really its own
MVC framework (its own filesystem model for reading config, its own
templating system as a view).  I guess what we need to do is get rid of
FormBuilder's model and view and use Catalyst's instead.  (Something I
dislike about FormBuilder is invoking TT twice per request; [% PROCESS
my_form.tt form=FormBuilder %] is much clener.)

Then you could read XML-formatted forms from memcached and render them
with ClearSilver -- without FormBuilder ever knowing or caring.  (The
flexibility of Catalyst we all love...)

Anyway, /me goes to look at how easy this is to do... but in the mean
time... comments?  Am I missing something?

I don't think you are missing anything.  Actually I was thinking something similar myself, but for a bunch of layout classes I've been working on.  I like the idea of a config type file for this, let's my authors declare what their page needs, but instead of having the controller perform this via a custom controller or an action class I want the action class to let a model do this for me.  So the model should be responsible to get the configuration in an expected format.  This would make it much easier if in the future I want to put stuff into the database instead of the filesystem.

--john

-- 
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;

_______________________________________________
List: Catalyst at lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/





 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index



More information about the Catalyst mailing list