On Mar 18, 1:30 pm, Clemens Oertel <clemens.oer...@gmail.com> wrote:
> 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.

Yes I am referring to toForm but note that you can provide your own
template. Please see formTemplate. I think the existent scaladocs can
be quite helpful. You can also apply an extremely flexible validation
model. Each field can have multiple validators and when you are
calling S.error(MetaRecord.validate(myRecord)) Lift will automatically
place the error messages near by your fields.

Nevertheless for youimediate needs the Record is probably not very
relevant yet as DB for Recrd is not yet implemented. I was just
pointing out that forms&form validations are consistently provided by
Record. I think there is still some level of validation in mappers but
I haven't played with it yet ...

>
> 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,
> Clemens
>
> 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
> clem...@oertel.ca
>
> Clemens Oertel
> clem...@oertel.ca
--~--~---------~--~----~------------~-------~--~----~
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 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to