I would actaully use:
var inputString: Box[String] = Empty .
However I'm not sure if toForm should be implemented like that. I'd
rather let the refinements to decide when to render the inputString or
the actual value. But it's an implementation detail mostly
I think that we should apply this concept in both Mapper and Record.
So from my perspective I think you should open a defect.
Br's,
Marius
On Dec 25, 3:57 am, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> Currently the "workflow" of field validation in Mapper often goes as follows
> (not using ajax):
> User loads a page containing say fields generated by toForm on the field or
> the mapper
> User presses save, submitting his data
> The data goes into the fields
> Validators are called and one fails so instead of saving and redirecting
> the same page is loaded
> The inputs contain the values in the MappedFields, some of which need to
> be modified so the mapper can be saved. Messages are displayed indicating the
> problem with whichever field.
>
> There is one serious limitation of this sequence which is that it uses
> validators that operate on data in the field and act as a gatekeeper
> preventing them from going from the mapper into the database. They do not
> deal with values that can't get into the mapper in the first place! So if you
> enter a date and it parses incorrectly you don't get to edit it but a blank
> field and message telling you what you did wrong but not showing your input
> for reference.
> It's not really the job of a validator. The MappedFields already decide
> whether a string input can be parsed in--they just leave no tracks.
> This is also relevant when
> def f(x: String) = {field.setFromAny(x); field.is.toString==x}
> is false.
> I'm interested in hearing whatever suggestions and thoughts people have, but
> here's my suggestion.
> My opinion is that MappedField or one of the common base traits should have a
> member to remember the input string.
> Or maybe better yet something along these lines:
> trait FormField {
> type T
> def is: T
> var inputString: Option[String] = None
> def parseIn(s: String) = inputString = Some(s) // subclasses should
> override and call super
> def formXml(name, String, value: String): NodeSeq
> def toForm: NodeSeq = S.fmapFunc((s:List[String])=>parseIn(s))(name =>
> formXml(name, inputString.getOrElse(value))}
>
> (Vague sketch)
> In other words, the concept of an html form provider could be moved to its
> own trait, which could provide logic for trapping parse errors, and
> MappedField could inherit from that trait.
> Thoughts?
> Thanks.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
