Thanks Robert!
Anjana Gopinath
True North Technology
11465 John's Creek Parkway, Suite 300
Duluth, GA 30079
[EMAIL PROTECTED]
On Mar 20, 2007, at 5:47 PM, Robert Zeigler wrote:
> Tapestry works its magic using runtime type information, and since
> generics in java were implemented using type erasure, the two types
> will be the same at runtime.
> So you'll need to wrap the two lists in some type of enclosure,
> just like with the pricing information.
>
> Robert
>
>
> On Mar 20, 2007, at 3/204:43 PM , Anjana Gopinath wrote:
>
>> Thanks Howard for explaining. It makes sense.
>>
>> But what if i want to store a list of objects as a ASO?
>>
>> For example
>>
>> public ArrayList<Application> appList;
>>
>> public ArrayList<Network> networkList;
>>
>> Both the above are of type List, but list of two objects. Will
>> this be an issue?
>>
>>
>>
>> Anjana Gopinath
>> True North Technology
>> 11465 John's Creek Parkway, Suite 300
>> Duluth, GA 30079
>> [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>> On Mar 20, 2007, at 5:38 PM, Howard Lewis Ship wrote:
>>
>>> T4 allowed multiple ASOs of the same type, however each and every
>>> ASO
>>> had to be defined with a unique name, plus an XML snippet to
>>> identify
>>> how to instantiate it.
>>>
>>> This violated the Dont Repeat Yourself principle, since you
had to
>>> know and repeat the ASO name on every use throughout the
>>> application.
>>>
>>> T5 simplifies this; the ASO "name" is simply the fully qualified
>>> class
>>> name and, in lieu of a definition (which is optional),
Tapestry will
>>> simply instantiate the class by its default constructor.
>>>
>>> This doesn't work if you are trying to store many simple values,
>>> such
>>> as a few Strings, but that's not how ASOs are designed to be
used.
>>> They are expected to contain a collection of typed properties
that
>>> will be used individually or in conjunction throughout the
>>> application.
>>>
>>> So this is a trade off ... a "feature" that was not used
(multiple
>>> ASOs of the same type), or at least, not widely used (and easily
>>> worked around) vs. extra duplicated effort (knowing and using the
>>> name).
>>>
>>>
>>>
>>> On 3/20/07, Anjana Gopinath <[EMAIL PROTECTED]> wrote:
>>>> Robert
>>>>
>>>> Thanks for explaining and i perfectly understand your point.
But i
>>>> still feel this is a restriction as i cant have ASOs of same
type.
>>>> Anyway, right now i can continue with the way you suggested.
>>>> Thanks!
>>>> Anjana Gopinath
>>>> True North Technology
>>>> 11465 John's Creek Parkway, Suite 300
>>>> Duluth, GA 30079
>>>> [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 20, 2007, at 4:55 PM, Robert Zeigler wrote:
>>>>
>>>> > I see it as simplification rather than a restriction.
>>>> > I guess I don't normally store application state in a bunch of
>>>> > separate strings; rather, I always store state in one or more
>>>> > POJO's, exactly analogous to the Pricing object. So, for
me, less
>>>> > mess, because I don't have to have a bunch of extra string
>>>> > properties in my page, and less mess because I don't have to
>>>> > constantly refer to what I called some variable on some other
>>>> page.
>>>> >
>>>> > Robert
>>>> >
>>>> > On Mar 20, 2007, at 3/203:35 PM , Anjana Gopinath wrote:
>>>> >
>>>> >> Thanks Robert for responding.
>>>> >>
>>>> >> I can do that, but was wondering why there is a
restriction like
>>>> >> this?
>>>> >>
>>>> >>
>>>> >> Anjana Gopinath
>>>> >> True North Technology
>>>> >> 11465 John's Creek Parkway, Suite 300
>>>> >> Duluth, GA 30079
>>>> >> [EMAIL PROTECTED]
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Mar 20, 2007, at 4:29 PM, Robert Zeigler wrote:
>>>> >>
>>>> >>> Correct.
>>>> >>> Why not create, say, a "Pricing" object with
"enterprisePrice"
>>>> >>> and "clientPrice" properties?
>>>> >>> Then you could do:
>>>> >>>
>>>> >>> @ApplicationState
>>>> >>> private Pricing _pricing;
>>>> >>>
>>>> >>> Then you have one less injection to do/page that requires
>>>> pricing
>>>> >>> information. :)
>>>> >>>
>>>> >>> Robert
>>>> >>>
>>>> >>> On Mar 20, 2007, at 3/203:26 PM , Anjana Gopinath wrote:
>>>> >>>
>>>> >>>> Hi
>>>> >>>>
>>>> >>>>
>>>> >>>> I am trying to use few ASO's so share data across the
pages. I
>>>> >>>> have declared the following, but looks like if one gets a
>>>> value,
>>>> >>>> the second varaible also gets the same value. Is it not
>>>> >>>> possible to define different ASO's of same type?
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> @ApplicationState
>>>> >>>> private String enterprisePrice;
>>>> >>>>
>>>> >>>> @ApplicationState
>>>> >>>> private String clientPrice;
>>>> >>>>
>>>> >>>> i saw this in the T5 website
>>>> >>>>
>>>> >>>> "Any other component or page that declares a field of
the same
>>>> >>>> type, regardless of name, and marks it with the
>>>> ApplicationState
>>>> >>>> annotation will share the same value. " . So is it not
>>>> possible
>>>> >>>> to have two different ASO's os same type?
>>>> >>>>
>>>> >>>> Thanks!
>>>> >>>>
>>>> >>>> Anjana Gopinath
>>>> >>>>
>>>> >>>> [EMAIL PROTECTED]
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>>
-------------------------------------------------------------------
>>>> -
>>>> >>> -
>>>> >>> To unsubscribe, e-mail: users-
[EMAIL PROTECTED]
>>>> >>> For additional commands, e-mail: users-
[EMAIL PROTECTED]
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>>
-------------------------------------------------------------------
>>>> --
>>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> > For additional commands, e-mail: users-
[EMAIL PROTECTED]
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>> TWD Consulting, Inc.
>>> Independent J2EE / Open-Source Java Consultant
>>> Creator and PMC Chair, Apache Tapestry
>>> Creator, Apache HiveMind
>>>
>>> Professional Tapestry training, mentoring, support
>>> and project work. http://howardlewisship.com
>>>
>>>
--------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
