[Lift] Re: Tabbed browsing and "session" state
On Sep 26, 10:38 am, tiro wrote: > Hi, > has anyone investigated or built a way to support tabbed browsing when > there is considerable view/workflow state? Or have I missed an elegant > way for this to be done in Lift? There is a rather recent wizard code in lift that Dave added (and I haven't looked on it yet :) ... ) that could potentially apply here? > > If I am not mistaken, Lift currently supports > 1. Sending continuations (things that will need to be done) from one > Request to the next in the form of FuncHolders that are attached to an > ID that is unique for a sent page. This works perfectly in a tabbed > environment, and you can send state this way, but the state doesn't > live on in the response sent by the snippet that has received it. No your function that is called upon a request, receives the data. That data needs to be preserved into a RequestVar, SessionVar or into a StatefulSnippet so that when rendering phase starts that value is visible by the snippet itself. Function ID-s are generated for each page rendering. This is important for security reasons. > 2. Session variables that are global to the session, as well as > 3. Stateful snippets that are instantiated at most once in each > session. Not necessarily. You can preserve a StatefulSnippet's reference if you're using the functions exposed by it such as link or redirectTo. Also using a StatefulSnippet as a form preserves its reference. Otherwise the StatefulSnippet reference is not kept in LiftSession. > When assuming that your user knows how to browse tabbed, I can > currently not imagine what 2. and 3. could be practically useful for. > Very often though, it seems, people use these mechanisms and then > later realize the mess they are in. > > E.g. (quite > funny)http://www.highdots.com/forums/javascript/browser-tab-269390.html > More > serious:http://www.codeodor.com/index.cfm/2007/7/19/Why-tabbed-browsing-makes... > > A simple example from an application I'm developing, and I'll bet more > than half of all Web apps, is this: I have one page where users can > search for a bunch of documents in a database (search form and result > list are on the same page - let's not make it too complicated). > Clicking on a result will navigate to the detail view of a document. I > am sure sooner or later the customer will want a link on the detail > view to go back to the search he came from. > > If I put the last search parameters used into Session Vars, this will > not work if the customer uses several such result lists in parallel > (not unrealistic in this case). He will always end up going back to > the last search used, not the one that was used to open the detail > view. Very bad behavior for example when the user has edited an item, > and it then "vanishes" from his view. > > What would work is: put the search parameters into hidden fields and/ > or URL parameters of the detail view. But you break your fingers doing > that and it gets really messy when the detail view can be opened from > several different context, and the conversation that takes you back to > the original context has several steps. There is also a limit to what > you can put into a URL, I believe. You use a framework because it > saves you these kinds of headaches. > > It seems to me, Lift already has 80% of what it takes for a great > solution. It is the mechanism mentioned under 1. Any tab that is still > open calls home regularly to say "I'm still here, don't forget me". Depends how you are building your tabs. If your tab is a totally different page than the state should be preserved on the server and the dedicated place is a SessionVar. But you could build your tabs as being part of the same page, hence changing the tabs becomes a matter of making divs visible/hidden and this implies not server hits. Just JavaScript. This will allow you to navigate from one tab to another pretty fast => a better user experience. > This is good because otherwise we would have to consider any page ever > sent to the client to still be open and come back to haunt us, > demanding us to behave as if nothing had happened since. The existing > mechanism would only need to allow the state to be passed on, with a > delta, to the next response-request episode. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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] Re: Tabbed browsing and "session" state
I think what you want is StatefulSnippet. They're lifetime is not the session--it's as long as you keep it alive. Basically Lift maintains a registry of stateful snippets in each request. When a snippet is needed (referenced in a template), if an instance exists in the registry that instance is used; otherwise a new one is instantiated and registered. Thus if it's referenced in two places on one page, this same instance will be reused. If you want the same instance to be used in a future page, ultimately what has to happen is that a callback that will be executed in the future request must have a reference to the old snippet instance, and register it. You can effect this manually by calling registerThisSnippet on the snippet in say a hidden field. StatefulSnippet has a link method that's like SHtml.link but it calls registerThisSnippet. Also a submit button (at least SHtml.submit) that goes to the same page maintans the same snippet instance; I forgot how. But without keeping the StatefulSnippet alive, the instance will not be preserved; and by the same token, you can keep several stateful snippets alive, as long as it's one per request. However this only works when the orignal instance was provided by lift. In order for registerThisSnippet to work, lift has to have provided the snippet with a name. An alternative solution is S.mapSnippet. This allows you to short circuit the snippet lookup mechanism for a single request (at a time). You specify a snippet name, exactly as it occurs in the template, not including "lift:", and a function. If you have a snippet instance you can pass its snippet method as the function here. Of course, the snippet method can call mapSnippet itself. So each search results link can have a callback function that sets up a snippet corresponding to that link, and calls mapSnippet so that that instance's snippet functions will be used in the page linked to. - tiro wrote: Hi, has anyone investigated or built a way to support tabbed browsing when there is considerable view/workflow state? Or have I missed an elegant way for this to be done in Lift? If I am not mistaken, Lift currently supports 1. Sending continuations (things that will need to be done) from one Request to the next in the form of FuncHolders that are attached to an ID that is unique for a sent page. This works perfectly in a tabbed environment, and you can send state this way, but the state doesn't live on in the response sent by the snippet that has received it. 2. Session variables that are global to the session, as well as 3. Stateful snippets that are instantiated at most once in each session. When assuming that your user knows how to browse tabbed, I can currently not imagine what 2. and 3. could be practically useful for. Very often though, it seems, people use these mechanisms and then later realize the mess they are in. E.g. (quite funny) http://www.highdots.com/forums/javascript/browser-tab-269390.html More serious: http://www.codeodor.com/index.cfm/2007/7/19/Why-tabbed-browsing-makes-holding-form-state-with-sessions-obsolete/1470 A simple example from an application I'm developing, and I'll bet more than half of all Web apps, is this: I have one page where users can search for a bunch of documents in a database (search form and result list are on the same page - let's not make it too complicated). Clicking on a result will navigate to the detail view of a document. I am sure sooner or later the customer will want a link on the detail view to go back to the search he came from. If I put the last search parameters used into Session Vars, this will not work if the customer uses several such result lists in parallel (not unrealistic in this case). He will always end up going back to the last search used, not the one that was used to open the detail view. Very bad behavior for example when the user has edited an item, and it then "vanishes" from his view. What would work is: put the search parameters into hidden fields and/ or URL parameters of the detail view. But you break your fingers doing that and it gets really messy when the detail view can be opened from several different context, and the conversation that takes you back to the original context has several steps. There is also a limit to what you can put into a URL, I believe. You use a framework because it saves you these kinds of headaches. It seems to me, Lift already has 80% of what it takes for a great solution. It is the mechanism mentioned under 1. Any tab that is still open calls home regularly to say "I'm still here, don't forget me". This is good because otherwise we would have to consider any page ever sent to the client to still be open and come back to haunt us, demanding us to behave as if nothing had happened since. The existing mechanism would only need to allow the state to be passed on, with a delta, to the next response-request episode. --~--~-~--~---
[Lift] How to share request scope data among snippets in Lift
Hi. If my lift application have some data that cost to create, and I want to share it among snippets, how to do in Lift? if such data are shared inside one snippet, I may use "lazy val". But I have no nice idea to share it among different snippts. Thanks much. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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] Re: How to share request scope data among snippets in Lift
Take a look at RequestVar... If he were to just use a object singleton he might end up being not thread safe. Cheers Tim Sent from my iPhone On 26 Sep 2009, at 14:05, Kevin Wright wrote: > > You could always try putting your lazy val inside a singleton object > > On Sat, Sep 26, 2009 at 8:14 AM, ishiijp > wrote: >> >> Hi. >> >> If my lift application have some data that cost to create, and I want >> to share it among snippets, how to do in Lift? >> >> if such data are shared inside one snippet, I may use "lazy val". >> But I have no nice idea to share it among different snippts. >> >> Thanks much. >> >>> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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] Re: How to share request scope data among snippets in Lift
To share information between snippets during a request, use a RequestVar:
object MyInfo extends RequestVar(calculate_value)
so
object MyInfo extends RequestVar[Box[Invoice]](Empty)
in one snippet, you may calculate the Invoice and put it in the MyInfo:
MyInfo.set(Full(invoice))
In another snippet, you can extract:
for {
invoice <- MyInfo.is
} yield ...
Note that the "calculate_value" is a call-by-name parameter, so it will be
invoked each time the RequestVar is uninitialized. You can place lazy
calculation logic in here.
On Sat, Sep 26, 2009 at 12:14 AM, ishiijp wrote:
>
> Hi.
>
> If my lift application have some data that cost to create, and I want
> to share it among snippets, how to do in Lift?
>
> if such data are shared inside one snippet, I may use "lazy val".
> But I have no nice idea to share it among different snippts.
>
> Thanks much.
>
> >
>
--
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 liftweb@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] Re: ProtoUser superUser versus Role
I have a bad habit of posting before investigating. net.liftweb.http.auth.AuthRole ...does exactly what I need. Thanks guys! On Sep 25, 5:12 pm, Juan M Uys wrote: > Hello, > > I'm implementing a Role in my model to ultimately replace the > functionality provided by ProtoUser.superUser > > Please let me know what the argument against having this functionality > in Lift is, and if you'd like to see this implemented, I'd gladly > commit my changes. > > Please also suggest sensible defaults. I would imagine initialroleslike: > 0=super > 1=normal > ...and then setting new User instances to role=1. > > Thanks, > Juan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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] Re: How to share request scope data among snippets in Lift
On Sat, Sep 26, 2009 at 6:40 AM, Kevin Wright wrote:
>
> If the information is created just once and then used across multiple
> requests, it'll be a lazy val in a singleton
>
A lazy val in a singleton will not work.
Once it's calculated, it's calculated and cannot be changed for the life of
the singleton. If the singleton is global scope, you're really hosed.
RequestVars are the Lift way of sharing information across snippets on a
request-by-request basis.
If you want lazy evaluation of the RequestVar:
object Invoice extends RequestVar(S.param("invoice_id").flatMap(id =>
Invoice.find(id))) // type inferred to Box[Invoice]
If you want to share information across the scope of your session, use a
SessionVar.
SessionVar works exactly like RequestVar, but the lifespan of the SessionVar
is your session.
>
> If it's request-dependent then it'll be a singleton extending RequestVar
>
> Sadly, the OP didn't specify what was needed :(
>
>
> On Sat, Sep 26, 2009 at 2:35 PM, Timothy Perrett
> wrote:
> >
> > Take a look at RequestVar... If he were to just use a object singleton
> > he might end up being not thread safe.
> >
> > Cheers
> >
> > Tim
> >
> > Sent from my iPhone
> >
> > On 26 Sep 2009, at 14:05, Kevin Wright
> > wrote:
> >
> >>
> >> You could always try putting your lazy val inside a singleton object
> >>
> >> On Sat, Sep 26, 2009 at 8:14 AM, ishiijp
> >> wrote:
> >>>
> >>> Hi.
> >>>
> >>> If my lift application have some data that cost to create, and I want
> >>> to share it among snippets, how to do in Lift?
> >>>
> >>> if such data are shared inside one snippet, I may use "lazy val".
> >>> But I have no nice idea to share it among different snippts.
> >>>
> >>> Thanks much.
> >>>
>
> >>>
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>
--
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 liftweb@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] Re: How to share request scope data among snippets in Lift
On Sat, Sep 26, 2009 at 2:54 PM, David Pollak
wrote:
>
>
> On Sat, Sep 26, 2009 at 6:40 AM, Kevin Wright
> wrote:
>>
>> If the information is created just once and then used across multiple
>> requests, it'll be a lazy val in a singleton
>
> A lazy val in a singleton will not work.
> Once it's calculated, it's calculated and cannot be changed for the life of
> the singleton. If the singleton is global scope, you're really hosed.
> RequestVars are the Lift way of sharing information across snippets on a
> request-by-request basis.
> If you want lazy evaluation of the RequestVar:
> object Invoice extends RequestVar(S.param("invoice_id").flatMap(id =>
> Invoice.find(id))) // type inferred to Box[Invoice]
> If you want to share information across the scope of your session, use a
> SessionVar.
> SessionVar works exactly like RequestVar, but the lifespan of the SessionVar
> is your session.
>
The OP never actually stated "share between snippets across a session"
or "share between snippets across a request". It was simply "share
between snippets"
Almost certainly SessionVar or RequestVar are what will be needed, but
what if the data is truly global in nature? Something like the 2001
average world exchange rates vs USD, which requires a costly
webservice or database lookup to find.
The original request was vague, but global caching is definitely one
possible interpretation of what was wanted.
>>
>> If it's request-dependent then it'll be a singleton extending RequestVar
>>
>> Sadly, the OP didn't specify what was needed :(
>>
>>
>> On Sat, Sep 26, 2009 at 2:35 PM, Timothy Perrett
>> wrote:
>> >
>> > Take a look at RequestVar... If he were to just use a object singleton
>> > he might end up being not thread safe.
>> >
>> > Cheers
>> >
>> > Tim
>> >
>> > Sent from my iPhone
>> >
>> > On 26 Sep 2009, at 14:05, Kevin Wright
>> > wrote:
>> >
>> >>
>> >> You could always try putting your lazy val inside a singleton object
>> >>
>> >> On Sat, Sep 26, 2009 at 8:14 AM, ishiijp
>> >> wrote:
>> >>>
>> >>> Hi.
>> >>>
>> >>> If my lift application have some data that cost to create, and I want
>> >>> to share it among snippets, how to do in Lift?
>> >>>
>> >>> if such data are shared inside one snippet, I may use "lazy val".
>> >>> But I have no nice idea to share it among different snippts.
>> >>>
>> >>> Thanks much.
>> >>>
>>
>> >>>
>> >>
>> >> >
>> >>
>> >
>> > >
>> >
>>
>>
>
>
>
> --
> 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 liftweb@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] Tabbed browsing and "session" state
Hi, has anyone investigated or built a way to support tabbed browsing when there is considerable view/workflow state? Or have I missed an elegant way for this to be done in Lift? If I am not mistaken, Lift currently supports 1. Sending continuations (things that will need to be done) from one Request to the next in the form of FuncHolders that are attached to an ID that is unique for a sent page. This works perfectly in a tabbed environment, and you can send state this way, but the state doesn't live on in the response sent by the snippet that has received it. 2. Session variables that are global to the session, as well as 3. Stateful snippets that are instantiated at most once in each session. When assuming that your user knows how to browse tabbed, I can currently not imagine what 2. and 3. could be practically useful for. Very often though, it seems, people use these mechanisms and then later realize the mess they are in. E.g. (quite funny) http://www.highdots.com/forums/javascript/browser-tab-269390.html More serious: http://www.codeodor.com/index.cfm/2007/7/19/Why-tabbed-browsing-makes-holding-form-state-with-sessions-obsolete/1470 A simple example from an application I'm developing, and I'll bet more than half of all Web apps, is this: I have one page where users can search for a bunch of documents in a database (search form and result list are on the same page - let's not make it too complicated). Clicking on a result will navigate to the detail view of a document. I am sure sooner or later the customer will want a link on the detail view to go back to the search he came from. If I put the last search parameters used into Session Vars, this will not work if the customer uses several such result lists in parallel (not unrealistic in this case). He will always end up going back to the last search used, not the one that was used to open the detail view. Very bad behavior for example when the user has edited an item, and it then "vanishes" from his view. What would work is: put the search parameters into hidden fields and/ or URL parameters of the detail view. But you break your fingers doing that and it gets really messy when the detail view can be opened from several different context, and the conversation that takes you back to the original context has several steps. There is also a limit to what you can put into a URL, I believe. You use a framework because it saves you these kinds of headaches. It seems to me, Lift already has 80% of what it takes for a great solution. It is the mechanism mentioned under 1. Any tab that is still open calls home regularly to say "I'm still here, don't forget me". This is good because otherwise we would have to consider any page ever sent to the client to still be open and come back to haunt us, demanding us to behave as if nothing had happened since. The existing mechanism would only need to allow the state to be passed on, with a delta, to the next response-request episode. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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] Re: How to share request scope data among snippets in Lift
You could always try putting your lazy val inside a singleton object On Sat, Sep 26, 2009 at 8:14 AM, ishiijp wrote: > > Hi. > > If my lift application have some data that cost to create, and I want > to share it among snippets, how to do in Lift? > > if such data are shared inside one snippet, I may use "lazy val". > But I have no nice idea to share it among different snippts. > > Thanks much. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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] Re: How to stop validations if previous validator returns error.
Very nice! thanks a lot!!
On 9月15日, 午前4:08, David Pollak wrote:
> I'll check code in after it passes the reviewboard process that let's you
> mix in:
> trait StopValidationOnError[T] extends Function1[T, List[FieldError]]
>
> to a validation function such that the validator will stop processing a
> given field if a validator that has that trait mixed in returns a validation
> error.
>
>
>
>
>
> On Sun, Sep 6, 2009 at 3:02 PM, ishiijp wrote:
>
> > I'm looking for a way to stop MappedField validations if prefvious
> > validator returns error.
>
> > For example:
>
> > object Alphabets extends MappedString(this, 20) {
> > override def validations =
> > valMinLen(1, "Alphabets is required") _ ::
> > valRegex(Pattern.compile("^[a-zA-Z]+$", "It's not alphabets!")
> > _ ::
> > super.validations
> > }
>
> > if valMinLen returns error, I don't want to process valRegex.
>
> > My solutions are
> > (1) define custom validator which works as I want.
> > (2) override MappedField#validate()
>
> > If you have other ideas, please help me.
>
> > Thanks in advance.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@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] Re: Code Plugability in Lift
You might want to take something for that, maybe some non-boiler-plate code might help... On Sep 26, 8:06 am, David Pollak wrote: > I've been thinking about vomitting (I mean creating) bytecode at runtime > that creates a mock class for Hibernate consumption. > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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] Re: How to share request scope data among snippets in Lift
If the information is created just once and then used across multiple requests, it'll be a lazy val in a singleton If it's request-dependent then it'll be a singleton extending RequestVar Sadly, the OP didn't specify what was needed :( On Sat, Sep 26, 2009 at 2:35 PM, Timothy Perrett wrote: > > Take a look at RequestVar... If he were to just use a object singleton > he might end up being not thread safe. > > Cheers > > Tim > > Sent from my iPhone > > On 26 Sep 2009, at 14:05, Kevin Wright > wrote: > >> >> You could always try putting your lazy val inside a singleton object >> >> On Sat, Sep 26, 2009 at 8:14 AM, ishiijp >> wrote: >>> >>> Hi. >>> >>> If my lift application have some data that cost to create, and I want >>> to share it among snippets, how to do in Lift? >>> >>> if such data are shared inside one snippet, I may use "lazy val". >>> But I have no nice idea to share it among different snippts. >>> >>> Thanks much. >>> >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@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 -~--~~~~--~~--~--~---
