[Html-widget] HTML::Widget::Element::Field

Carl Franks fireartist at gmail.com
Mon Nov 6 14:38:07 GMT 2006


On 03/11/06, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> First of all my goal was to make Catalyst::Example::InstantCRUD an
> easy starting point for learning programming in Catalyst.  This means
> that the user should be able to start playing with the presentation
> layer without the fear to break something in the more invisible
> business logic parts.
> Accidentaly (or perhaps not) this kind of separation would also be
> good for bigger teams - where you could let the designer work with the
> templates - and the programmers with other parts of the project.  Of
> course we could get rid of generating the form entirely and have
> everything in the templates - but then we would have to code the logic
> for errors and stickiness etc in the templating language which is too
> simple for tasks like that.  So what is left is some smart HTML tags -
> and the example of Rails shows that this can work.
>
> I have also the idea of scaffolding - so that the programmer could
> build a form reasonably good looking without the help of the designer
> and have  just: [% result %] in the template.  But then the designer
> would come to the project and he could override the defaults provided
> by the programmer with:
>
> [% result.form_start %]
> [% result.textfield( foo ) %] <br>
> [% result.textarea( bar ) %] <br>
> [% result.checkbox( baz ) %] <br>
> <input class="submit" id="widget_ok" name="ok" type="submit" value="Create" />
> </form>

Being able to start with just [% result %] in the template, and then
have a route to customization is a good goal.
What's your experience been like with pointing designers at the
interface_config.dat file to make those kind of changes?
It looks like a simple enough syntax, that anyone should be able to
make changes without too much difficulty. ( Is that wishful thinking?
:)

A complication with the proposed method above, is that a widget will
have at least 1 fieldset element, but may have any number of hidden
fields, nested fieldsets, divs, spans, ul/ol's.
Would we want the methods in your example above to be smart enough to
print elements earlier in the form, and any opening tags?
Likewise, we'd need a form_end() method which closes all the tags.
This would mean you couldn't rearrange the order of elements, using
these methods.
It would also mean having to ditch HTML::Element and write our own xml
generator.
Or if you were using these methods, would it suffice that you can only
use form-related elements (no fieldset, div, etc) and that the
designer has to explicitly list all elements?
We could, of course, provide helpers such as
[% result.hidden_fields %] and
[% result.buttons %]

A much easier method to implement would be something like...
[% result.type( 'Textfield', 'foo' ) %]
[% result.type( 'Textarea', 'bar', 'rows', '5' ) %]
[% result %]
But, then, you're kinda making the designer think like a programmer.

I'm working on changing the internals, so you can choose a different
renderer, using TT rather than HTML::Element, for example.
If I get this working, that may help, but you'd still need to make
that decision, as to which renderer to load.

> The problem here would be that there would be some leftovers - in the
> code the programmer would leave
> $w.element('Textfield', baz)
> but in the output this foo would be overriden to be a checkbox.  This
> looks a bit unclean - but actually I don't know if this is something
> important here.

If the intension is to let the designer /override/ the programmer's
choices, then it's not really avoidable.
Of course, only allowing changes in "interface_config.dat" would solve that.

> The scaffolding idea is quite powerfull in my opinion.  It is about
> designing the library not for a static usage - but rather taking into
> account that the needs of a project change over time.

Being able to set tag attributes from the templates sounds good, but I
question the value of being able to change the element type from the
templates.
Other than changing between textfield / textarea, there can't be many
situations in which it's okay for the designer to change the type,
without the database or validation(controller) layer knowing about it.
Select and RadioGroup elements require a list of labels / values,
which would be unwieldy to pass from the template. (I don't like how
Rails handles Selects).
Checkboxes usually represent a boolean datatype, which ideally would
have a 'Bool' or other appropriate constraint added in the controller,
and use a relevant database column.

I like how Reaction uses TT templates, but they're specific to each
field type, and I don't see how we could use that approach to allow
customization by element name, rather than type.

Hmm, what about creating a $widget by parsing a html file containing
only a FORM tag and the form contents?
The controller code would only need to add constraints / filters.
The designer can change the form html as they wish.
I obviously haven't given this much thought, though...

Well, what can I say? Give me a crude core dump, and you'll get one
back in return!

Carl



More information about the Html-widget mailing list