On Mon, Feb 15, 2010 at 4:06 PM, Kris Nuttycombe
<kris.nuttyco...@gmail.com>wrote:
> On Mon, Feb 15, 2010 at 4:31 PM, David Pollak
> <feeder.of.the.be...@gmail.com> wrote:
> > If all the SHtml stuff returned a NodeSeq (or Elem) with AnswerHolder and
> > AnswerHolder[T] looked like:
> >
> > trait AnswerHolder[T] {
> > def hasAnswer: Boolean
> > def answer: Box[T]
> > def map[S](f: T => S): Box[S]
> > ...
> > }
> >
> > Then we could get what you want (no explicit mutability) and keep APIs
> > working the way they work now. What do you think?
> >
> > We could even introduce alternative SHtml stuff like:
> >
> > def text(original: String): Elem with AnswerHolder[String]
> >
> > What do you think?
>
> That looks good; I think it'd go a long way toward making the order of
> operations a little more foolproof. The idea of 'Elem with
> AnswerHolder' had never occurred to me; I guess I just always assumed
> that Elem or Node was sealed, but it doesn't appear to be from the
> scaladocs. That would certainly help on the backwards compatibility
> front and would alleviate the need for the implicit conversion I'd
> imagined from FormField[T] to NodeSeq.
>
> What do you think about the notion of a "!" method that does the
> unsafe answer.open_! ?
Sure.
> I would think that in the vast majority of
> cases, the Box being Empty would represent either a coding error or a
> framework error. In the case of a coding error (the answer attempting
> to be extracted during the initial rendering of the form elements)
> this would fail fast, and in the case where the response is actually
> being processed it should probably never be empty anyway.
>
Can you open a ticket and assign it to me and mark it for M4 referencing
this thread?
>
> Kris
>
> >
> > On Mon, Jan 25, 2010 at 11:31 AM, Kris Nuttycombe
> > <kris.nuttyco...@gmail.com> wrote:
> >>
> >> On Mon, Jan 25, 2010 at 12:16 PM, David Pollak
> >> <feeder.of.the.be...@gmail.com> wrote:
> >> >
> >> >
> >> > On Mon, Jan 25, 2010 at 11:09 AM, Kris Nuttycombe
> >> > <kris.nuttyco...@gmail.com> wrote:
> >> >>
> >> >> On Mon, Jan 25, 2010 at 11:51 AM, Kris Nuttycombe
> >> >> <kris.nuttyco...@gmail.com> wrote:
> >> >> > On Mon, Jan 25, 2010 at 11:40 AM, David Pollak
> >> >> > <feeder.of.the.be...@gmail.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >> On Mon, Jan 25, 2010 at 10:19 AM, Kris Nuttycombe
> >> >> >> <kris.nuttyco...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> On Mon, Jan 25, 2010 at 11:07 AM, Marius <
> marius.dan...@gmail.com>
> >> >> >>> wrote:
> >> >> >>> > S.formFuncName .. should guarantee proper ordering of functions
> >> >> >>> > application respecting the ordering of functions creation (and
> >> >> >>> > this
> >> >> >>> > is
> >> >> >>> > used by fmapFunc).
> >> >> >>> >
> >> >> >>> > I'm a bit tired to follow code from this page so could you
> please
> >> >> >>> > put
> >> >> >>> > together a minimalistic application that I could just try?
> >> >> >>> >
> >> >> >>> > Br's,
> >> >> >>> > Marius
> >> >> >>>
> >> >> >>> Thanks, Marius, but I'm too time-crunched at the moment to boil
> >> >> >>> this
> >> >> >>> down. In any case, I found a solution. My frustration is
> primarily
> >> >> >>> that ordering of function creation matters in the first place;
> >> >> >>> making
> >> >> >>> the ordering of function creation less relevant is the point of
> my
> >> >> >>> proposal in the other thread. If the order that you do things in
> >> >> >>> matters, it completely hoses you for the purposes of composition
> >> >> >>> (as I
> >> >> >>> painfully found out with this example.) Here, the composition is
> >> >> >>> just
> >> >> >>> two calls deep and explicit, and even with only that small amount
> >> >> >>> of
> >> >> >>> composition it was a pain to track down.
> >> >> >>>
> >> >> >>> Does this make my proposal in the other thread make any more
> sense
> >> >> >>> to
> >> >> >>> you?
> >> >> >>
> >> >> >> Ordering is well defined:
> >> >> >>
> >> >> >> The order in which the functions are mapped
> >> >> >> Skewed plus or minus based on value of S.formGroup
> >> >> >>
> >> >> >> There's no way to avoid ordering. The functions have to be
> executed
> >> >> >> in
> >> >> >> some
> >> >> >> order. By default, the stuff in SHtml does this in the order the
> >> >> >> elements
> >> >> >> were defined, but sets S.formGroup to 1 for the submit button (so
> >> >> >> it's
> >> >> >> always the last function executed.)
> >> >> >
> >> >> > They have to be executed in some order; I just wish that the
> >> >> > execution
> >> >> > could actually be performed by user code! That's the whole point of
> >> >> > my
> >> >> > suggestion from the other thread.
> >> >> >
> >> >> >> More broadly, I think you might want to look at what I did with
> >> >> >> Screen
> >> >> >> and
> >> >> >> Wizard. These are declarative mechanisms for defining forms,
> >> >> >> validations,
> >> >> >> and behaviors. Where are these not working for you?
> >> >> >
> >> >> > I simply haven't had the time to port thousands of lines of form
> code
> >> >> > I've already written over to stuff on SNAPSHOT. I was supposed to
> >> >> > have
> >> >> > this stuff released last Friday; my intention was to release on M8
> >> >> > since I haven't had time to test SNAPSHOT adequately because I've
> >> >> > been
> >> >> > hunting down order of evaluation bugs.
> >> >> >
> >> >> > Kris
> >> >>
> >> >> More to the point, I think that with a slight modification in design,
> >> >> I wouldn't *have* to think about order of evaluation. The fact that
> >> >> it's exposed (and has been, for me, an infuriating source of bugs) is
> >> >> a design smell.
> >> >
> >> > But something's going to have to trigger the evaluation of the
> >> > functions.
> >> > If everything is passive, then how does your "the form is submitted,
> now
> >> > start pulling the rest of the form elements in" stuff work?
> >> >
> >> > Since we moved to the S.formGroup stuff, other than this thread, there
> >> > has
> >> > not been an issue with form evaluation order, so tossing around
> "design
> >> > smell" doesn't necessarily sit well.
> >> >
> >> > Let's go back to what you're trying to accomplish. I'm not
> >> > understanding
> >> > that at the top level (I haven't read through your Ajax posts, but
> will
> >> > try
> >> > to get to them today). What's the delta between what you're trying to
> >> > accomplish and the current state of the Screen/Wizard stuff?
> >>
> >> I think what I'm trying to accomplish is at a somewhat lower level
> >> than what Screen/Wizard is targeted at. The paste at
> >> http://paste.pocoo.org/show/169908/ is an example of what I'm trying
> >> to do, where order of operations has fouled me up. In the "before"
> >> example, the function passed in gets evaluated with the correct value
> >> from the radio button, but since the dateField was inline, it has not
> >> yet been evaluated at the time of processing of the form that
> >> contained it.
> >>
> >> It just seems really bad to me that inlining something has different
> >> behavior than does assigning it to a val and then using the val. This
> >> is totally nonobvious to me, at least.
> >>
> >> The essence of my suggestion from the other thread is this; get rid of
> >> the var in the following snippet:
> >>
> >> def mySnippet(xhtml: NodeSeq) {
> >> var a: Option[String] = None
> >>
> >> bind("a", xhtml,
> >> "value" -> text("". s => a = Some(s)),
> >> "submit" -> submit("Submit", () => a.foreach(doSomething _)
> >> )
> >> }
> >>
> >> With my proposal, this would become:
> >>
> >> def mySnippet(xhtml: NodeSeq) {
> >> val aField = text("s", s => s)
> >>
> >> bind("a", xhtml,
> >> "value" -> aField,
> >> "submit" -> submit("Submit", () => doSomething(aField!))
> >> )
> >> }
> >>
> >> If you eliminate the var, you eliminate any questions with respect to
> >> order of operations. I think that this is valuable with or without
> >> your Screen/Wizard changes, unless the intent is to get rid of the
> >> SHtml.* methods for form fields entirely.
> >>
> >> Kris
> >>
> >>
> >> >>
> >> >> Kris
> >> >>
> >> >> --
> >> >> 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<liftweb%2bunsubscr...@googlegroups.com>
> .
> >> >> For more options, visit this group at
> >> >> http://groups.google.com/group/liftweb?hl=en.
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Lift, the simply functional web framework http://liftweb.net
> >> > Beginning Scala http://www.apress.com/book/view/1430219890
> >> > Follow me: http://twitter.com/dpp
> >> > Surf the harmonics
> >> >
> >> > --
> >> > 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<liftweb%2bunsubscr...@googlegroups.com>
> .
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/liftweb?hl=en.
> >> >
> >>
> >> --
> >> 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<liftweb%2bunsubscr...@googlegroups.com>
> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/liftweb?hl=en.
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
> > --
> > 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<liftweb%2bunsubscr...@googlegroups.com>
> .
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
>
> --
> 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<liftweb%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
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.
