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

Mark Zealey mark at itsolve.co.uk
Tue Feb 20 18:02:17 GMT 2007


Something else i wanted to do was to be able to define 'blocks' which would go 
on my form; for example:

form:
  INCLUDE 'name.fb'
  INCLUDE 'address.fb'

To get a default name block and then an address block appended to my form. 
Using HTML::Widget you could do ->merge which is something i'm yet to find an 
equivelent too in formbuilder. Because of the way the fields are defined; i'm 
not sure it's possible to create a block widget like that and in any case i 
want to 'flatten' it into the form basically via an include as shown above. I 
don't really know how switching to YAML would work with that though...

Mark

On Tuesday 20 February 2007 4:04 pm, Jonathan Rockway wrote:
> 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?



More information about the Catalyst mailing list