[Html-widget] Rails-like form helpers - RFC for a new module

[John Napiorkowski]

I'm definitely interested in seeing what you come up
with.  I'm not sure if any names I come up with are
useful though :)  I also used DBIx::Class::Widget for
a little while but found as you that it was a little
too much bound together which is why I'm using
formbuilder now (which has less glue to DBIx then I
would like, granted). 

As far as the config file format, why not use
config::any and just let people choose the config of
their choice?

 --john



--- Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:

> Thanks for the ideas, I think I'll try them later -
> for now the module is
> nearly ready it just needs some finishing touches. I
> would like to finish it
> and see if people use it before extending.  What I
> need now is to decide how
> to name it and if make it a subclass of HTML::Widget
> - the creator would
> record the config and db row in the object and then
> the update would an
> object method with no arguments.  This would be the
> simplest interface I see
> - but unfortunately the update method needs to have
> a HTML::Widget::Result
> object not a simple HTML::Widget - any ideas how to
> cleanly solve that?
> 
> All the logic for this module I've taken from
> DBIx::Class::Widget (by Jonas
> Alves). We came to conclusion that it was coupling
> the db and the interface
> too strongly and I hope that the config will make
> the coupling a bit more
> loose.
> 
> --
> Zbyszek
> 
> On 9/25/06, Peter Edwards <peter at dragonstaff.com>
> wrote:
> >
> > The sort of interface I'd like would be a form
> definition file, say in
> > Config::General format, following a standard
> syntax.
> > As a starting point it would be worth looking at a
> Visual Basic .frm file
> > to
> > see the sort of info that stores.
> > - general form level attributes, including data
> source spec
> > - nested containers, both simple and tabbed
> > - labels
> > - widgets for display elements with optional link
> to data source element
> > - back in InstantCRUD an overrideable handler for
> generalised form
> > handling
> > tasks (list paging, record view, record next/prev,
> that sort of thing) and
> > backends for AJAX widgets.
> >
> > Later on someone could write an Eclipse plugin to
> make it easy to set up
> > forms. Valuable for proof of concept prototyping
> and then you can fine
> > tune
> > the form def or write custom TT2 templates where
> necessary.
> > It also makes it easy to write a utility to allow
> users to customise
> > screen
> > appearance.
> >
> > Regards, Peter
> >
> > -----Original Message-----
> > From: html-widget-bounces at lists.rawmode.org
> > [mailto:html-widget-bounces at lists.rawmode.org] On
> Behalf Of John
> > Napiorkowski
> > Sent: 24 September 2006 23:38
> > To: html-widget at lists.rawmode.org
> > Subject: Re: [Html-widget] Rails-like form helpers
> - RFC for a new module
> >
> > --- Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> >
> > > Dear all,
> > >
> > > In the new InstantCRUD I decided to take out the
> > > code for html forms
> > > generation and make a separate module for it. 
> After
> > > reading 'Rails-like
> > > form helpers' thread I think that this module
> might
> > > find a more general use.
> > > I would like to ask you what intefrace would you
> > > propose for it.
> > >
> > > It can build the HTML::Widgets based on some
> config
> > > and data from the
> > > database and then can also save the data from
> the
> > > widget to the database.
> > > The config part is more complicated than it
> could be
> > > because the info about
> > > many-to-many relations is not available from the
> > > schema so you need to
> > > specify it in the config.  Since it is already
> there
> > > I've added also the
> > > stringification to it - as it is a bit cleaner
> to
> > > have it here in the
> > > interface part than overload stringification in
> the
> > > database schema
> > > definition.
> > >
> > > The current interface is composed of just two
> > > functions:
> > >
> > >
> >
>
Catalyst::Example::InstantCRUD::Widget->make_widget($interface_config,
> > > $class, $schema, $item);
> > >
> > > $interface_config is a hash containing info
> about
> > > all db classes and how to
> > > wigetify them, $class is the db class, $schema
> is
> > > DBIC schema and $item is
> > > the db row to populate values in the form - its
> > > optional.
> > >
> > >
> >
>
Catalyst::Example::InstantCRUD::Widget->populate_db($result,
> > > $item);
> > >
> > > $result is HTML::Widget::Result and $item is the
> db
> > > row to be updated
> > >
> > > So my question is do you think it deserves to be
> > > taken out from InstantCRUD
> > > and then what name would you propose for it? 
> How
> > > would you design the API?
> >
> > I personally like the idea of having a config file
> for
> > this.  One of the things that has really worked
> for me
> > with Formbuilding is that option to use a yaml
> > configuration file to build forms.  I didn't
> > personally like building the forms in the
> controller,
> > it really seems like a view thing to me, and
> > forwarding to a view to build the form and then to
> > Template Toolkit seemed really like a lot of extra
> > work.
> >
> > With formbuilding I can put the config file in
> with
> > the *.tt files and it seems really neat and
> ordered to
> > me.
> >
> > Other things I'd like is an easier way to have the
> > forms and other elements hook back to catalyst
> > controllers.  I've really liked the JSF idea of
> having
> > the template language be more than a renderer. 
> Makes
> > developing AJAX stuff easier.
> >
> > So it would be very cool if instead of exposing
> > information to the template system you would
> expose
> > objects with callbacks to controllers.  However to
> get
> > this to work right we really need a better
> subrequest
> > system.  I've been playing with the subrequest
> plugin
> > from Trunk just to get the idea of how this all
> works
> > but haven't made so much progress in understanding
> it
> > all :)
> >
> > Right now for my portal like system I'm just
> creating
> > objects that do dumb LWP requests to a controller.
>  It
> > works but feels very crude.
> >
> > --john
> >
> >
> >
> > _______________________________________________
> > 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/
> > _______________________________________________
> Html-widget mailing list
> Html-widget at lists.rawmode.org
>
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com