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
>
>
