You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Lance Java <la...@googlemail.com> on 2012/04/26 14:16:04 UTC
Does the Tree component need to use the session?
The current tree implementation requires the session to store the
TreeExpansionModel. As with most of you, I like to avoid using the session
wherever possible to improve scalability and to avoid issues when a user
opens multiple browser windows for the same page. In my mind, the
TreeExpansionModel doesn't need to be stored in the session. It could be
serialized as a string (comma separated list of expanded id's) and passed
in each request / response.
Thoughts?
Re: Does the Tree component need to use the session?
Posted by trsvax <tr...@gmail.com>.
I would say the Tapestry way to override persist behavior is with Meta and it
should probably stay that way. Secondly I'd prefer making the default the
preferred way and overriding that behavior instead of the other way around.
The thing Tapestry does not provide out of the box is override Persist by
type which is what I think you need in this case.
I would think persisting the grids String, Integer and Boolean in the url
would be a good idea.
Finally I think it would work in the url even with multiple components on
the same page. You just need to differentiate them somehow. In my paging
component I use the component id/field name.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Does-the-Tree-component-need-to-use-the-session-tp5667428p5670613.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Does the Tree component need to use the session?
Posted by Lance Java <la...@googlemail.com>.
I don't think this would work, for instance the grid component persists
String, Integer and Boolean. Also, if there were 2 trees in the app, they
would both need the same persistence
I'd prefer a component parameter. I was assuming this would require
invoking tapestry's underlying persistence API's instead of using @Persist.
Re: Does the Tree component need to use the session?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 27 Apr 2012 10:02:10 -0300, trsvax <tr...@gmail.com> wrote:
> I'm sure there are
> many people (me included) that persist db result sets in the session.
That's something I put in the "never, never, ever do that" list. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Does the Tree component need to use the session?
Posted by trsvax <tr...@gmail.com>.
Here is my thought because I think there are other places in core that use
persist.
I think the idea behind persist is you leave the argument blank which allows
you to override the type via the metadata. If no overrides are found it
falls back to the default which is session. It appears you could override
the default with client but that seems like a bad idea. I'm sure there are
many people (me included) that persist db result sets in the session.
So here is my suggestion: Create a persist-override module that does the
following
1. Create a "PersistChain" type that implements chain of command
2. Create a ValueEncoder for DefaultTreeExpansionModel
3. Create a PersistByType provider that uses value encoders to persist in
the client and put it in the chain.
4. Replace the default persist type with PersistChain
Now you can control by datatype the default persist method. You can also
override this by placing other providers in the chain and you can still
override things with Meta. Lastly the default type is still Session.
Issues:
1. It might be better to have a PersistByType mapped configuration instead
of using ValueEncoder directly. There might be times when you have a
ValueEncoder but don't want the change the persist type.
So if you want PersistClient for components in core you just add this module
to your pom file and it magically works.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Does-the-Tree-component-need-to-use-the-session-tp5667428p5670216.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Does the Tree component need to use the session?
Posted by Lance Java <la...@googlemail.com>.
I'm not sure how I'd manage it either.
1. It would be nice if you could pass a "persistenceType" parameter of
"session" or "client". Is that possible?
2. Is there a "hook" where you can specify how to serialize / deserialize
an object to the client persistence?
3. Tree accepts an "expansionModel" parameter. Not sure how to keep this
functionality.
On Thursday, 26 April 2012, trsvax <tr...@gmail.com> wrote:
> I'm not sure how to fix it in a backward compatible way. If you move the
> persistence to the URL it will change it's behavior under some
> circumstances.
>
> --
> View this message in context:
http://tapestry.1045711.n5.nabble.com/Does-the-Tree-component-need-to-use-the-session-tp5667428p5668800.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Does the Tree component need to use the session?
Posted by trsvax <tr...@gmail.com>.
I'm not sure how to fix it in a backward compatible way. If you move the
persistence to the URL it will change it's behavior under some
circumstances.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Does-the-Tree-component-need-to-use-the-session-tp5667428p5668800.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Does the Tree component need to use the session?
Posted by Bob Harner <bo...@gmail.com>.
+1 (who's the volunteer?)
If it's designed cleverly, the character size need to store the
expanded/collapsed state can be very tiny.
On Apr 26, 2012 9:46 AM, "Lance Java" <la...@googlemail.com> wrote:
> > I thought client persist was via the url not cookies, but as I said I
> never really used it
> See my previous post, I was wrong
>
> > The issue is the URL gets too long
> Agreed, perhaps gzip compression can help there
>
> > and bookmarking is iffy since the id can change.
> Hopefully the URL won't be bookmarked as the requests are via Ajax and
> won't change the URL in the browsers address bar
>
Re: Does the Tree component need to use the session?
Posted by Lance Java <la...@googlemail.com>.
> I thought client persist was via the url not cookies, but as I said I
never really used it
See my previous post, I was wrong
> The issue is the URL gets too long
Agreed, perhaps gzip compression can help there
> and bookmarking is iffy since the id can change.
Hopefully the URL won't be bookmarked as the requests are via Ajax and
won't change the URL in the browsers address bar
Re: Does the Tree component need to use the session?
Posted by trsvax <tr...@gmail.com>.
I thought client persist was via the url not cookies, but as I said I never
really used it.
It might be handy to have a persist that used a URL argument. That's how I
do paging with something like
url?table1.page=1 where table1 is the component id. In the case of tree that
might be
url?tree1.nodes=1,5,7
Perhaps
@Persist("RequestParameter")
The issue is the URL gets too long and bookmarking is iffy since the id can
change.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Does-the-Tree-component-need-to-use-the-session-tp5667428p5667628.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Does the Tree component need to use the session?
Posted by Lance Java <la...@googlemail.com>.
I take that back... I always assumed client persistence was based on
cookies. It seems it uses a request parameter... That could work but has
max URL length restrictions
Re: Does the Tree component need to use the session?
Posted by Lance Java <la...@googlemail.com>.
Client persistence wont get rid of the multiple window error. It will also
introduce the possibility that the client has cookies disabled so nothing
will work.
Re: Does the Tree component need to use the session?
Posted by trsvax <tr...@gmail.com>.
I would agree with that. I would prefer it if the core did not require a
session at all.
I suppose you could change the default to
Persist(PersistenceConstants.CLIENT) but I have never tried that.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Does-the-Tree-component-need-to-use-the-session-tp5667428p5667498.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Does the Tree component need to use the session?
Posted by Geoff Callender <ge...@gmail.com>.
I've had the same thought. As you'd expect, if you open the Tree From Database, With Zones example in two browser windows you'll find that your actions in one affects the other.
So +1 from me.
On 26/04/2012, at 10:16 PM, Lance Java wrote:
> The current tree implementation requires the session to store the
> TreeExpansionModel. As with most of you, I like to avoid using the session
> wherever possible to improve scalability and to avoid issues when a user
> opens multiple browser windows for the same page. In my mind, the
> TreeExpansionModel doesn't need to be stored in the session. It could be
> serialized as a string (comma separated list of expanded id's) and passed
> in each request / response.
>
> Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org