[Lift] Re: Forms & validation formatter
On Apr 2, 6:57 pm, Clemens Oertel wrote:
> One follow up question, relating to the contexts I mentioned earlier:
> Following my approach mentioned below, let's assume I have a template
> for embedding. This template contains the HTML code for a tabular
> list of data entities. Depending on where the template is embedded,
> some of the entities' fields should appear as links: There are 2
> linkable reference fields A and B, and depending on the context,
> either A, B, or A and B should be rendered as links to the referenced
> entity.
>
> This logic obviously can't go into the template. Also, the model's
> toForm method is unsuitable (having the model referring to a
> RequestVar seems evil to me). No no, this should go into the snippet,
> where such logic belongs. But this would mean having to go through the
> templates XML tree before calling Site.toForm(site, form), enclosing
> all affected liftf:field elements with the respective links. This
> sounds very, very wrong.
>
> Thus, from my current understanding, this context-sensitive rendering
> of fields is best done using the explicit lift-tag/bind approach. So
> I'll probably have to have explicit bind calls anyways, and won't be
> able to use my initial approach of having the mapper class (or it's
> companion object) fill out the forms itself.
>
> I'd be happy if someone could prove me wrong ...
I don't necessarily see this in terms of right and wrong. Well your
embeddable template could use a snippet and you can potentially use
chooseTemplate to kind of shape the form template ... then you can
call toForm in this snippet hence passing only the appropriate form
template and not a huge template containing things that do not relate
with your form per se.
>
> Best,
> Clemens
>
> PS: Exercise for the reader: Instead of selective linking, have only
> either A or B be displayed, depending on the embedding context.
>
> On 31-Mar-09, at 3:59 PM, marius d. wrote:
>
>
>
>
>
> >> Outer Template
> >>
> >> Create a New Site
>
> >>
> >>
> >>
> >>
> >> Submit
> >>
> >>
> >>
> >>
> >>
> >>
> >> End Outer Template
>
> >> Embedded Template
> >>
> >>
> >> Name: >> td>
> >> A Hospital Site
> >>
> >>
> >>
> >> End Embedded Template
>
> >> SiteOps
> >> def add(form: NodeSeq): NodeSeq = {
> >> val invokedAs = S.invokedAs
> >> val site = Site.create
>
> >> def newSite(form: NodeSeq): NodeSeq = {
> >> def saveMe(): Unit = {
> >> site.validate match {
> >> case Nil => site.save ; S.notice("Added " + site.name);
> >> S.redirectTo("/sites/")
> >> case xs => S.error(xs) ; S.mapSnippet(invokedAs, newSite)
> >> }
> >> }
>
> >> bind("site", Site.toForm(site, form), "submit" ->
> >> submit("Save", saveMe))
> >> }
>
> >> newSite(form)
> >> }
> >> End SiteOps
>
> >> The Site.toForm function is pretty much the same as found in
> >> MetaRecord. It will eventually call each fields' toForm function
> >> (which are the original Lift 1.0 mapper versions, no changes there).
>
> >> Am I really doing things outside the rendering pipeline (this is
> >> not a
> >> rhetorical question)?
>
> > Nope sorry ... I misunderstood your case. By bad entirely.
>
> > It all seems to work, incl. validation.
> >> Also, the eagerly evaluated template, which will be passed to toForm,
> >> contains only field tags, no other lift tags.
>
> >> Again, imagine a few dozen different entities, each with a ton of
> >> fields. I'm sure you'll understand that I'm hesitant to bind each
> >> field manually (once for the list page, once for the display page,
> >> once for the add page, and again once for the edit page, even though
> >> the last 2 can surely be combined into one bind call in the code).
> >> I obviously have to declare each field in the model, and refer to it
> >> in the view. I really wouldn't mind not having to mention it anywhere
> >> inbetween.
>
> > This is actually a nice thing to do. Sorry that I misunderstood your
> > intentions :)
>
> >> Thank you for all your help,
> >> Clemens
>
> >> Clemens Oertel
> >> clem...@oertel.ca
>
> 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
-~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
> > Most web sites I've worked on, there's a default way to display a form and > that default is encapsulated in the model itself. This encapsulation does > not bar you from building your own form renders, but it does give you nice > default behavior. > I found it odd at first too, to find web rendering methods in the data object classes. It doesn't bother me particularly. But it does seem like keeping Record narrow would encourage broader use of the Record API. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Tue, Mar 31, 2009 at 7:06 AM, Clemens Oertel wrote: > Hello, > > Sorry for the delay in my response, but I only get to play with lift on the > weekends, and I wanted to look into your suggestions in more detail. > > I ported the toForm code from Record to Mapper (and by port, I mean mostly > cut'n'paste). While doing so, I noticed 2 things: > > - Why not provide the same template mechanism used for forms for HTML > output? This way I can reuse the same template for both - given that my > records have at least dozens, if not even hundreds, of fields, that'd be a > great help. > - The templates require the use of and similar tags. I thought > I'd be really smart, and created a HTML file A with lift-tags > (...) to run my snippet, and used > the tags as children to . This way, I can > create my templates externally, and use the normal lift dispatch-from-view > mechanism. And, to save me some more work, the actual form template is in a > separate, reusable, HTML file B, to be embedded into A. Embedding, of > course, requires eager evaluation. Fine. No. With eager evaluation, lift of > course complains that there is no class "field", as referenced by > . Now me's wondering whether a separate namespace would be more > appropriate? (I did switch to a different namespace, liftf, out of > necessity, but I figure that other people might have similar issues) > > > As to the original discussion: I still strongly believe that toForm and > to/as(X)Html should not be in Mapper/Record. Different story for > JSON/XML/SQL - those seem to me to be rather functionality complete, no > problem. > But form and html creation seem to be something that most users will want > to adapt to their application's needs eventually - state dependent css > classes, javascript validation, AJAX form updates... In the examples that > I've seen so far, this functionality was dealt with in the snippet. So, > either mapper/record eventually become this super-omnipotent-mega-classes > that can deal with this functionality to > (field.toJavaScriptValidatingAndIncrementallyAjaxUpdatingForm ...), or > form/html generation happens in multiple locations, or the user has to > override some functions from mapper/record/fields. My beef with this is A) > that the respective function calls, given their current signature, require > the respective mapper/record-objects to be fully aware of application state > for more complex applications; and B) that it is my understanding that > overriding internal classes of a framework is a bad thing - I'd rather see a > proper application of the Hollywood principle. > Most web sites I've worked on, there's a default way to display a form and that default is encapsulated in the model itself. This encapsulation does not bar you from building your own form renders, but it does give you nice default behavior. > > Just wanted to provide an outsider's feedback. Overall, I think lift's just > fantastic. > > Thank you for listening/reading, > Clemens > > On 19-Mar-09, at 1:08 PM, marius d. wrote: > > > > > On Mar 18, 11:24 pm, Clemens wrote: > > Thank you for your patience, Marius. > > > Well you can use different RecordMeta implementations if you need to > > different representation of a record without sequential template > > change. So no state dependency. > > > , b I'm really not trying to be difficultut having multiple RecordMeta > > instances, for which the HTML output seems to be only one of many > > functionalities, seems to be shooting with canons at sparrows. Having > > a toForm functions that takes some template provider as input could be > > one option. > > > Well this is kinda already in there but it's private :) ... See: > > private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > so to me makes sense to relax it ... to > > public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > > ... thanks for reminding me about this :) > > > Anyways, I was not even thinking at record level, but rather at field > > level. See below. > > > Well keeping close view representation and backend abstraction makes a > > lot of sense as it reduces lots of complexity. Having records/mappers > > that know how to represent themselves in different contexts (DB, > > xhtml) brings a lot of benefits an simplicity. I admit thought that > > > (Btw, by "context" I meant different HTML display contexts.) > > > I agree that a field should be able to provide hints about how it > > should be represented, such as max/min length, type, defaults, etc. > > > Depending on the logical context within the app I'm working on, a > > record (and thus its fields) can have multiple representations: row in > > a table, complete record as a table, abbreviated record as a table, > > complete form as table, form as row in a table, form with mandatory > > fields only, records have to be printed out as ini-files, etc. > > Unfortunately, it's not me making this stuff up, it's fixed > > requirements. > > > At field level, there are also d
[Lift] Re: Forms & validation formatter
One follow up question, relating to the contexts I mentioned earlier:
Following my approach mentioned below, let's assume I have a template
for embedding. This template contains the HTML code for a tabular
list of data entities. Depending on where the template is embedded,
some of the entities' fields should appear as links: There are 2
linkable reference fields A and B, and depending on the context,
either A, B, or A and B should be rendered as links to the referenced
entity.
This logic obviously can't go into the template. Also, the model's
toForm method is unsuitable (having the model referring to a
RequestVar seems evil to me). No no, this should go into the snippet,
where such logic belongs. But this would mean having to go through the
templates XML tree before calling Site.toForm(site, form), enclosing
all affected liftf:field elements with the respective links. This
sounds very, very wrong.
Thus, from my current understanding, this context-sensitive rendering
of fields is best done using the explicit lift-tag/bind approach. So
I'll probably have to have explicit bind calls anyways, and won't be
able to use my initial approach of having the mapper class (or it's
companion object) fill out the forms itself.
I'd be happy if someone could prove me wrong ...
Best,
Clemens
PS: Exercise for the reader: Instead of selective linking, have only
either A or B be displayed, depending on the embedding context.
On 31-Mar-09, at 3:59 PM, marius d. wrote:
>>
>> Outer Template
>>
>>Create a New Site
>>
>>
>>
>>
>>
>>Submit
>>
>>
>>
>>
>>
>>
>> End Outer Template
>>
>> Embedded Template
>>
>>
>> Name:> td>
>> A Hospital Site
>>
>>
>>
>> End Embedded Template
>>
>> SiteOps
>>def add(form: NodeSeq): NodeSeq = {
>> val invokedAs = S.invokedAs
>> val site = Site.create
>>
>> def newSite(form: NodeSeq): NodeSeq = {
>>def saveMe(): Unit = {
>> site.validate match {
>>case Nil => site.save ; S.notice("Added " + site.name);
>> S.redirectTo("/sites/")
>>case xs => S.error(xs) ; S.mapSnippet(invokedAs, newSite)
>> }
>>}
>>
>>bind("site", Site.toForm(site, form), "submit" ->
>> submit("Save", saveMe))
>> }
>>
>> newSite(form)
>>}
>> End SiteOps
>>
>> The Site.toForm function is pretty much the same as found in
>> MetaRecord. It will eventually call each fields' toForm function
>> (which are the original Lift 1.0 mapper versions, no changes there).
>>
>> Am I really doing things outside the rendering pipeline (this is
>> not a
>> rhetorical question)?
>
> Nope sorry ... I misunderstood your case. By bad entirely.
>
> It all seems to work, incl. validation.
>> Also, the eagerly evaluated template, which will be passed to toForm,
>> contains only field tags, no other lift tags.
>>
>> Again, imagine a few dozen different entities, each with a ton of
>> fields. I'm sure you'll understand that I'm hesitant to bind each
>> field manually (once for the list page, once for the display page,
>> once for the add page, and again once for the edit page, even though
>> the last 2 can surely be combined into one bind call in the code).
>> I obviously have to declare each field in the model, and refer to it
>> in the view. I really wouldn't mind not having to mention it anywhere
>> inbetween.
>
> This is actually a nice thing to do. Sorry that I misunderstood your
> intentions :)
>
>>
>> Thank you for all your help,
>> Clemens
>>
>> Clemens Oertel
>> clem...@oertel.ca
> >
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
-~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Mar 31, 9:09 pm, Clemens Oertel wrote:
> Marius:
>
> On 31-Mar-09, at 12:31 PM, marius d. wrote:
>
>
>
> > On Mar 31, 5:06 pm, Clemens Oertel wrote:
> >> - Why not provide the same template mechanism used for forms for HTML
> >> output? This way I can reuse the same template for both - given that
> >> my records have at least dozens, if not even hundreds, of fields,
> >> that'd be a great help.
>
> > Well you can load templates from an html file. Please see
> > LiftSession.findAnyTemplate function.
>
> just thought that, since MetaRecord has
>
> def toForm(inst: BaseRecord): NodeSeq
> and
> def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq
>
> it would only be consistent to provide similar means for HTML output.
>
> > Well I can understand the urge but we do NOT recommend processing
> > templates outside of rendering pipeline. You can call
> > LiftSession.processSurroundAndInclude so that lift tags to be
> > processed etc. but again it is not recommended. The main reason is
> > that your functions that you assume to be bounded during this off-
> > cycle template processing, will not actually be bounded cause it i
> > happening in the wrong place.
>
> > The Record's form template is to allow you to shape the form in any
> > way you like (from markup perspective). But this template is supposed
> > to be very very lightweight in terms of lift's tags. It is just an
> > xhtml fragment and not a full blow page/(lift template).
>
> Mmh, maybe there's a misunderstanding. I was only using the template
> as indicated in the source code, or so I thought.
>
> May I just provide an abbreviated version of the code that I come up
> with?
>
> Outer Template
>
> Create a New Site
>
>
>
>
>
> Submit
>
>
>
>
>
>
> End Outer Template
>
> Embedded Template
>
>
> Name:
> A Hospital Site
>
>
>
> End Embedded Template
>
> SiteOps
> def add(form: NodeSeq): NodeSeq = {
> val invokedAs = S.invokedAs
> val site = Site.create
>
> def newSite(form: NodeSeq): NodeSeq = {
> def saveMe(): Unit = {
> site.validate match {
> case Nil => site.save ; S.notice("Added " + site.name);
> S.redirectTo("/sites/")
> case xs => S.error(xs) ; S.mapSnippet(invokedAs, newSite)
> }
> }
>
> bind("site", Site.toForm(site, form), "submit" ->
> submit("Save", saveMe))
> }
>
> newSite(form)
> }
> End SiteOps
>
> The Site.toForm function is pretty much the same as found in
> MetaRecord. It will eventually call each fields' toForm function
> (which are the original Lift 1.0 mapper versions, no changes there).
>
> Am I really doing things outside the rendering pipeline (this is not a
> rhetorical question)?
Nope sorry ... I misunderstood your case. By bad entirely.
It all seems to work, incl. validation.
> Also, the eagerly evaluated template, which will be passed to toForm,
> contains only field tags, no other lift tags.
>
> Again, imagine a few dozen different entities, each with a ton of
> fields. I'm sure you'll understand that I'm hesitant to bind each
> field manually (once for the list page, once for the display page,
> once for the add page, and again once for the edit page, even though
> the last 2 can surely be combined into one bind call in the code).
> I obviously have to declare each field in the model, and refer to it
> in the view. I really wouldn't mind not having to mention it anywhere
> inbetween.
This is actually a nice thing to do. Sorry that I misunderstood your
intentions :)
>
> Thank you for all your help,
> Clemens
>
> 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
-~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
Marius:
On 31-Mar-09, at 12:31 PM, marius d. wrote:
>
>
>
> On Mar 31, 5:06 pm, Clemens Oertel wrote:
>> - Why not provide the same template mechanism used for forms for HTML
>> output? This way I can reuse the same template for both - given that
>> my records have at least dozens, if not even hundreds, of fields,
>> that'd be a great help.
>
> Well you can load templates from an html file. Please see
> LiftSession.findAnyTemplate function.
just thought that, since MetaRecord has
def toForm(inst: BaseRecord): NodeSeq
and
def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq
it would only be consistent to provide similar means for HTML output.
> Well I can understand the urge but we do NOT recommend processing
> templates outside of rendering pipeline. You can call
> LiftSession.processSurroundAndInclude so that lift tags to be
> processed etc. but again it is not recommended. The main reason is
> that your functions that you assume to be bounded during this off-
> cycle template processing, will not actually be bounded cause it i
> happening in the wrong place.
>
> The Record's form template is to allow you to shape the form in any
> way you like (from markup perspective). But this template is supposed
> to be very very lightweight in terms of lift's tags. It is just an
> xhtml fragment and not a full blow page/(lift template).
Mmh, maybe there's a misunderstanding. I was only using the template
as indicated in the source code, or so I thought.
May I just provide an abbreviated version of the code that I come up
with?
Outer Template
Create a New Site
Submit
End Outer Template
Embedded Template
Name:
A Hospital Site
End Embedded Template
SiteOps
def add(form: NodeSeq): NodeSeq = {
val invokedAs = S.invokedAs
val site = Site.create
def newSite(form: NodeSeq): NodeSeq = {
def saveMe(): Unit = {
site.validate match {
case Nil => site.save ; S.notice("Added " + site.name);
S.redirectTo("/sites/")
case xs => S.error(xs) ; S.mapSnippet(invokedAs, newSite)
}
}
bind("site", Site.toForm(site, form), "submit" ->
submit("Save", saveMe))
}
newSite(form)
}
End SiteOps
The Site.toForm function is pretty much the same as found in
MetaRecord. It will eventually call each fields' toForm function
(which are the original Lift 1.0 mapper versions, no changes there).
Am I really doing things outside the rendering pipeline (this is not a
rhetorical question)? It all seems to work, incl. validation.
Also, the eagerly evaluated template, which will be passed to toForm,
contains only field tags, no other lift tags.
Again, imagine a few dozen different entities, each with a ton of
fields. I'm sure you'll understand that I'm hesitant to bind each
field manually (once for the list page, once for the display page,
once for the add page, and again once for the edit page, even though
the last 2 can surely be combined into one bind call in the code).
I obviously have to declare each field in the model, and refer to it
in the view. I really wouldn't mind not having to mention it anywhere
inbetween.
Thank you for all your help,
Clemens
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
-~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Mar 31, 5:06 pm, Clemens Oertel wrote: > Hello, > > Sorry for the delay in my response, but I only get to play with lift > on the weekends, and I wanted to look into your suggestions in more > detail. > > I ported the toForm code from Record to Mapper (and by port, I mean > mostly cut'n'paste). While doing so, I noticed 2 things: > > - Why not provide the same template mechanism used for forms for HTML > output? This way I can reuse the same template for both - given that > my records have at least dozens, if not even hundreds, of fields, > that'd be a great help. Well you can load templates from an html file. Please see LiftSession.findAnyTemplate function. > - The templates require the use of and similar tags. I > thought I'd be really smart, and created a HTML file A with lift-tags > (...) to run my snippet, and > used the tags as children to . This > way, I can create my templates externally, and use the normal lift > dispatch-from-view mechanism. And, to save me some more work, the > actual form template is in a separate, reusable, HTML file B, to be > embedded into A. Embedding, of course, requires eager evaluation. > Fine. No. With eager evaluation, lift of course complains that there > is no class "field", as referenced by . Now me's wondering > whether a separate namespace would be more appropriate? (I did switch > to a different namespace, liftf, out of necessity, but I figure that > other people might have similar issues) Well I can understand the urge but we do NOT recommend processing templates outside of rendering pipeline. You can call LiftSession.processSurroundAndInclude so that lift tags to be processed etc. but again it is not recommended. The main reason is that your functions that you assume to be bounded during this off- cycle template processing, will not actually be bounded cause it i happening in the wrong place. The Record's form template is to allow you to shape the form in any way you like (from markup perspective). But this template is supposed to be very very lightweight in terms of lift's tags. It is just an xhtml fragment and not a full blow page/(lift template). > > As to the original discussion: I still strongly believe that toForm > and to/as(X)Html should not be in Mapper/Record. Different story for > JSON/XML/SQL - those seem to me to be rather functionality complete, > no problem. > But form and html creation seem to be something that most users will > want to adapt to their application's needs eventually - state > dependent css classes, javascript validation, AJAX form updates... In > the examples that I've seen so far, this functionality was dealt with > in the snippet. So, either mapper/record eventually become this super- > omnipotent-mega-classes that can deal with this functionality to > (field.toJavaScriptValidatingAndIncrementallyAjaxUpdatingForm ...), or > form/html generation happens in multiple locations, or the user has to > override some functions from mapper/record/fields. My beef with this > is A) that the respective function calls, given their current > signature, require the respective mapper/record-objects to be fully > aware of application state for more complex applications; and B) that > it is my understanding that overriding internal classes of a framework > is a bad thing - I'd rather see a proper application of the Hollywood > principle. > > Just wanted to provide an outsider's feedback. Overall, I think lift's > just fantastic. I'm really glad you like Lift ! > > Thank you for listening/reading, > Clemens > > On 19-Mar-09, at 1:08 PM, marius d. wrote: > > > > > > > On Mar 18, 11:24 pm, Clemens wrote: > >> Thank you for your patience, Marius. > > >>> Well you can use different RecordMeta implementations if you need to > >>> different representation of a record without sequential template > >>> change. So no state dependency. > > >> , b I'm really not trying to be difficultut having multiple > >> RecordMeta > >> instances, for which the HTML output seems to be only one of many > >> functionalities, seems to be shooting with canons at sparrows. Having > >> a toForm functions that takes some template provider as input could > >> be > >> one option. > > > Well this is kinda already in there but it's private :) ... See: > > > private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > > so to me makes sense to relax it ... to > > > public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > > ... thanks for reminding me about this :) > > >> Anyways, I was not even thinking at record level, but rather at field > >> level. See below. > > >>> Well keeping close view representation and backend abstraction > >>> makes a > >>> lot of sense as it reduces lots of complexity. Having records/ > >>> mappers > >>> that know how to represent themselves in different contexts (DB, > >>> xhtml) brings a lot of benefits an simplicity. I admit thought that >
[Lift] Re: Forms & validation formatter
Hello, Sorry for the delay in my response, but I only get to play with lift on the weekends, and I wanted to look into your suggestions in more detail. I ported the toForm code from Record to Mapper (and by port, I mean mostly cut'n'paste). While doing so, I noticed 2 things: - Why not provide the same template mechanism used for forms for HTML output? This way I can reuse the same template for both - given that my records have at least dozens, if not even hundreds, of fields, that'd be a great help. - The templates require the use of and similar tags. I thought I'd be really smart, and created a HTML file A with lift-tags (...) to run my snippet, and used the tags as children to . This way, I can create my templates externally, and use the normal lift dispatch-from-view mechanism. And, to save me some more work, the actual form template is in a separate, reusable, HTML file B, to be embedded into A. Embedding, of course, requires eager evaluation. Fine. No. With eager evaluation, lift of course complains that there is no class "field", as referenced by . Now me's wondering whether a separate namespace would be more appropriate? (I did switch to a different namespace, liftf, out of necessity, but I figure that other people might have similar issues) As to the original discussion: I still strongly believe that toForm and to/as(X)Html should not be in Mapper/Record. Different story for JSON/XML/SQL - those seem to me to be rather functionality complete, no problem. But form and html creation seem to be something that most users will want to adapt to their application's needs eventually - state dependent css classes, javascript validation, AJAX form updates... In the examples that I've seen so far, this functionality was dealt with in the snippet. So, either mapper/record eventually become this super- omnipotent-mega-classes that can deal with this functionality to (field.toJavaScriptValidatingAndIncrementallyAjaxUpdatingForm ...), or form/html generation happens in multiple locations, or the user has to override some functions from mapper/record/fields. My beef with this is A) that the respective function calls, given their current signature, require the respective mapper/record-objects to be fully aware of application state for more complex applications; and B) that it is my understanding that overriding internal classes of a framework is a bad thing - I'd rather see a proper application of the Hollywood principle. Just wanted to provide an outsider's feedback. Overall, I think lift's just fantastic. Thank you for listening/reading, Clemens On 19-Mar-09, at 1:08 PM, marius d. wrote: > > > > On Mar 18, 11:24 pm, Clemens wrote: >> Thank you for your patience, Marius. >> >>> Well you can use different RecordMeta implementations if you need to >>> different representation of a record without sequential template >>> change. So no state dependency. >> >> , b I'm really not trying to be difficultut having multiple >> RecordMeta >> instances, for which the HTML output seems to be only one of many >> functionalities, seems to be shooting with canons at sparrows. Having >> a toForm functions that takes some template provider as input could >> be >> one option. > > Well this is kinda already in there but it's private :) ... See: > > private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > so to me makes sense to relax it ... to > > public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > > ... thanks for reminding me about this :) > >> >> Anyways, I was not even thinking at record level, but rather at field >> level. See below. >> >>> Well keeping close view representation and backend abstraction >>> makes a >>> lot of sense as it reduces lots of complexity. Having records/ >>> mappers >>> that know how to represent themselves in different contexts (DB, >>> xhtml) brings a lot of benefits an simplicity. I admit thought that >> >> (Btw, by "context" I meant different HTML display contexts.) >> >> I agree that a field should be able to provide hints about how it >> should be represented, such as max/min length, type, defaults, etc. >> >> Depending on the logical context within the app I'm working on, a >> record (and thus its fields) can have multiple representations: row >> in >> a table, complete record as a table, abbreviated record as a table, >> complete form as table, form as row in a table, form with mandatory >> fields only, records have to be printed out as ini-files, etc. >> Unfortunately, it's not me making this stuff up, it's fixed >> requirements. >> >> At field level, there are also different possible representations. >> For >> example, I would like to be able to represent a record as a tabular >> form, with every input field being shown with its preferred length. >> In >> addition to this, I would like to have a different form with a fixed >> with multi-column layout; for this form, no i
[Lift] Re: Forms & validation formatter
On Mar 19, 7:08 pm, "marius d." wrote: > On Mar 18, 11:24 pm, Clemens wrote: > > > Thank you for your patience, Marius. > > > > Well you can use different RecordMeta implementations if you need to > > > different representation of a record without sequential template > > > change. So no state dependency. > > >, b I'm really not trying to be difficultut having multiple RecordMeta > > instances, for which the HTML output seems to be only one of many > > functionalities, seems to be shooting with canons at sparrows. Having > > a toForm functions that takes some template provider as input could be > > one option. > > Well this is kinda already in there but it's private :) ... See: > > private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > so to me makes sense to relax it ... to > > public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq I used here on purpose ... :) > > ... thanks for reminding me about this :) > > > > > > > Anyways, I was not even thinking at record level, but rather at field > > level. See below. > > > > Well keeping close view representation and backend abstraction makes a > > > lot of sense as it reduces lots of complexity. Having records/mappers > > > that know how to represent themselves in different contexts (DB, > > > xhtml) brings a lot of benefits an simplicity. I admit thought that > > > (Btw, by "context" I meant different HTML display contexts.) > > > I agree that a field should be able to provide hints about how it > > should be represented, such as max/min length, type, defaults, etc. > > > Depending on the logical context within the app I'm working on, a > > record (and thus its fields) can have multiple representations: row in > > a table, complete record as a table, abbreviated record as a table, > > complete form as table, form as row in a table, form with mandatory > > fields only, records have to be printed out as ini-files, etc. > > Unfortunately, it's not me making this stuff up, it's fixed > > requirements. > > > At field level, there are also different possible representations. For > > example, I would like to be able to represent a record as a tabular > > form, with every input field being shown with its preferred length. In > > addition to this, I would like to have a different form with a fixed > > with multi-column layout; for this form, no input field must be wider > > than 40 characters. Somehow I have to tell the fields not to make > > themselves wider than 40 characters, and not just use the maximum > > length. > > > Again, what it boils down to is the desire to be able to have > > different representations for a single record, and to have different > > possible representations for each field. This while maintaining as > > much encapsulation as possible. > > Well for both mapper and record you have the toForm function which is > per field thus allows you to represent the field in any way you like: > your own Node, augment the default node with new attributes etc. And > your implementation can of choose the layout based on your own > context. > > > > > Hence my original idea to have fields provide representation hints > > (eg. "I'd like to be 80 characters wide"), and then have another > > "something" that uses these hints for the actual output, while > > potentially adding additional hints/constrains (eg. "No one get's more > > than 40 characters"), css directives, a little red star in front of > > mandatory fields (based on a rendering hint), Depending on how > > the record is being displayed, I would use a different "something", > > and neither the record nor the fields would have to know anything > > about "application context". > > Well since you can override the toForm for each field you can add your > own "something" to it. Thus you can work with necessary abstractions > to make the field "unaware" of the "application context" if that's > what you want but it feels to me that this is an application specific > concern and not a framework one. Personally if I'd need to render a > record/field in different layouts using mapper I'd probably make the > fields aware of the context in which they need to render themselves. > Context is good ! :) > > > > > If I then had a default "something", which renders fields the way they > > are rendered right now, and have the various record fields > > (StringField, etc.) call upon this default "something" whenever their > > toForm-function is called, no one would notice something has changed. > > But I could also call toForm(formRenderer) for non-default rendering. > > > > it's quire a paradigm shift from ... say MVC mindset. But let's not > > > get into a "patterns" debate now .. we had plenty of those :) > > > Agreed. > > > Best, > > Clemens --~--~-~--~~~---~--~~ 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 emai
[Lift] Re: Forms & validation formatter
On Mar 18, 11:24 pm, Clemens wrote: > Thank you for your patience, Marius. > > > Well you can use different RecordMeta implementations if you need to > > different representation of a record without sequential template > > change. So no state dependency. > >, b I'm really not trying to be difficultut having multiple RecordMeta > instances, for which the HTML output seems to be only one of many > functionalities, seems to be shooting with canons at sparrows. Having > a toForm functions that takes some template provider as input could be > one option. Well this is kinda already in there but it's private :) ... See: private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq so to me makes sense to relax it ... to public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq ... thanks for reminding me about this :) > > Anyways, I was not even thinking at record level, but rather at field > level. See below. > > > Well keeping close view representation and backend abstraction makes a > > lot of sense as it reduces lots of complexity. Having records/mappers > > that know how to represent themselves in different contexts (DB, > > xhtml) brings a lot of benefits an simplicity. I admit thought that > > (Btw, by "context" I meant different HTML display contexts.) > > I agree that a field should be able to provide hints about how it > should be represented, such as max/min length, type, defaults, etc. > > Depending on the logical context within the app I'm working on, a > record (and thus its fields) can have multiple representations: row in > a table, complete record as a table, abbreviated record as a table, > complete form as table, form as row in a table, form with mandatory > fields only, records have to be printed out as ini-files, etc. > Unfortunately, it's not me making this stuff up, it's fixed > requirements. > > At field level, there are also different possible representations. For > example, I would like to be able to represent a record as a tabular > form, with every input field being shown with its preferred length. In > addition to this, I would like to have a different form with a fixed > with multi-column layout; for this form, no input field must be wider > than 40 characters. Somehow I have to tell the fields not to make > themselves wider than 40 characters, and not just use the maximum > length. > > Again, what it boils down to is the desire to be able to have > different representations for a single record, and to have different > possible representations for each field. This while maintaining as > much encapsulation as possible. Well for both mapper and record you have the toForm function which is per field thus allows you to represent the field in any way you like: your own Node, augment the default node with new attributes etc. And your implementation can of choose the layout based on your own context. > > Hence my original idea to have fields provide representation hints > (eg. "I'd like to be 80 characters wide"), and then have another > "something" that uses these hints for the actual output, while > potentially adding additional hints/constrains (eg. "No one get's more > than 40 characters"), css directives, a little red star in front of > mandatory fields (based on a rendering hint), Depending on how > the record is being displayed, I would use a different "something", > and neither the record nor the fields would have to know anything > about "application context". Well since you can override the toForm for each field you can add your own "something" to it. Thus you can work with necessary abstractions to make the field "unaware" of the "application context" if that's what you want but it feels to me that this is an application specific concern and not a framework one. Personally if I'd need to render a record/field in different layouts using mapper I'd probably make the fields aware of the context in which they need to render themselves. Context is good ! :) > > If I then had a default "something", which renders fields the way they > are rendered right now, and have the various record fields > (StringField, etc.) call upon this default "something" whenever their > toForm-function is called, no one would notice something has changed. > But I could also call toForm(formRenderer) for non-default rendering. > > > it's quire a paradigm shift from ... say MVC mindset. But let's not > > get into a "patterns" debate now .. we had plenty of those :) > > Agreed. > > Best, > Clemens --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
Thank you for your patience, Marius. > Well you can use different RecordMeta implementations if you need to > different representation of a record without sequential template > change. So no state dependency. I'm really not trying to be difficult, but having multiple RecordMeta instances, for which the HTML output seems to be only one of many functionalities, seems to be shooting with canons at sparrows. Having a toForm functions that takes some template provider as input could be one option. Anyways, I was not even thinking at record level, but rather at field level. See below. > Well keeping close view representation and backend abstraction makes a > lot of sense as it reduces lots of complexity. Having records/mappers > that know how to represent themselves in different contexts (DB, > xhtml) brings a lot of benefits an simplicity. I admit thought that (Btw, by "context" I meant different HTML display contexts.) I agree that a field should be able to provide hints about how it should be represented, such as max/min length, type, defaults, etc. Depending on the logical context within the app I'm working on, a record (and thus its fields) can have multiple representations: row in a table, complete record as a table, abbreviated record as a table, complete form as table, form as row in a table, form with mandatory fields only, records have to be printed out as ini-files, etc. Unfortunately, it's not me making this stuff up, it's fixed requirements. At field level, there are also different possible representations. For example, I would like to be able to represent a record as a tabular form, with every input field being shown with its preferred length. In addition to this, I would like to have a different form with a fixed with multi-column layout; for this form, no input field must be wider than 40 characters. Somehow I have to tell the fields not to make themselves wider than 40 characters, and not just use the maximum length. Again, what it boils down to is the desire to be able to have different representations for a single record, and to have different possible representations for each field. This while maintaining as much encapsulation as possible. Hence my original idea to have fields provide representation hints (eg. "I'd like to be 80 characters wide"), and then have another "something" that uses these hints for the actual output, while potentially adding additional hints/constrains (eg. "No one get's more than 40 characters"), css directives, a little red star in front of mandatory fields (based on a rendering hint), Depending on how the record is being displayed, I would use a different "something", and neither the record nor the fields would have to know anything about "application context". If I then had a default "something", which renders fields the way they are rendered right now, and have the various record fields (StringField, etc.) call upon this default "something" whenever their toForm-function is called, no one would notice something has changed. But I could also call toForm(formRenderer) for non-default rendering. > it's quire a paradigm shift from ... say MVC mindset. But let's not > get into a "patterns" debate now .. we had plenty of those :) Agreed. Best, Clemens --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Mar 18, 8:54 pm, Clemens wrote: > > Yes I am referring to toForm but note that you can provide your own > > template. Please see formTemplate. > > I did, thanks for the pointer. formTemplate applies to the record as a > whole, right? If I want to render a record differently, I could set > different templates one after the other - even though this introduces > more evil state dependence. Well you can use different RecordMeta implementations if you need to different representation of a record without sequential template change. So no state dependency. > > Just trying to figure out how to how to solve my case where a field is > supposed to be rendered differently in different contexts - a single > asXHtml variable doesn't seem to allow this. > > Also, all the formatting happens in what I thought was the DB > abstraction layer, which still makes context-sensitive formatting > difficult (again, as I understand things right know) - it's just > personal style, but I like to keep control flow and view stuff outside > my data models. Well keeping close view representation and backend abstraction makes a lot of sense as it reduces lots of complexity. Having records/mappers that know how to represent themselves in different contexts (DB, xhtml) brings a lot of benefits an simplicity. I admit thought that it's quire a paradigm shift from ... say MVC mindset. But let's not get into a "patterns" debate now .. we had plenty of those :) > > But record promises to give me a lot more flexibility than mapper, > that's great. > > > I think the existent scaladocs can > > be quite helpful. > > Point taken ;-) > > > 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 ... > > Oh, the validation is working just fine with mapper. It's only the > lack of flexibility with respect to automated output that's I'm > talking about. I'm sorry maybe I'm missing something but can you give a Minimalistic example that would yield the lack of flexibility of Mapper for your needs? Perhaps we can improve things or perhaps certain things are already there waiting to be discovered. > > Best, > Clemens --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
> Yes I am referring to toForm but note that you can provide your own > template. Please see formTemplate. I did, thanks for the pointer. formTemplate applies to the record as a whole, right? If I want to render a record differently, I could set different templates one after the other - even though this introduces more evil state dependence. Just trying to figure out how to how to solve my case where a field is supposed to be rendered differently in different contexts - a single asXHtml variable doesn't seem to allow this. Also, all the formatting happens in what I thought was the DB abstraction layer, which still makes context-sensitive formatting difficult (again, as I understand things right know) - it's just personal style, but I like to keep control flow and view stuff outside my data models. But record promises to give me a lot more flexibility than mapper, that's great. > I think the existent scaladocs can > be quite helpful. Point taken ;-) > 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 ... Oh, the validation is working just fine with mapper. It's only the lack of flexibility with respect to automated output that's I'm talking about. Best, Clemens --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Mar 18, 1:30 pm, Clemens Oertel 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 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 {
> >
[Lift] Re: Forms & validation formatter
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,
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 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.
[Lift] Re: Forms & validation formatter
FWIW please also take a look on Record and form&validation support.
Br's,
Marius
On Mar 17, 11:07 pm, Clemens Oertel 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
