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

[Zbigniew Lukasiak]

Hi,

I must admit that I don't have any definitive idea how the new element
would be used.  What I can do now is just make a core dump of the
crude thoughts I have on that subject.

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>

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.

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.

--
Zbyszek




On 10/31/06, Carl Franks <fireartist at gmail.com> wrote:
> On 31/10/06, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> > Hi,
> >
> > Answering Carl's comment on my blog post at:
> > http://www.blogger.com/comment.g?blogID=36345871&postID=116134505314349604
> > where inspired by an email from this list I compared HTML::Widget with
> > Rails Helpers.
> >
> > Carl writes:
> >
> > > I've edited H::W, to make it possible to add a 'Field' type element to achieve this.
> >
> > > $widget->element(Field => foo);
> > > $result->field_xml( foo => 'Textfield', %attrs );
> >
> > That's a fast reply!  Looks like HTML::Widget is really moving fast
> > ahead.  Now I need to think how to incorporate that into InstantCRUD.
> > But I have one more idea.  How about:
> >
> > $result->Textfield('foo', %attrs)
> >
> > What do you think?
> >
> > And by the way - the explanation message for a failing constraing
> > logically also belongs to  the templates.  But it is so tightly
> > coupled to the actual code of the constraint that I don't see a good
> > solution to this.
>
> I don't have as much time as I'd like to reply properly, so I'll
> expand on this later... hopefully there'll be some conversation around
> this though!
>
> As I mentioned in the blog reply, the $result->field_xml() feature
> hasn't been added to svn - it's just something I've experimented with
> on my desktop.
>
> How would this method be used? Would you be calling it in the template
> for every field in the form? What about the form tags? hidden form
> fields? buttons? This seems a step backwards.
> Can you describe an API that would allow you to use $result->as_xml
> for /most/ of the form, but override just 1 or 2 fields?
> Would using separate template files for each field help, letting you
> change templates on each form / field?
>
> I'd like a better idea of how you'd like to use it, and what other H-W
> things are causing you issues, before adding yet another method to
> what is becoming a thick soup.
>
> There are some things I'd like to rework - I don't like how element
> containers are done - I don't like that $result->elements() returns
> containers which already have a HTML::Element baked in them - I'd like
> it to be simple to point to a folder of templates to use for xml/html
> generation - have an agreed css lexicon (as mentioned in the "Catalyst
> Marketing Plan Draft" thread on the catalyst-dev list), etc...
> Do we want to support "nested" params, like[this], is so how would they be used?
>
> I'd also like to clear up the mess of methods in $widget and $result.
> Do we really need $w->get_elements() # non-recursive
> and $w->find_elements() # recursive ... ?
>
> At this moment I don't know how backward-compatible these things would
> be, and whether this will need to be in a new namespace, or whether it
> would be acceptable to move the existing code to H::W::Compat and
> develop H::W afresh?
>
> 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/