The simplest answer is to use traits to define logic and when you have a page that's going to have multiple logic pieces that need to keep track of each other's state, mix the traits into a larger stateful snippet.
I'm sorry that I've been giving you half-answers to a lot of your questions... I know you've stated parts of your problem in a number of different posts, but if I could trouble you to put together a more complete description of the pages, components and interactions, I can try to work up a complete example that might help. On Wed, Mar 10, 2010 at 8:02 AM, hexa <hex...@gmail.com> wrote: > ok,, > > I don't want to put them in a single snippet since I want to be able > to use them independently .. > > I could call one snippet from the other I guess this would work but > just doesn't feel right... I would end up > having to do one snippet per page to control the subsnippets... > > In fact i'm not sure how I can "compose" independent even non > stateful snippets... without having an enclosing > "controler" snippet > > Best would be if non-stateful snippets could find each other for > example could I have something like > > <lift::SnippetA> > <lift:SnippetB> > </lift:SnippetB> > </lift::SnippetA> > > And have snippet B find the snippet A instance ? and modify it's > rendering based on it ? or something similar? > This way my list Invoice could know what it's in a AddInvoice > snippet and get the Client it must show the invoices for .. > And otherwise just render all invoices... > Having it in another context could make it render different > things... > > Or would I really have to bind SnippetB inside SnippetA with > chooseTemplate and directly call it's functions with the arguments I > need ? and do this all top-down... rather then down-top... > > So basically I guess the question is how do you manage multiple > snippets (non-stateful) so that they are the most independent from > each other and that code can reused and scoped properly if they have > any effect on each other and or that they can enclose each other... > > Maybe I"m way off too ,, sorry , Help is much apreciated... > > I will try the ajax way too, and I guess I could repost the > RequestVar.. need to try that too.. > > Thanks, > > hexa > > > On Mar 10, 9:33 am, David Pollak <feeder.of.the.be...@gmail.com> > wrote: > > The short answer is "no". > > > > The slightly longer answer is "Can you put both into a single snippet?" > > > > The even longer answer is "Have you tried using Ajax forms so you don't > even > > leave the page?" > > > > > > > > On Tue, Mar 9, 2010 at 10:19 PM, hexa <hex...@gmail.com> wrote: > > > Hi, > > > I have 2 Stateful snippets in a page : > > > > > 1. a InvoiceList snippet that > > > > > 1. If no client RequestVar is present lists all the invoices in the > > > system > > > 2. If a client RequestVar is present lists the invoices for that > > > client > > > > > 2. a AddInvoice snippet that displays a form and adds an invoice > > > binded on the Client RequestVar.. > > > > > Now these 2 can share the same RequestVar.. and that's fine for one > > > request > > > > > And at least in the case of 1 stateful snippet since I set the request > > > var to a class var , it persists after a submit on the AddInvoice... > > > the client persists > > > > > But for the other snippet .. the state is lost... > > > > > So is there a way to manage the common states of multiple snippets in > > > a page ? Should I use a SessionVar ? I kinda would prefer not to > > > since It's really not a var that should be persistent over the > > > session.... > > > > > The best would be that they both keep their state .. as an action is > > > performed on one of them... > > > > > Thanks a lot > > > > > hexa > > > > > -- > > > 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> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroups.com> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/liftweb?hl=en. > > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://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. > > -- 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.
