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

[Zbigniew Lukasiak]

Hi,

Now when I think about this I think that you are probably right that
the designer does not normally need to change the type of the field.
The attributes, possibility to intersperse the inputs with additional
tags and to change the order of fields should be quite reasonable
range of customisation.  I would not care too much about fieldsets and
ul/ols in HTML::Widget - I would just left that for the templating,
but I would generate the hidden fields by the start_form helper.

Unfortuntely I don't have any experience with designers in a Catalyst
project.  The interface_config.dat should not be too complicated - and
it can be made a bit simpler by choosing a separate directory for it
and having separate files for each Controller, and also by using some
config language instead of Perl datastructures.  But if it is only
used by InstantCRUD than I am afraid people would not accept it.

And where is that guy that started me thinking about this with his Rails email?

--
Zbyszek

On 11/6/06, Carl Franks <fireartist at gmail.com> wrote:
> 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
>
> _______________________________________________
> Html-widget mailing list
> Html-widget at lists.rawmode.org
> http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
>


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/