Re: SessionState

On Mon, 26 Nov 2012 19:17:45 -0200, Pillar wrote: I don't know if it's common practice to send thank you's in a mailing list, but screw it. Thanks! I'm pretty sure I'll be using much more of Tapestry in the future. We in the Tapestry mailing lists are very happy to help. :) Stick around

RE: SessionState

el...@hotmail.com Subject: Re: SessionState On Mon, 26 Nov 2012 18:45:14 -0200, Pillar <[hidden email]> wrote: > Hi, Hi! > In the Tapestry User Guide for session storage > <http://tapestry.apache.org/session-storage.html> , it states "Any other > co

Re: SessionState

On Mon, 26 Nov 2012 18:45:14 -0200, Pillar wrote: Hi, Hi! In the Tapestry User Guide for session storage , it states "Any other component or page that declares a field of the same type, regardless of name, and marks it with the SessionStat

Re: @SessionState and Translator

On Fri, 30 Mar 2012 03:44:33 -0300, resign wrote: hi, Hi! is it possible to add an translator to textfield depends on logged user? For example i want to translate Date object depends on logged user. Use the translate parameter of TextField. -- Thiago H. de Paula Figueiredo Independent Ja

Re: SessionState problem

"If you did private SalesItem salesItem = new SalesItem()" You got me!!!:-P Thank you very much. On 10/5/2011 3:12 PM, Thiago H de Paula Figueiredo [via Tapestry] wrote: > On Wed, 05 Oct 2011 19:00:05 -0300, okramlee <[hidden email] > > wrote: > > > Hi Thiago, > > Hi! > > > " If a field isn't @Se

Re: SessionState problem

On Wed, 05 Oct 2011 19:00:05 -0300, okramlee wrote: Hi Thiago, Hi! " If a field isn't @SessionState, it is completely thread-safe, not being shared between users." Yeah, that was what I thought about. But it did share the object between users even though I remove everything and keep sale

Re: SessionState problem

Tapestry objects's instance variables will never leak from user to user.. You have to try pretty hard to make that work. Whether its' @Persist, @SessionState, @SessinoAttribute, or just plain field, it will never leak. On Oct 5, 2011, at 5:22 PM, leothelion wrote: > Hi Thiago, > > Thanks for yo

Re: SessionState problem

Hi Thiago, Thanks for your reply. I will try it. Just a question out of this topic. I use salesItem as SessionState is because I don't what it to be shared by the other users when they are loading the same page. That's why I came up with the idea of SessionState. I don't know if there another wa

Re: SessionState problem

