How would this be used?
2010/2/15 David Pollak <feeder.of.the.be...@gmail.com>
> 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?
>
>
> 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.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
