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_! ? 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.
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.
>> >> 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.
>> >
>>
>> --
>> 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.
>>
>
>
>
> --
> 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.
>
--
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.
