I admit to only having worked with mapper. I will look closer into  
record, (quick glance: it comes with next-to-the-field messages, nice).

Marius, are you referring to the toForm functions? I'm probably just  
not seeing how to use them in a flexible manner. With respect to  
validation, I was wondering how to apply conditional formatting based  
on failed/succeeded validation.

Maybe a word or two to the background of my questions: I'm currently  
trying to port a web application from RoR to lift. All I know is that  
RoR does not work for me any longer, but I'm not sure where to go yet,  
so I started to look around, and lift seems to be the most promising  
candidate. The heavy exposure to RoR might have tainted my mind, true,  
and I'm open to be shown the light.

Anyways, this app is of medical nature, very database heavy, lots and  
lots of fields. In order to avoid error upon data entry, the record's  
form on screen must looks as closely like the paper version as  
possible. A record's field can appear (and may be edited) in different  
contexts. Sometimes, the same text field is displayed with different  
lengths, the same text area may have different heights, all text  
fields may be limited to a max length of n in some contexts, etc.

Other aspect of the story: While working on the RoR version, the  
directive was: Some boolean fields are to be displayed as drop downs  
with 3 values (empty, yes, no). This now has changed, these boolean  
fields are to be displayed as 3 radio buttons. One of course wants to  
ensure that such a change only affects one area in the code base.

That's what got me wondering: Is the toForm approach the best one for  
my case?

Thanks for listening,

On 18-Mar-09, at 3:18 AM, marius d. wrote:

> FWIW please also take a look on Record and form&validation support.
> Br's,
> Marius
> On Mar 17, 11:07 pm, Clemens Oertel <clemens.oer...@gmail.com> wrote:
>> Hello everybody,
>> Still trying to learn how to use lift efficiently and effectively, I
>> got a little bit confused about the toForm function in the model/
>> mappers. Admittedly, my web framework background may be limited, but
>> this looked to me as if some view code snuck into the model space
>> there (I must admit that I do like how RoR tries to keep the models
>> fairly clean of both controller  code and of view code).
>> For my first little project, I was going to encapsulate the HTML  
>> field
>> formatting into a separate class (similar to what RoR does, but  
>> making
>> use of the type system).
>> This is a very quick brain dump, not running code.
>> // The different field types, at a higher level than HTML
>> abstract class InputType
>> case class TextField extends InputType
>> case class DateField extends InputType
>> case class DateTimeField extends InputType
>> // Rendering hints that an form field formatter may use, could also  
>> be
>> called FormGenerator ...
>> abstract class RenderingHint
>> case class MinLength(l: Int) extends RenderingHint
>> case class MaxLength(l: Int) extends RenderingHint
>> // Input-type aware callback'ed formatter, from the model's  
>> perspective
>> trait InputTypeHandler {
>>    def handleTextField(fieldID: String, presetValue: String,
>> renderingHints: RenderingHint*)
>>    def handleDateField(fieldID: String, presetValue: Date,
>> renderingHints: RenderingHint*)
>> }
>> // A model class using the callback
>> class ModelClass {
>>    object aField extends MappedString(this, 128) {
>>      def inputTypeCallback(InputTypeHandler handler) {
>>        // A reasonable default should/could be pushed upwards in the
>> type hierarchy
>>        handler.handleTextField(fieldID, this.is,  
>> MaxLength(this.length))
>>      }
>>    }
>> }
>> This InputTypeHandler could be a nice spot to deal with validation
>> result formatting:
>> class AnInputFormatter(errors: List[FieldError]) extends
>> InputTypeHandler {
>>    def handleTextField(fieldID: String, presetValue: String,
>> renderingHints: RenderingHint*) {
>>      errors.filter(_._1 == fieldID).match {
>>        case Nil => /* format field normally */
>>        case xs => /* format as error, i.e. red background, error
>> messages right of field .... */
>>      }
>>    }
>>    ...
>> }
>> // A snippet
>> ...
>> val inputFormatter = new AnInputFormatter(errorsFromValidation)
>> bind("form", html, "aField" -> aModelClass.aField.
>> inputTypeCallback(inputFormatter))
>> ...
>> Maybe a partial function, potentially on case classes, is better?  
>> Many
>> options ...
>> I'm looking forward to any feedback.
>> Best,
>> Clemens
> >

Clemens Oertel

Clemens Oertel

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to