I like these discussions, and I really like that they tend to end in a conclusion that good code conventions and good code design seems to be the solution to the "problem". T5 encourage one to do things "right".
2007/3/20, Anjana Gopinath <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED] >>>> >>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>>> >>> >>>> >> >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------- >>>> -- >>>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> > For additional commands, e-mail: [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] > >
-- /ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]