Automatically generated forms

[Alli]

I'm working on porting my rails app to lift and have been amazed by
lift. The community
is quite small and seems to be quite friendly as well.

First thing I want to mention is I don't regularly dive into the code
of the frameworks I'm using
but it's really easy to read and navigate through the liftweb source.
The code base is managable
and not that big yet so it's a good time to get familiar with it.

Are the toForm() methods in the lift Mapper/MetaMapper intended for
'production use' or just
to get something up quick and dirty. I really like the idea of
automatically generating the form
but the xhtml returned includes <tr><td><input.......></td></tr>. I
really tend to keep my form
table-less. I was playing with it yesterday, trying to override the
formatFormLine method in
my model to return something like: <label
for="{displayName}">{displayName}</label>
<input>.... etc. The problem is that the formatFormLine is not the
only method that
is enforcing the use of tables, it is also in one of the toForm()
methods in Mapper.scala.
If i start overriding all these methods, it starts being kind of silly
so i decided going back
to using bind() and then using .toForm() on each MappedString/
MappedTextField etc object
which is fine but it would be nice being able to automatically
generate the entire form and then
use style sheets to lay it out nicely. Is it possible to put these
<tr><td>... into some helper
methods that we can then override?

[Alexander Kosenkov]

Completely agree with you.

I'm sure that default forms should not contain tables at all.

[David Pollak]

On Tue, Jul 29, 2008 at 1:25 AM, Alli <allil...@gmail.com> wrote:

I'm working on porting my rails app to lift and have been amazed by
lift. The community
is quite small and seems to be quite friendly as well.

Welcome and we're glad to have you. 
 

First thing I want to mention is I don't regularly dive into the code
of the frameworks I'm using
but it's really easy to read and navigate through the liftweb source.
The code base is managable
and not that big yet so it's a good time to get familiar with it.

:-)
 

Are the toForm() methods in the lift Mapper/MetaMapper intended for
'production use' or just
to get something up quick and dirty.

I use them in production.  For simple CRUD work, the Mapper forms are, IMHO, a better alternative than scaffolding or other generated code.
 

I really like the idea of
automatically generating the form
but the xhtml returned includes <tr><td><input.......></td></tr>. I
really tend to keep my form
table-less. I was playing with it yesterday, trying to override the
formatFormLine method in
my model to return something like: <label
for="{displayName}">{displayName}</label>
<input>.... etc. The problem is that the formatFormLine is not the
only method that
is enforcing the use of tables, it is also in one of the toForm()
methods in Mapper.scala.
If i start overriding all these methods, it starts being kind of silly
so i decided going back
to using bind() and then using .toForm() on each MappedString/
MappedTextField etc object
which is fine but it would be nice being able to automatically
generate the entire form and then
use style sheets to lay it out nicely. Is it possible to put these
<tr><td>... into some helper
methods that we can then override?

Let me noodle on something.  I'll post code up later today.  I'm thinking a formatting function that can be defined in Boot might do the trick.

Thanks for the question/suggestion.

David
 

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[David Pollak]

Folks,

I committed up a few enhancements to form generation from Mapper models.

There's a new object (MapperRules) that contains formatting rules:

/**
 * Rules and functions shared by all Mappers
 */
object MapperRules {
  /**
   * This function converts a header name into the appropriate
   * XHTML format for displaying across the headers of a
   * formatted block.  The default is &lt;th&gt; for use
   * in XHTML tables.  If you change this function, the change
   * will be used for all MetaMappers, unless they've been
   * explicitly changed.
   */
  var displayNameToHeaderElement: String => NodeSeq = in => <th>{in}</th>

  /**
   * This function converts an element into the appropriate
   * XHTML format for displaying across a line
   * formatted block.  The default is &lt;td&gt; for use
   * in XHTML tables.  If you change this function, the change
   * will be used for all MetaMappers, unless they've been
   * explicitly changed.
   */
  var displayFieldAsLineElement: NodeSeq => NodeSeq = in => <td>{in}</td>

  /**
   * This function is the global (for all MetaMappers that have
   * not changed their formatFormElement function) that
   * converts a name and form for a given field in the
   * model to XHTML for presentation in the browser.  By
   * default, a table row ( &lt;tr&gt; ) is presented, but
   * you can change the function to display something else.
   */
  var formatFormElement: (NodeSeq, NodeSeq) => NodeSeq =
    (name, form) =>
      <xml:group><tr>
  <td>{name}</td>
  <td>{form}</td>
  </tr></xml:group>
}

If you change the functions, you globally change the formatting functionality (you can do this in Boot).

Each MetaMapper has one of these variables so you can override functionality on a MetaMapper by MetaMapper.

I hope this helps.

Thanks,

David

[Alli]

Thanks David, that's perfect. Will give it a go soon. Not often when
you make a suggestion that
gets implemented the same day :).

Cheers,
Alfred

> > Collaborative Task Managementhttp://much4.us

[David Pollak]

On Tue, Jul 29, 2008 at 10:43 AM, Alli <allil...@gmail.com> wrote:

Thanks David, that's perfect. Will give it a go soon. Not often when
you make a suggestion that
gets implemented the same day :).

We aim to please. :-)

Plus, the Mapper code is nearly 2 years old and I wrote it when I was thinking a lot more OO and imperative.  This was a perfect application of FP.  And a big thanks to Marius for coming up with the "Rules" object idiom.
 

--

lift, the simply functional web framework http://liftweb.net

Collaborative Task Management http://much4.us

[Alli]

Hi David,

I just installed 0.10-SNAPSHOT to try out the changes and couldn't get
it working,
was calling myModelObject.toForm(Full("Submit"), "/blah") and had
overridden
the vars in Boot.scala as you described. It seems like the functions
don't get called.

Then I started debugging and diving into lift:
I checked the def toForm(button: Can[String], f: A => Any): NodeSeq
in
Mapper.scala and it still has references to <tr></tr>. Wasn't sure if
you
had already implemented everything, was just so impatient to try the
stuff
out :).

Cheers,
Alfred

On Jul 29, 7:22 pm, "David Pollak" <feeder.of.the.be...@gmail.com>
wrote:

[David Pollak]

D'oh!

I found the last place (In Mapper.scala) where I didn't clean up the code.

If you're using the Maven repository, it'll take about an hour before the new code has made in through Hudson.

If you're pulling from GitHub, the code's up and live.

[Alli]

Cheers David, it works like a charm! You guys definately won't need
any bugtracking system, the bugs get fixed as soon as they get
spotted!

[David Pollak]

On Wed, Jul 30, 2008 at 1:45 PM, Alli <allil...@gmail.com> wrote:

Cheers David, it works like a charm! You guys definately won't need
any bugtracking system, the bugs get fixed as soon as they get
spotted!

:-)

Looking forward to seeing the excellent things you build with lift.
 

--

lift, the simply functional web framework http://liftweb.net

Collaborative Task Management http://much4.us