On Wed, 05 Oct 2011 17:56:44 -0300, leothelion wrote: If I erase the ' row="salesItem" ', then the adding problem is gone. But I cannot use a SessionState instance as a row in grid component? Yeah, but it's not a good idea, as you're using the same field for two very different things (us

Re: SessionState problem

I think I found where causes the problem. Here is the tml file: ${salesItem.sku} ... ... If I erase the ' row="salesItem" ', then the adding problem is gone. But I cannot use a SessionState instance as a row in grid component? If not, what is t

Re: SessionState problems with a String type

On Wed, 29 Jun 2011 15:20:48 -0300, Josh Canfield wrote: Ha! Good catch, and annoying. For anyone who hasn't addressed this, when I'm in apache fronted tomcat I use a rewrite rule in apache to make sure everything goes to the www. url... I suppose you could also do the same thing in a Tapestr

Re: SessionState problems with a String type

Ha! Good catch, and annoying. For anyone who hasn't addressed this, when I'm in apache fronted tomcat I use a rewrite rule in apache to make sure everything goes to the www. url... I suppose you could also do the same thing in a Tapestry request filter. Josh On Wed, Jun 29, 2011 at 9:35 AM, Tim

Re: SessionState problems with a String type

I'm replying to this somewhat old thread just to say that I have found the problem. The problem was that I had stored something as a SessionState Object (SSO), then I forwarded the user to another website to do some authentication which forwarded the user back to my site. But when the user c

Re: SessionState problems with a String type

Well, I just tried checking the session id like this, and it is in fact the same after coming back. And the SessionState objects started working too! So then I took out this session id code, and the SessionState objects are still working. So now it's all working fine, and I am left scratchi

Re: SessionState problems with a String type

On Wed, 11 May 2011 15:35:15 -0300, Tim Koop wrote: I'm trying to authenticate on my website with OpenID, using Java code from the openid4java library. After the user specifies his OpenID provider, the server (Tapestry) is supposed to forward him to the appropriate web page (like Google) to

Re: SessionState problems with a String type

I'm trying to authenticate on my website with OpenID, using Java code from the openid4java library. After the user specifies his OpenID provider, the server (Tapestry) is supposed to forward him to the appropriate web page (like Google) to get authenticated, then it forwards the user back to m

Re: SessionState problems with a String type

Are you sure you're getting the same session when you come back to the page? try dumping the session id. @Inject private HttpServletRequest request; void onActivate() { final HttpSession session = request.getSession(false); log.debug(session == null ? "Null session" :

Re: SessionState problems with a String type

On Wed, 11 May 2011 15:17:42 -0300, Tim Koop wrote: Thanks Josh (and Thiago). You're welcome! I added (create = false), and this certainly got rid of the error message. However, my session object is still either not getting set correctly (even though I clearly visit the page where it get

Re: SessionState problems with a String type

Thanks Josh (and Thiago). I added (create = false), and this certainly got rid of the error message. However, my session object is still either not getting set correctly (even though I clearly visit the page where it gets set, and I even write a message to the log saying I was there), or it is

Re: SessionState problems with a String type

http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/annotations/SessionState.html Specifically: public abstract boolean create If true (the default), then referencing an field marked with the annotation will create the SSO. If false, then accessing the field will not create the SSO,

Re: SessionState problems with a String type

On Wed, 11 May 2011 14:01:01 -0300, Tim Koop wrote: I'm having a little problem with even a simple SessionState String object. Try @SessionState(create = false). Better yet, create a class to represent your user session state and put this userColour field there, as a @SessionState object

Re: @SessionState Bug?

Hi everybody, To partially address the concerns raised, and following Pierce's suggestion (and using many of his words), I have updated this page in the User Guide to help make it clearer what the pitfalls and decision points are for using @SessionState and @SessionAttribute: http://tapestry.

Re: @SessionState Bug?

> > I'd like to suggest that @SessionState be deprecated in favor of > @SessionAttribute in the future. > > Thoughts? This is ultimately a _documentation_ error. (If we ignore the problem with generics for the moment.) That is, the real problem is that the docs for @SessionState/@Sessio

Re: Re: @SessionState Bug?

On Thu, 06 Jan 2011 21:38:15 -0200, Josh Canfield wrote: Perhaps you could build a CYASessionStateWorker that looks at @SessionState annotated fields and pukes if the type is outside of some package you specify. For instance, all of my @SessionState objects generally go in a "state" package a

Re: Re: @SessionState Bug?

I'm also opposed to deprecating @SessionState, for many of the reasons below. Perhaps you could build a CYASessionStateWorker that looks at @SessionState annotated fields and pukes if the type is outside of some package you specify. For instance, all of my @SessionState objects generally go in a "

Re: Re: @SessionState Bug?

On Thu, 06 Jan 2011 19:40:31 -0200, Michael Gentry wrote: Hi Thiago, Hi, Michael! I meant to mention that I don't consider "@SessionState has been used as it is since Tapetry 5 exists." to be a very good reason/excuse because @IncludeJavaScriptLibrary and @IncludeStylesheet are now deprec

Re: Re: @SessionState Bug?

On Thu, Jan 6, 2011 at 9:13 PM, Michael Gentry wrote: > Hi Igor, > > This does everything that @SessionState does, but gives you more > control. Plus you can easily use a data type more than once. > > > Nope, with @SessionState you have auto-building of SSOs and co-called accompany-fields to chec

Re: Re: @SessionState Bug?

Hi Thiago, I meant to mention that I don't consider "@SessionState has been used as it is since Tapetry 5 exists." to be a very good reason/excuse because @IncludeJavaScriptLibrary and @IncludeStylesheet are now deprecated. Things sometimes change (and hopefully for the better). :-) Cheers, mrg

Re: Re: @SessionState Bug?

Hi! As I said, in this case, what you consider dangerous I consider safe and vice-versa. Just different opinions. :) I agree that there's no completely safe option. Both have their pros and cons. And I don't consider @SessionState data-dangerous at all. I'd never use non-specific object t

Re: @SessionState Bug?

I'm with Igor. :) I've never used @SessionState for "simple" object types (List, Boolean, String, and the like). I've only ever used it for composite object types that will only ever have a single object per session ("Visit", "ShoppingCart", "User", and that ilk). For that matter, in practice,

Re: Re: @SessionState Bug?

Hi Thiago, You argue that @SessionState is type-safe, but it is data-dangerous. Is that a good trade-off? I personally want my data to be safe, too. :-) Also, If I do: @SessionAttribute("user") private String user; On something that was already set to be a User record (instead of a string), it

Re: Re: @SessionState Bug?

Hi Igor, How am I missing the use case of doing something like: @SessionAttribute(value=Constants.USER) private User user; or @SessionAttribute(value=Constants.SHOPPING_CART) private List shoppingCartItems; This does everything that @SessionState does, but gives you more control. Plus you can

Re: Re: @SessionState Bug?

