One other point - part of the downside of the current way could be avoided
with error messages.
You should probably get a warning if you have two @SessionState variables in
your page that map to the same session variable, because it's unlikely
that's what you actually intended to do.
On Thu, Jan 6, 2011 at 11:42 AM, Donny Nadolny <donny.nado...@gmail.com>wrote:
> Hi Nille,
>
> 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.
>
> Based on types, the problems are that you get unintuitive results,
> especially with generics - it's not clear just from a brief description of
> the feature, eg "values are assigned based on the type", which way it will
> behave (are types with different generic arguments different or the same?
> right now they're considered the same type, but it was mentioned earlier in
> this thread that it's going to change). Also, whoever implements it is going
> to have to decide how it works when the types are different but compatible.
> Should List<Object> automatically get assigned if there's a List<String>
> there? How about just List?
>
> With it based on name/type pair, it's clear how it would work in the case
> you gave - they would be different values because even though they have the
> same name (ignoring case), they have different types. The disadvantage is
> with refactoring, and being forced to use the same name if you want to get
> the same object (although I don't think that's too much of a downside,
> especially if you could give an override name, like it's done with
> @InjectComponent - by default it uses the variable name to link it, but you
> can pass a name if you want to name them differently).
>
> Doing it by name essentially creates the equivalent of global variables -
> but in a way that makes more sense, because that's what session state is: a
> global variables in your application.
>
>
>
> On Thu, Jan 6, 2011 at 10:56 AM, nille hammer <
> tapestry.nilleham...@winfonet.eu> wrote:
>
>> Hi Donny,
>>
>> If you think a bit further, assigning the value based on the type is the
>> only sensible way to do it. If the value was assigned based on the variable
>> name, you would have to use that exact variable name in every component and
>> page you want to use your SessionState-Object. That is extremely 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
>> private EmailAddress emailAddress;
>>
>> regards nillehammer
>>
>> ----- original Nachricht --------
>>
>> Betreff: Re: @SessionState Bug?
>> Gesendet: Do, 06. Jan 2011
>> Von: Donny Nadolny<donny.nado...@gmail.com>
>>
>> > 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 same thing, because it's done based on
>> > the
>> > type rather than the variable name.
>> >
>> > I see how this would be confusing though - it does seem intuitive that
>> they
>> > would be assigned based on the variable name.
>> >
>> > On Thu, Jan 6, 2011 at 10:09 AM, Michael Gentry
>> > <mgen...@masslight.net>wrote:
>> >
>> > > 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(create=false)
>> > > private List<String> list1;
>> > > @SessionState(create=false)
>> > > private List<String> list2;
>> > >
>> > > And I'd still expect to have two separate/distinct variables and
>> > > lists, not two variables pointing to the same list (unless I
>> > > specifically assigned them to the same list myself).
>> > >
>> > > Thanks,
>> > >
>> > > mrg
>> > >
>> > >
>> > > On Thu, Jan 6, 2011 at 9:57 AM, Donny Nadolny <
>> donny.nado...@gmail.com>
>> > > wrote:
>> > > > 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 idea to do it for both anyway.
>> > > >
>> > > > The reason why they're both considered the same: this has to do with
>> > how
>> > > > generics work in Java. It's called type erasure - after the class is
>> > > > compiled, the generic type is erased, so at runtime it doesn't care
>> > what
>> > > the
>> > > > type is. Generics are a compile time check.
>> > > >
>> > > > For example, you could do:
>> > > > List<String> strings = new ArrayList<String>();
>> > > > List strings2 = strings;
>> > > > strings2.add(new Object()); //this line is fine
>> > > > String string = strings.get(0); //throws ClassCastException
>> > > >
>> > > > You might think that the strings2.add(new Object()) would have a
>> > problem
>> > > > because strings2 is pointing to strings which is an
>> ArrayList<String>,
>> > > but
>> > > > it doesn't because at runtime it doesn't do any checks, or even know
>> > that
>> > > > you put <String> there (well, there's certain ways of figuring it
>> out,
>> > > but
>> > > > generally just accept that it doesn't know). All it can do is give a
>> > > warning
>> > > > at "List strings2 = strings" because you're doing some potentially
>> type
>> > > > unsafe things.
>> > > >
>> > > >
>> > > > On Thu, Jan 6, 2011 at 9:38 AM, Michael Gentry <
>> mgen...@masslight.net
>> > > >wrote:
>> > > >
>> > > >> Hi everyone,
>> > > >>
>> > > >> Given the following page class:
>> > > >>
>> > > >>
>> > > >> public class Bug
>> > > >> {
>> > > >> @Inject
>> > > >> private Logger log;
>> > > >>
>> > > >> @SessionState(create=false)
>> > > >> private List<Boolean> booleans;
>> > > >>
>> > > >> @SessionState(create=false)
>> > > >> private List<String> strings;
>> > > >>
>> > > >> void onActivate()
>> > > >> {
>> > > >> log.debug("booleans = " + booleans);
>> > > >> log.debug("strings = " + strings);
>> > > >>
>> > > >> if (booleans == null)
>> > > >> booleans = new ArrayList<Boolean>();
>> > > >>
>> > > >> booleans.add(Boolean.TRUE);
>> > > >>
>> > > >> log.debug("booleans: " + booleans);
>> > > >> log.debug("strings: " + strings);
>> > > >> log.debug("equal? " + booleans.equals(strings));
>> > > >> }
>> > > >> }
>> > > >>
>> > > >> I get this output:
>> > > >>
>> > > >> DEBUG 2011-01-06 09:35:24,014 booleans = null
>> > > >> DEBUG 2011-01-06 09:35:24,014 strings = null
>> > > >> DEBUG 2011-01-06 09:35:24,014 booleans: [true]
>> > > >> DEBUG 2011-01-06 09:35:24,014 strings: [true]
>> > > >> DEBUG 2011-01-06 09:35:24,015 equal? true
>> > > >>
>> > > >>
>> > > >> Even though I don't add anything to the strings list or even
>> allocate
>> > > >> the strings list, it seems to be pointing to the booleans list,
>> which
>> > > >> is, of course, incorrect. This seems to be happening on both 5.1
>> and
>> > > >> 5.2. Am I missing something?
>> > > >>
>> > > >> Thanks,
>> > > >>
>> > > >> mrg
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> > > >> For additional commands, e-mail: users-h...@tapestry.apache.org
>> > > >>
>> > > >>
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> > > For additional commands, e-mail: users-h...@tapestry.apache.org
>> > >
>> > >
>> >
>>
>> --- original Nachricht Ende ----
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
