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.