Hi Donny, I will always use the name attribute. Thanks, mrg On Thu, Jan 6, 2011 at 2:40 PM, Donny Nadolny wrote: > You could still have the problem of someone using @SessionAttribute and > giving the variable the same name as some other session variable. > > I might take it one step further -

Re: Re: @SessionState Bug?

On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry wrote: I'd like to suggest that @SessionState be deprecated in favor of @SessionAttribute in the future. I'm completely against. @SessionState has been used as it is since Tapetry 5 exists. I think @SessionAttribute is dangerous for almos

Re: Re: @SessionState Bug?

Michael, @SessionState will not be deprecated. I guess you are missing the use case for this very useful annotation. Some examples are a logged in user or a shopping basket. Usually you have only one instance of such an object in your app, so it is absolutely fine to same only one instance per app

Re: Re: @SessionState Bug?

You could still have the problem of someone using @SessionAttribute and giving the variable the same name as some other session variable. I might take it one step further - declare a single class/enum with the names of all of your session variables, and *always* use the name parameter for @Session

Re: Re: @SessionState Bug?

On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield wrote: > In 5.2 there is SessionAttribute which pulls the value from the > session by name, defaulting to the name of the field... Hi Josh, @SessionAttribute is working great so far. Thanks again for the tip. For discussion by others (if desired):

Re: Re: @SessionState Bug?

On Thu, 06 Jan 2011 14:56:00 -0200, Josh Canfield wrote: In 5.2 there is SessionAttribute which pulls the value from the session by name, defaulting to the name of the field... Ooops, I missed that. Thanks Josh! -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hiber

Re: Re: @SessionState Bug?

On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield wrote: > In 5.2 there is SessionAttribute which pulls the value from the > session by name, defaulting to the name of the field... Hi Josh, SessionAttribute sounds much more promising to me. Thanks for the tip! mrg ---

Re: Re: @SessionState Bug?

Hi Thiago, Absolutely, I agree - @SessionState can't be changed to be based on name. I was just arguing that handling session state based on name is an alternate solution, just they both solutions have a set of problems. On Thu, Jan 6, 2011 at 11:53 AM, Thiago H. de Paula Figueiredo < thiag...@

Re: Re: @SessionState Bug?

mely intrusive >> and surely not easy to maintain. And even if you were able to maintain that. >> What would you expect Tapestry to do in the following case? >> Component1 >> @SessionState >> private String eMailAddress; >> >> Component2 >> @SessionState >

Re: Re: @SessionState Bug?

On Thu, 06 Jan 2011 14:42:09 -0200, Donny Nadolny wrote: Hi Nille, Hi, guys! I don't think it's the only way to do it. Determining it based on the variable name (or maybe name/type pair) would work. It would just have a different set of problems. Don't forget that @SessionState can't ch

Re: @SessionState Bug?

Hi Robert, I understand what it is doing now, but still find it non-intuitive. I think part of this goes back to the whole POJO "subclasses-are-evil" debate. In my use case, I had an abstract wizard page that had a lot of concrete subclasses that needed to share data on multiple pages (@Persist

Re: Re: @SessionState Bug?

you expect Tapestry to do in the following case? >> Component1 >> @SessionState >> private String eMailAddress; >> >> Component2 >> @SessionState >> private EmailAddress emailAddress; >> >> regards nillehammer >> >> - original Nach

Re: Re: @SessionState Bug?

you were able to maintain that. > What would you expect Tapestry to do in the following case? > Component1 > @SessionState > private String eMailAddress; > > Component2 > @SessionState > private EmailAddress emailAddress; > > regards nillehammer > > - origi

Re: @SessionState Bug?

Hi Mike, I understand that the behavior seems a bit non-intuitive. It has to do with the fact that the @SessionState objects are global (ie not per-page) objects. The decision was made early on to base these solely on the type of the object, rather than on the name of the object. Usually, @Ses

Re: Re: @SessionState Bug?

- original Nachricht Betreff: Re: @SessionState Bug? Gesendet: Do, 06. Jan 2011 Von: Donny Nadolny > Ah that's the problem then. You're expecting them to be assigned based on > the name of the variable, but @SessionState assigns them based on their > type. > >

Re: @SessionState Bug?

On Thu, Jan 6, 2011 at 10:14 AM, Thiago H. de Paula Figueiredo wrote: > On Thu, 06 Jan 2011 13:09:43 -0200, Michael Gentry >> Thanks for the explanation, but the types might be a red herring.  I'm >> less concerned about that than the fact that Tapestry seems to be >> assigning one of my variable

Re: @SessionState Bug?

> Thanks for the explanation, but the types might be a red herring.  I'm > less concerned about that than the fact that Tapestry seems to be > assigning one of my variables to a different variable. You did assign them to the same thing, you just didn't know it. You told tapestry to store the value

Re: @SessionState Bug?

yeah, typing too fast, kids running around my legs getting into stuff! :) On Thu, Jan 6, 2011 at 7:17 AM, Thiago H. de Paula Figueiredo wrote: > On Thu, 06 Jan 2011 13:14:09 -0200, Josh Canfield > wrote: > >> Next on my list is generic services (@Inject GenericDAO >> personDao;) it's implemented

Re: @SessionState Bug?

On Thu, 06 Jan 2011 13:14:09 -0200, Josh Canfield wrote: Next on my list is generic services (@Inject GenericDAO personDao;) it's implemented but working through tests/use cases. I'll add @Persist. Shouldn't it be @SessionState? ;) -- Thiago H. de Paula Figueiredo Independent Java, Apac

Re: @SessionState Bug?

Ah that's the problem then. You're expecting them to be assigned based on the name of the variable, but @SessionState assigns them based on their type. You could have in page1: @SessionState private String username; In page 2: @SessionState private String email; And they would be assigned to the

Re: @SessionState Bug?

On Thu, 06 Jan 2011 13:09:43 -0200, Michael Gentry wrote: Hi Donny, Hi! Thanks for the explanation, but the types might be a red herring. I'm less concerned about that than the fact that Tapestry seems to be assigning one of my variables to a different variable. It doesn't matter if the

Re: @SessionState Bug?

> The reason why they're both considered the same: this has to do with how > generics work in Java. I'm building in better generics support for 5.3, this seems like something I can make work. All of the generic information is available for fields, methods, and method parameters via reflection. Luc

Re: @SessionState Bug?

Hi Donny, Thanks for the explanation, but the types might be a red herring. I'm less concerned about that than the fact that Tapestry seems to be assigning one of my variables to a different variable. It doesn't matter if the types are the same or different. I could've had: @SessionState(creat

Re: @SessionState Bug?

Tapestry will treat the two as the exact same SessionState since they both are java.util.List - the Boolean/String type parameters will not help differentiate between the two. It is possible to get around this by changing one of them to Collection/Iterable/ArrayList/etc so that they use two d

Re: @SessionState Bug?

Your two lists are the same - they're both of type List so they both get assigned to the same thing. See below for why. The solution is to make two classes, one that holds the booleans, and one that holds the strings. Technically you would only need to do that for one, but it's probably a good ide

Re: SessionState for simple types

Yes! I forgot about that. Works like a charm :) On Tue, Sep 14, 2010 at 1:46 PM, Guerin Laurent wrote: > Hi, > > From tapestry 5.2 you can use @SessionAttribute. > > Envoyé de mon iPhone > > Le 14 sept. 2010 à 20:34, "Adam Zimowski" a écrit : > >>> I find it both easy and self-descriptive to wri

Re: SessionState for simple types

Hi, From tapestry 5.2 you can use @SessionAttribute. Envoyé de mon iPhone Le 14 sept. 2010 à 20:34, "Adam Zimowski" a écrit : I find it both easy and self-descriptive to write wrapper classes for these java objects. That's exactly what I'm trying to avoid. With a large team of junior p

Re: SessionState for simple types

> I find it both easy and self-descriptive to write wrapper classes for these > java objects. That's exactly what I'm trying to avoid. With a large team of junior programmers this will be a maintenance nightmare. > You could always grab the HttpSession and store them yourself. >From my searchin

Re: SessionState for simple types

> I understand that @SessionState was meant for POJOs. What's the > preferred (if any) way in Tapestry to store Strings, Integers and such > across multiple pages? It really depends on the use case. If you can bundle them up into a class that'd be the best way. For instance, if you're storing some

Re: SessionState for simple types

I'm not sure if this is the recommended way, but I find it both easy and self-descriptive to write wrapper classes for these java objects so you can use either SessionState or the Environment to move them across pages in the application. For example, if you have a String for the name of the use

Re: @SessionState error

@SessionState is meant for data holding POJOs, not simple types. On Mon, Jun 1, 2009 at 2:04 PM, Thibaut Gadiolet wrote: > Hi folks, > > As soon as I put the annotation @SessionState in my application, I get an > error. > > *here is a sample of code from home.java* > > *   �...@sessionstate >    

Re: @SessionState error

Thank you so much ! It works perfectly right now ! On Mon, Jun 1, 2009 at 5:06 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Em Mon, 01 Jun 2009 18:04:01 -0300, Thibaut Gadiolet < > thibaut.gadio...@gmail.com> escreveu: > > Hi folks, >> > > Hi! > > @SessionState >>priv

Re: @SessionState error

Em Mon, 01 Jun 2009 18:04:01 -0300, Thibaut Gadiolet escreveu: Hi folks, Hi! @SessionState private String userName; Use @SessionState(create = false). This prevents Tapestry of trying to instantiate a String when userName wasn't set yet. -- Thiago H. de Paula Figueiredo Inde