Re: T5: ASO in HttpServletRequestFilter
the RequestGlobals service can return the HttpServletRequest and HttpServletResponse objects (getters) ... therefore you could implement RequestFilter as well :) g, kris "kranga" <[EMAIL PROTECTED]> 13.05.2008 16:51 Bitte antworten an "Tapestry users" An "Tapestry users" Kopie Thema Re: T5: ASO in HttpServletRequestFilter Obvious: Because you can't access the HttpServletRequest from within the RequestFilter to access methods such as getRequestUri() (needed by 3rd party library being called in the filter). If I didn't have access to the ASO manager, then I could write up the filter as a traditional Servlet filter. Why bother with the Tapestry filter chain in the first place? Or do I need to configure my servletRequestFilter to be "after" some other filter? If so, where do I find the list of these "after" "before" definitions? - Original Message - From: "Robert Zeigler" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Tuesday, May 13, 2008 10:43 AM Subject: Re: T5: ASO in HttpServletRequestFilter > Why not use a RequestFilter, instead? > You can access the ApplicationStateManager from withing a RequestFilter. > > Robert > > On May 13, 2008, at 5/139:41 AM , kranga wrote: > >> Version: 5.0.11 >> It appears that if you inject an application state manager into an >> HttpServletRequestFilter and try to access an ASO, you get a null >> pointer exception since the Tapestry Request object has still not been >> set up. This means that if you do need to access an ASO, you are forced >> to use the session directly (and hence the session from within your >> pages too). >> >> - >> 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: ASO in HttpServletRequestFilter
Obvious: Because you can't access the HttpServletRequest from within the RequestFilter to access methods such as getRequestUri() (needed by 3rd party library being called in the filter). If I didn't have access to the ASO manager, then I could write up the filter as a traditional Servlet filter. Why bother with the Tapestry filter chain in the first place? Or do I need to configure my servletRequestFilter to be "after" some other filter? If so, where do I find the list of these "after" "before" definitions? - Original Message - From: "Robert Zeigler" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Tuesday, May 13, 2008 10:43 AM Subject: Re: T5: ASO in HttpServletRequestFilter Why not use a RequestFilter, instead? You can access the ApplicationStateManager from withing a RequestFilter. Robert On May 13, 2008, at 5/139:41 AM , kranga wrote: Version: 5.0.11 It appears that if you inject an application state manager into an HttpServletRequestFilter and try to access an ASO, you get a null pointer exception since the Tapestry Request object has still not been set up. This means that if you do need to access an ASO, you are forced to use the session directly (and hence the session from within your pages too). - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: ASO in HttpServletRequestFilter
Why not use a RequestFilter, instead? You can access the ApplicationStateManager from withing a RequestFilter. Robert On May 13, 2008, at 5/139:41 AM , kranga wrote: Version: 5.0.11 It appears that if you inject an application state manager into an HttpServletRequestFilter and try to access an ASO, you get a null pointer exception since the Tapestry Request object has still not been set up. This means that if you do need to access an ASO, you are forced to use the session directly (and hence the session from within your pages too). - 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]
Re: T5 ASO cannot have a non default constructor in 5.0.11?
On Sun, 2008-05-11 at 16:15 +0200, Filip S. Adamsen wrote: > You can still use an ApplicationStateCreator. Just instantiate the ASO > in the creator and set the values wherever you want after its creation. Ha, you're right, I simply want to invoke the default constructor - I forgot this ;) Thanx && cheers, Martin > > -Filip > > On 2008-05-11 16:12, Martin Grotzke wrote: > > On Sun, 2008-05-11 at 15:13 +0200, Filip S. Adamsen wrote: > >> Hi, > >> > >> Tapestry is trying to inject services into your ASO's constructor. In > >> 5.0.12-SNAPSHOT you can put @Inject on the constructor Tapestry should > >> use when auto-instantiating. > > Ok, thanx! This will solve our issue when we can upgrade to 5.0.12. > > > >> Until you can upgrade to 5.0.12 I guess a workaround would be to > >> contribute and ApplicationStateCreator for your ASO. > > The parameters of the ASO constructor are runtime parameters, so AFAICS > > we could not use an ApplicationStateCreator. > > > > I now added a test if the ASO already exists before we access it, so > > that T5 does not has to create the ASO. Hopefully I found all cases > > where this would be an issue ;) > > > > Cheers, > > Martin > > > > > >> See "Configuring ASOs" at the bottom: > >> http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html > >> > >> -Filip > >> > >> On 2008-05-11 14:54, Martin Grotzke wrote: > >>> Hi, > >>> > >>> I'm just upgrading our app from 5.0.10-SNAPSHOT to 5.0.11 and get > >>> exceptions for ASOs that have a non default constructor (additionally to > >>> the default constructor): > >>> > >>> Caused by: java.lang.RuntimeException: Error invoking constructor > >>> com.freiheit.shopping24.shop.search.model.AnalysedSearchParameters(DBShopCategory, > >>> List, String, String, String, String, List, List, DisplayedEntriesEnum, > >>> SortOrderField, ViewStyle, int, String, boolean, boolean, boolean, > >>> boolean, boolean) (at AnalysedSearchParameters.java:73) (for service > >>> 'ApplicationStateManager'): No service implements the interface > >>> com.freiheit.shopping24.shop.search.model.DBShopCategory. > >>> at > >>> org.apache.tapestry.ioc.internal.ConstructorServiceCreator.createObject(ConstructorServiceCreator.java:62) > >>> at > >>> org.apache.tapestry.ioc.internal.ServiceResourcesImpl.autobuild(ServiceResourcesImpl.java:123) > >>> at > >>> org.apache.tapestry.internal.services.ApplicationStateManagerImpl$1.create(ApplicationStateManagerImpl.java:98) > >>> at > >>> org.apache.tapestry.internal.services.SessionApplicationStatePersistenceStrategy.get(SessionApplicationStatePersistenceStrategy.java:56) > >>> at > >>> org.apache.tapestry.internal.services.ApplicationStateManagerImpl$ApplicationStateAdapter.getOrCreate(ApplicationStateManagerImpl.java:45) > >>> at > >>> org.apache.tapestry.internal.services.ApplicationStateManagerImpl.get(ApplicationStateManagerImpl.java:126) > >>> at > >>> $ApplicationStateManager_119d7fb59ed.get($ApplicationStateManager_119d7fb59ed.java) > >>> at > >>> com.freiheit.shopping24.shop.search.presentation.pages.Search._$read_searchParameters(Search.java) > >>> at > >>> com.freiheit.shopping24.shop.search.presentation.pages.Search.onActivate(Search.java:188) > >>> at > >>> com.freiheit.shopping24.shop.search.presentation.pages.Search.dispatchComponentEvent(Search.java) > >>> at > >>> org.apache.tapestry.internal.structure.ComponentPageElementImpl.dispatchEvent(ComponentPageElementImpl.java:843) > >>> at > >>> org.apache.tapestry.internal.structure.ComponentPageElementImpl.triggerContextEvent(ComponentPageElementImpl.java:1004) > >>> ... 91 more > >>> Caused by: java.lang.RuntimeException: No service implements the > >>> interface com.freiheit.shopping24.shop.search.model.DBShopCategory. > >>> at > >>> org.apache.tapestry.ioc.internal.RegistryImpl.getService(RegistryImpl.java:517) > >>> at > >>> org.apache.tapestry.ioc.internal.services.MasterObjectProviderImpl.provide(MasterObjectProviderImpl.java:46) > >>> at > >>> $MasterObjectProvider_119d7fb5998.provide($MasterObjectProvider_119d7fb5998.java) > >>> at > >>> org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:621) > >>> at > >>> org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:675) > >>> at > >>> org.apache.tapestry.ioc.internal.ObjectLocatorImpl.getObject(ObjectLocatorImpl.java:50) > >>> at > >>> org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameterValue(InternalUtils.java:209) > >>> at > >>> org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameters(InternalUtils.java:239) > >>> at > >>> org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParametersForConstructor(InternalUtils.java:227) > >>> at > >>> org.apache.tapestry.ioc.internal.ConstructorServiceCrea
Re: T5 ASO cannot have a non default constructor in 5.0.11?
You can still use an ApplicationStateCreator. Just instantiate the ASO in the creator and set the values wherever you want after its creation. -Filip On 2008-05-11 16:12, Martin Grotzke wrote: On Sun, 2008-05-11 at 15:13 +0200, Filip S. Adamsen wrote: Hi, Tapestry is trying to inject services into your ASO's constructor. In 5.0.12-SNAPSHOT you can put @Inject on the constructor Tapestry should use when auto-instantiating. Ok, thanx! This will solve our issue when we can upgrade to 5.0.12. Until you can upgrade to 5.0.12 I guess a workaround would be to contribute and ApplicationStateCreator for your ASO. The parameters of the ASO constructor are runtime parameters, so AFAICS we could not use an ApplicationStateCreator. I now added a test if the ASO already exists before we access it, so that T5 does not has to create the ASO. Hopefully I found all cases where this would be an issue ;) Cheers, Martin See "Configuring ASOs" at the bottom: http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html -Filip On 2008-05-11 14:54, Martin Grotzke wrote: Hi, I'm just upgrading our app from 5.0.10-SNAPSHOT to 5.0.11 and get exceptions for ASOs that have a non default constructor (additionally to the default constructor): Caused by: java.lang.RuntimeException: Error invoking constructor com.freiheit.shopping24.shop.search.model.AnalysedSearchParameters(DBShopCategory, List, String, String, String, String, List, List, DisplayedEntriesEnum, SortOrderField, ViewStyle, int, String, boolean, boolean, boolean, boolean, boolean) (at AnalysedSearchParameters.java:73) (for service 'ApplicationStateManager'): No service implements the interface com.freiheit.shopping24.shop.search.model.DBShopCategory. at org.apache.tapestry.ioc.internal.ConstructorServiceCreator.createObject(ConstructorServiceCreator.java:62) at org.apache.tapestry.ioc.internal.ServiceResourcesImpl.autobuild(ServiceResourcesImpl.java:123) at org.apache.tapestry.internal.services.ApplicationStateManagerImpl$1.create(ApplicationStateManagerImpl.java:98) at org.apache.tapestry.internal.services.SessionApplicationStatePersistenceStrategy.get(SessionApplicationStatePersistenceStrategy.java:56) at org.apache.tapestry.internal.services.ApplicationStateManagerImpl$ApplicationStateAdapter.getOrCreate(ApplicationStateManagerImpl.java:45) at org.apache.tapestry.internal.services.ApplicationStateManagerImpl.get(ApplicationStateManagerImpl.java:126) at $ApplicationStateManager_119d7fb59ed.get($ApplicationStateManager_119d7fb59ed.java) at com.freiheit.shopping24.shop.search.presentation.pages.Search._$read_searchParameters(Search.java) at com.freiheit.shopping24.shop.search.presentation.pages.Search.onActivate(Search.java:188) at com.freiheit.shopping24.shop.search.presentation.pages.Search.dispatchComponentEvent(Search.java) at org.apache.tapestry.internal.structure.ComponentPageElementImpl.dispatchEvent(ComponentPageElementImpl.java:843) at org.apache.tapestry.internal.structure.ComponentPageElementImpl.triggerContextEvent(ComponentPageElementImpl.java:1004) ... 91 more Caused by: java.lang.RuntimeException: No service implements the interface com.freiheit.shopping24.shop.search.model.DBShopCategory. at org.apache.tapestry.ioc.internal.RegistryImpl.getService(RegistryImpl.java:517) at org.apache.tapestry.ioc.internal.services.MasterObjectProviderImpl.provide(MasterObjectProviderImpl.java:46) at $MasterObjectProvider_119d7fb5998.provide($MasterObjectProvider_119d7fb5998.java) at org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:621) at org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:675) at org.apache.tapestry.ioc.internal.ObjectLocatorImpl.getObject(ObjectLocatorImpl.java:50) at org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameterValue(InternalUtils.java:209) at org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameters(InternalUtils.java:239) at org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParametersForConstructor(InternalUtils.java:227) at org.apache.tapestry.ioc.internal.ConstructorServiceCreator.createObject(ConstructorServiceCreator.java:46) ... 102 more The class AnalysedSearchParameters still has a default constructor. Is this really not allowed, or is this a bug? Thanx && cheers, Martin - 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]
Re: T5 ASO cannot have a non default constructor in 5.0.11?
On Sun, 2008-05-11 at 15:13 +0200, Filip S. Adamsen wrote: > Hi, > > Tapestry is trying to inject services into your ASO's constructor. In > 5.0.12-SNAPSHOT you can put @Inject on the constructor Tapestry should > use when auto-instantiating. Ok, thanx! This will solve our issue when we can upgrade to 5.0.12. > > Until you can upgrade to 5.0.12 I guess a workaround would be to > contribute and ApplicationStateCreator for your ASO. The parameters of the ASO constructor are runtime parameters, so AFAICS we could not use an ApplicationStateCreator. I now added a test if the ASO already exists before we access it, so that T5 does not has to create the ASO. Hopefully I found all cases where this would be an issue ;) Cheers, Martin > > See "Configuring ASOs" at the bottom: > http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html > > -Filip > > On 2008-05-11 14:54, Martin Grotzke wrote: > > Hi, > > > > I'm just upgrading our app from 5.0.10-SNAPSHOT to 5.0.11 and get > > exceptions for ASOs that have a non default constructor (additionally to > > the default constructor): > > > > Caused by: java.lang.RuntimeException: Error invoking constructor > > com.freiheit.shopping24.shop.search.model.AnalysedSearchParameters(DBShopCategory, > > List, String, String, String, String, List, List, DisplayedEntriesEnum, > > SortOrderField, ViewStyle, int, String, boolean, boolean, boolean, boolean, > > boolean) (at AnalysedSearchParameters.java:73) (for service > > 'ApplicationStateManager'): No service implements the interface > > com.freiheit.shopping24.shop.search.model.DBShopCategory. > > at > > org.apache.tapestry.ioc.internal.ConstructorServiceCreator.createObject(ConstructorServiceCreator.java:62) > > at > > org.apache.tapestry.ioc.internal.ServiceResourcesImpl.autobuild(ServiceResourcesImpl.java:123) > > at > > org.apache.tapestry.internal.services.ApplicationStateManagerImpl$1.create(ApplicationStateManagerImpl.java:98) > > at > > org.apache.tapestry.internal.services.SessionApplicationStatePersistenceStrategy.get(SessionApplicationStatePersistenceStrategy.java:56) > > at > > org.apache.tapestry.internal.services.ApplicationStateManagerImpl$ApplicationStateAdapter.getOrCreate(ApplicationStateManagerImpl.java:45) > > at > > org.apache.tapestry.internal.services.ApplicationStateManagerImpl.get(ApplicationStateManagerImpl.java:126) > > at > > $ApplicationStateManager_119d7fb59ed.get($ApplicationStateManager_119d7fb59ed.java) > > at > > com.freiheit.shopping24.shop.search.presentation.pages.Search._$read_searchParameters(Search.java) > > at > > com.freiheit.shopping24.shop.search.presentation.pages.Search.onActivate(Search.java:188) > > at > > com.freiheit.shopping24.shop.search.presentation.pages.Search.dispatchComponentEvent(Search.java) > > at > > org.apache.tapestry.internal.structure.ComponentPageElementImpl.dispatchEvent(ComponentPageElementImpl.java:843) > > at > > org.apache.tapestry.internal.structure.ComponentPageElementImpl.triggerContextEvent(ComponentPageElementImpl.java:1004) > > ... 91 more > > Caused by: java.lang.RuntimeException: No service implements the interface > > com.freiheit.shopping24.shop.search.model.DBShopCategory. > > at > > org.apache.tapestry.ioc.internal.RegistryImpl.getService(RegistryImpl.java:517) > > at > > org.apache.tapestry.ioc.internal.services.MasterObjectProviderImpl.provide(MasterObjectProviderImpl.java:46) > > at > > $MasterObjectProvider_119d7fb5998.provide($MasterObjectProvider_119d7fb5998.java) > > at > > org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:621) > > at > > org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:675) > > at > > org.apache.tapestry.ioc.internal.ObjectLocatorImpl.getObject(ObjectLocatorImpl.java:50) > > at > > org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameterValue(InternalUtils.java:209) > > at > > org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameters(InternalUtils.java:239) > > at > > org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParametersForConstructor(InternalUtils.java:227) > > at > > org.apache.tapestry.ioc.internal.ConstructorServiceCreator.createObject(ConstructorServiceCreator.java:46) > > ... 102 more > > > > The class AnalysedSearchParameters still has a default constructor. > > > > Is this really not allowed, or is this a bug? > > > > Thanx && cheers, > > Martin > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > signature.asc Description: This is a digitally signed message part
Re: T5 ASO cannot have a non default constructor in 5.0.11?
Hi, Tapestry is trying to inject services into your ASO's constructor. In 5.0.12-SNAPSHOT you can put @Inject on the constructor Tapestry should use when auto-instantiating. Until you can upgrade to 5.0.12 I guess a workaround would be to contribute and ApplicationStateCreator for your ASO. See "Configuring ASOs" at the bottom: http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html -Filip On 2008-05-11 14:54, Martin Grotzke wrote: Hi, I'm just upgrading our app from 5.0.10-SNAPSHOT to 5.0.11 and get exceptions for ASOs that have a non default constructor (additionally to the default constructor): Caused by: java.lang.RuntimeException: Error invoking constructor com.freiheit.shopping24.shop.search.model.AnalysedSearchParameters(DBShopCategory, List, String, String, String, String, List, List, DisplayedEntriesEnum, SortOrderField, ViewStyle, int, String, boolean, boolean, boolean, boolean, boolean) (at AnalysedSearchParameters.java:73) (for service 'ApplicationStateManager'): No service implements the interface com.freiheit.shopping24.shop.search.model.DBShopCategory. at org.apache.tapestry.ioc.internal.ConstructorServiceCreator.createObject(ConstructorServiceCreator.java:62) at org.apache.tapestry.ioc.internal.ServiceResourcesImpl.autobuild(ServiceResourcesImpl.java:123) at org.apache.tapestry.internal.services.ApplicationStateManagerImpl$1.create(ApplicationStateManagerImpl.java:98) at org.apache.tapestry.internal.services.SessionApplicationStatePersistenceStrategy.get(SessionApplicationStatePersistenceStrategy.java:56) at org.apache.tapestry.internal.services.ApplicationStateManagerImpl$ApplicationStateAdapter.getOrCreate(ApplicationStateManagerImpl.java:45) at org.apache.tapestry.internal.services.ApplicationStateManagerImpl.get(ApplicationStateManagerImpl.java:126) at $ApplicationStateManager_119d7fb59ed.get($ApplicationStateManager_119d7fb59ed.java) at com.freiheit.shopping24.shop.search.presentation.pages.Search._$read_searchParameters(Search.java) at com.freiheit.shopping24.shop.search.presentation.pages.Search.onActivate(Search.java:188) at com.freiheit.shopping24.shop.search.presentation.pages.Search.dispatchComponentEvent(Search.java) at org.apache.tapestry.internal.structure.ComponentPageElementImpl.dispatchEvent(ComponentPageElementImpl.java:843) at org.apache.tapestry.internal.structure.ComponentPageElementImpl.triggerContextEvent(ComponentPageElementImpl.java:1004) ... 91 more Caused by: java.lang.RuntimeException: No service implements the interface com.freiheit.shopping24.shop.search.model.DBShopCategory. at org.apache.tapestry.ioc.internal.RegistryImpl.getService(RegistryImpl.java:517) at org.apache.tapestry.ioc.internal.services.MasterObjectProviderImpl.provide(MasterObjectProviderImpl.java:46) at $MasterObjectProvider_119d7fb5998.provide($MasterObjectProvider_119d7fb5998.java) at org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:621) at org.apache.tapestry.ioc.internal.RegistryImpl.getObject(RegistryImpl.java:675) at org.apache.tapestry.ioc.internal.ObjectLocatorImpl.getObject(ObjectLocatorImpl.java:50) at org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameterValue(InternalUtils.java:209) at org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParameters(InternalUtils.java:239) at org.apache.tapestry.ioc.internal.util.InternalUtils.calculateParametersForConstructor(InternalUtils.java:227) at org.apache.tapestry.ioc.internal.ConstructorServiceCreator.createObject(ConstructorServiceCreator.java:46) ... 102 more The class AnalysedSearchParameters still has a default constructor. Is this really not allowed, or is this a bug? Thanx && cheers, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 ASO & Service
Well I just wandered about serialization issues, but better for me if it's
not a problem, at the end I added my Service as a parametrer in the ASO:
MyASO.addproducttoChart(idProduct,MyServices)
{
Map _chartMap;
Product p=MyServices.getProductById(idProduct);
_chartMap.put(idProduct,p);
}
It is unclear for me how to inject those services in the
ApplicationStateCreator, and also which will be they time scope...in the way
I did I now that the service has been "freshly" injected in the page, but
really this I still don't get it full.
Thanks
Filip S. Adamsen-2 wrote:
>
> What? It's not uncommon to have methods on an ASO. You can also inject
> services into it when creating it if you use an ApplicationStateCreator.
> The relevant docs on Application State has an example at the bottom.
>
> -Filip
>
> maxthesecond skrev:
>> oopss!
>> I think I missed the point
>> the ASO aplication state object is merely a container for sharing
>> information across pages and time it shall not have metods, so I'll do as
>> you say.
>> thanks again
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/T5-ASO---Services-tp17134860p17145265.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 ASO & Service
What? It's not uncommon to have methods on an ASO. You can also inject services into it when creating it if you use an ApplicationStateCreator. The relevant docs on Application State has an example at the bottom. -Filip maxthesecond skrev: oopss! I think I missed the point the ASO aplication state object is merely a container for sharing information across pages and time it shall not have metods, so I'll do as you say. thanks again - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 ASO & Service
oopss! I think I missed the point the ASO aplication state object is merely a container for sharing information across pages and time it shall not have metods, so I'll do as you say. thanks again -- View this message in context: http://www.nabble.com/T5-ASO---Services-tp17134860p17141903.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 ASO & Service
Sounds good, if it's simply imposible to use services within ASO I'll do
that, but I found more natural the other way arround:
In the Page
_MyAso.addproductttoChart(id);
In the ASO
MyASO.addproducttoChart(idProduct)
{
Map _chartMap;
@Inject private MyServices _MyServices;
Product p=_MyServices.getProductById(idProduct);
_chartMap.put(idProduct,p);
}
Instead of
In my Page
@Inject _MyServices
@AplicationState _MyAso
_MyServices.AddProductToChart(idProduct,_MyAso.getMap());
And in services
..
MyServices.AddProductToChart(idProduct,map){
Product p=_MyServices.getProductById(idProduct);
_chartMap.put(idProduct,p);
}
It's basically the same but imho in the first model the separation of
responsabilities is higher and keeps the service DAO lean.
thanks for yor answer!
Bill Holloway wrote:
>
> Of course, you'll have the went-to-null trouble even passing the bits
> of data into your service as method args :)
>
> On Thu, May 8, 2008 at 2:38 PM, maxthesecond <[EMAIL PROTECTED]> wrote:
>>
>> How I'm suposed to get services inside an ASO?
>>
>> I placed my DAO objects in services I didn't need any sesion so far, but
>> at
>> a certain point I need an ASO the wich needs to make use of my DAO
>> services.
>>
>> btw I've notice an old post in wich the willing was the oposit; how to
>> acces
>> the ASO from a Services, such is the destiny of frameworks: give
>> satisfaction to all needs
>>
>> Thanks and never mind !
>> --
>> View this message in context:
>> http://www.nabble.com/T5-ASO---Services-tp17134860p17134860.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> --
> Bill @ PeoplePad
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/T5-ASO---Services-tp17134860p17141809.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 ASO & Service
Of course, you'll have the went-to-null trouble even passing the bits of data into your service as method args :) On Thu, May 8, 2008 at 2:38 PM, maxthesecond <[EMAIL PROTECTED]> wrote: > > How I'm suposed to get services inside an ASO? > > I placed my DAO objects in services I didn't need any sesion so far, but at > a certain point I need an ASO the wich needs to make use of my DAO services. > > btw I've notice an old post in wich the willing was the oposit; how to acces > the ASO from a Services, such is the destiny of frameworks: give > satisfaction to all needs > > Thanks and never mind ! > -- > View this message in context: > http://www.nabble.com/T5-ASO---Services-tp17134860p17134860.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Bill @ PeoplePad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 ASO & Service
Max, What I do in my app is pass the relevant bits of ASO data into my service methods as arguments. You could pass the entire ASO, but you might risk having it go null on you if the ASO gets set to null somewhere. Bill On Thu, May 8, 2008 at 2:38 PM, maxthesecond <[EMAIL PROTECTED]> wrote: > > How I'm suposed to get services inside an ASO? > > I placed my DAO objects in services I didn't need any sesion so far, but at > a certain point I need an ASO the wich needs to make use of my DAO services. > > btw I've notice an old post in wich the willing was the oposit; how to acces > the ASO from a Services, such is the destiny of frameworks: give > satisfaction to all needs > > Thanks and never mind ! > -- > View this message in context: > http://www.nabble.com/T5-ASO---Services-tp17134860p17134860.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Bill @ PeoplePad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [T5] ASO, BeanEditor and Interfaces
Martin,
You are very welcome.
Depending on whether there is a difference between an empty embedded object
versus a missing embedded object (is the address missing, or is it blank?),
there is another trick that makes NPE avoidance much easier.
You can add a dummy property (like boolean dummy = false;) to your embedded
object to force Hibernate to instantiate it. I've done this before for a
UserProfile embedded in a Person object. It means you have a database
column that serves no real purpose but it also means you never have to worry
about the embedded object being null after Hibernate retrieval.
Jonathan
> -Original Message-
> From: Kheldar666 [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 03, 2008 5:49 PM
> To: users@tapestry.apache.org
> Subject: RE: [T5] ASO, BeanEditor and Interfaces
>
>
> Yes ! that was it :)
>
> I indeed had an embedded Address with all fields empty ^^. Thank you very
> much to both of you :) !
>
> I owe you at least a beer :)
>
> Regards
>
> Martin
>
>
>
> Jonathan Barker wrote:
> >
> > Martin,
> >
> > I'm a bit confused about what you are trying to accomplish, but maybe I
> > can
> > toss out some ideas.
> >
> > If you have loaded a User object via Hibernate:
> >
> > Scenario 1: embedded Address
> > If the embedded address is all null / empty fields, then the Address
> > reference in User will be null. You may want to make sure the Address
> > field
> > is set before rendering. I've hit this before and had to set the
> address
> > (if null then new) immediately after loading from hibernate.
> >
> > Scenario 2: linked Address
> > The same problem as Scenario 1 will apply, plus you could run into
> > problems
> > if the User was loaded in an earlier session trying to follow the old
> > Address proxy.
> >
> > You may also want to look into the ASO documentation - specifically the
> > section at the bottom for ASO's requiring configuration. You could make
> > sure your address is non-null there.
> > http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
> >
> > Also, you can make sure your UserImpl constructor instantiates an empty
> > Address object.
> >
> > Jonathan
> >
> >
> >> -Original Message-
> >> From: Kheldar666 [mailto:[EMAIL PROTECTED]
> >> Sent: Sunday, February 03, 2008 1:53 PM
> >> To: users@tapestry.apache.org
> >> Subject: Re: [T5] ASO, BeanEditor and Interfaces
> >>
> >>
> >> Heu...
> >>
> >> I allready have a full Hibernate/Spring instantiation system that works
> >> perfectly well :-) .
> >>
> >> I'm not trying to instanciate a Bean via Tapestry. I try to edit one
> that
> >> is
> >> allready loaded.
> >>
> >> The problem for me comes from Tapestry beanEditor that tries -I think-
> to
> >> create an empty bean using the interface Address instead of AddressImpl
> >> when
> >> it creates is BeanModel.
> >>
> >> Maybe be I dont know how to explain my problem clearly enought...
> Sorry.
> >>
> >> Thank you for your help :)
> >>
> >> Martin
> >>
> >>
> >> Sven Homburg wrote:
> >> >
> >> > i think you missunderstood completely the sense of hibernate entities
> >> > and IOC serices.
> >> >
> >> > in your case i think it makes more sense to let instantiate the
> enties
> >> > by a factory class
> >> > please read http://www.hibernate.org/328.html
> >> >
> >> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
> >> >>
> >> >> Well by adding this to my module :
> >> >>
> >> >> public static void bind(ServiceBinder binder){
> >> >> binder.bind(User.class, UserImpl.class);
> >> >> binder.bind(Address.class, AddressImpl.class);
> >> >> }
> >> >>
> >> >> I solved the User instanciation problem. But It didn't solve the
> >> Address
> >> >> instanciation problem.
> >> >>
> >> >> In fact User model have an Address property. I want to user
> >> BeanEditForm
> >> >> to
> >> >> Edit both the User and is Address. This is the component :
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
RE: [T5] ASO, BeanEditor and Interfaces
Yes ! that was it :)
I indeed had an embedded Address with all fields empty ^^. Thank you very
much to both of you :) !
I owe you at least a beer :)
Regards
Martin
Jonathan Barker wrote:
>
> Martin,
>
> I'm a bit confused about what you are trying to accomplish, but maybe I
> can
> toss out some ideas.
>
> If you have loaded a User object via Hibernate:
>
> Scenario 1: embedded Address
> If the embedded address is all null / empty fields, then the Address
> reference in User will be null. You may want to make sure the Address
> field
> is set before rendering. I've hit this before and had to set the address
> (if null then new) immediately after loading from hibernate.
>
> Scenario 2: linked Address
> The same problem as Scenario 1 will apply, plus you could run into
> problems
> if the User was loaded in an earlier session trying to follow the old
> Address proxy.
>
> You may also want to look into the ASO documentation - specifically the
> section at the bottom for ASO's requiring configuration. You could make
> sure your address is non-null there.
> http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
>
> Also, you can make sure your UserImpl constructor instantiates an empty
> Address object.
>
> Jonathan
>
>
>> -Original Message-
>> From: Kheldar666 [mailto:[EMAIL PROTECTED]
>> Sent: Sunday, February 03, 2008 1:53 PM
>> To: users@tapestry.apache.org
>> Subject: Re: [T5] ASO, BeanEditor and Interfaces
>>
>>
>> Heu...
>>
>> I allready have a full Hibernate/Spring instantiation system that works
>> perfectly well :-) .
>>
>> I'm not trying to instanciate a Bean via Tapestry. I try to edit one that
>> is
>> allready loaded.
>>
>> The problem for me comes from Tapestry beanEditor that tries -I think- to
>> create an empty bean using the interface Address instead of AddressImpl
>> when
>> it creates is BeanModel.
>>
>> Maybe be I dont know how to explain my problem clearly enought... Sorry.
>>
>> Thank you for your help :)
>>
>> Martin
>>
>>
>> Sven Homburg wrote:
>> >
>> > i think you missunderstood completely the sense of hibernate entities
>> > and IOC serices.
>> >
>> > in your case i think it makes more sense to let instantiate the enties
>> > by a factory class
>> > please read http://www.hibernate.org/328.html
>> >
>> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
>> >>
>> >> Well by adding this to my module :
>> >>
>> >> public static void bind(ServiceBinder binder){
>> >> binder.bind(User.class, UserImpl.class);
>> >> binder.bind(Address.class, AddressImpl.class);
>> >> }
>> >>
>> >> I solved the User instanciation problem. But It didn't solve the
>> Address
>> >> instanciation problem.
>> >>
>> >> In fact User model have an Address property. I want to user
>> BeanEditForm
>> >> to
>> >> Edit both the User and is Address. This is the component :
>> >>
>> >>
>> >>
>> >>
>> >> Address
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> I set this in the AppModule for my address field can be detected by
>> the
>> >> BeanEditor :
>> >>
>> >> public static void
>> >> contributeDefaultDataTypeAnalyzer(MappedConfiguration,
>> String>
>> >> configuration) {
>> >> configuration.add(Address.class, "address");
>> >> }
>> >>
>> >> And I stiil have the InstantiationException. If I make direct
>> reference
>> >> to
>> >> the implementation classes that works fine (but I don't want to do it
>> >> that
>> >> way).
>> >>
>> >> I tried configuration.add(AddressImpl.class, "address"); but it does
>> not
>> >> work at all because tapestru can't detect the Address field in User
>> bean.
>> >>
>> >> Any ideas ?
>> >>
>> >> Regards,
>> >>
>> >> Martin
>> >>
>> >>
>> >>
>> >>
>> >> Sven Homburg wrote:
>> >> >
>> >> > this should
RE: [T5] ASO, BeanEditor and Interfaces
Martin,
I'm a bit confused about what you are trying to accomplish, but maybe I can
toss out some ideas.
If you have loaded a User object via Hibernate:
Scenario 1: embedded Address
If the embedded address is all null / empty fields, then the Address
reference in User will be null. You may want to make sure the Address field
is set before rendering. I've hit this before and had to set the address
(if null then new) immediately after loading from hibernate.
Scenario 2: linked Address
The same problem as Scenario 1 will apply, plus you could run into problems
if the User was loaded in an earlier session trying to follow the old
Address proxy.
You may also want to look into the ASO documentation - specifically the
section at the bottom for ASO's requiring configuration. You could make
sure your address is non-null there.
http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
Also, you can make sure your UserImpl constructor instantiates an empty
Address object.
Jonathan
> -Original Message-
> From: Kheldar666 [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 03, 2008 1:53 PM
> To: users@tapestry.apache.org
> Subject: Re: [T5] ASO, BeanEditor and Interfaces
>
>
> Heu...
>
> I allready have a full Hibernate/Spring instantiation system that works
> perfectly well :-) .
>
> I'm not trying to instanciate a Bean via Tapestry. I try to edit one that
> is
> allready loaded.
>
> The problem for me comes from Tapestry beanEditor that tries -I think- to
> create an empty bean using the interface Address instead of AddressImpl
> when
> it creates is BeanModel.
>
> Maybe be I dont know how to explain my problem clearly enought... Sorry.
>
> Thank you for your help :)
>
> Martin
>
>
> Sven Homburg wrote:
> >
> > i think you missunderstood completely the sense of hibernate entities
> > and IOC serices.
> >
> > in your case i think it makes more sense to let instantiate the enties
> > by a factory class
> > please read http://www.hibernate.org/328.html
> >
> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
> >>
> >> Well by adding this to my module :
> >>
> >> public static void bind(ServiceBinder binder){
> >> binder.bind(User.class, UserImpl.class);
> >> binder.bind(Address.class, AddressImpl.class);
> >> }
> >>
> >> I solved the User instanciation problem. But It didn't solve the
> Address
> >> instanciation problem.
> >>
> >> In fact User model have an Address property. I want to user
> BeanEditForm
> >> to
> >> Edit both the User and is Address. This is the component :
> >>
> >>
> >>
> >>
> >> Address
> >>
> >>
> >>
> >>
> >>
> >> I set this in the AppModule for my address field can be detected by the
> >> BeanEditor :
> >>
> >> public static void
> >> contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
> >> configuration) {
> >> configuration.add(Address.class, "address");
> >> }
> >>
> >> And I stiil have the InstantiationException. If I make direct reference
> >> to
> >> the implementation classes that works fine (but I don't want to do it
> >> that
> >> way).
> >>
> >> I tried configuration.add(AddressImpl.class, "address"); but it does
> not
> >> work at all because tapestru can't detect the Address field in User
> bean.
> >>
> >> Any ideas ?
> >>
> >> Regards,
> >>
> >> Martin
> >>
> >>
> >>
> >>
> >> Sven Homburg wrote:
> >> >
> >> > this should help you
> >> > http://wiki.apache.org/tapestry/Tapestry5HowToIocAndHibernate
> >> >
> >> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
> >> >>
> >> >> Hi Everybody,
> >> >>
> >> >> I was wondering if ASO and BeanEditor can work with Interfaces ? At
> >> the
> >> >> first sight it seems not possible.
> >> >>
> >> >> Let's say I have this Interface and Classes :
> >> >>
> >> >> public interface User {
> >> >> public int getId();
> >> >> public void setId(int id);
> >> >> public String getName();
> >&g
Re: [T5] ASO, BeanEditor and Interfaces
hmmm, i try to understand,
why do you mean, that the beaneditor should create
or instantiate anything for ?
if i not realy going wrong you must take care that any
class, you want to edit, is instantiated before.
and ofcourse you must feed the beaneditor with an instance
not an interface
2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
>
> Heu...
>
> I allready have a full Hibernate/Spring instantiation system that works
> perfectly well :-) .
>
> I'm not trying to instanciate a Bean via Tapestry. I try to edit one that is
> allready loaded.
>
> The problem for me comes from Tapestry beanEditor that tries -I think- to
> create an empty bean using the interface Address instead of AddressImpl when
> it creates is BeanModel.
>
> Maybe be I dont know how to explain my problem clearly enought... Sorry.
>
> Thank you for your help :)
>
> Martin
>
>
> Sven Homburg wrote:
> >
> > i think you missunderstood completely the sense of hibernate entities
> > and IOC serices.
> >
> > in your case i think it makes more sense to let instantiate the enties
> > by a factory class
> > please read http://www.hibernate.org/328.html
> >
> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
> >>
> >> Well by adding this to my module :
> >>
> >> public static void bind(ServiceBinder binder){
> >> binder.bind(User.class, UserImpl.class);
> >> binder.bind(Address.class, AddressImpl.class);
> >> }
> >>
> >> I solved the User instanciation problem. But It didn't solve the Address
> >> instanciation problem.
> >>
> >> In fact User model have an Address property. I want to user BeanEditForm
> >> to
> >> Edit both the User and is Address. This is the component :
> >>
> >>
> >>
> >>
> >> Address
> >>
> >>
> >>
> >>
> >>
> >> I set this in the AppModule for my address field can be detected by the
> >> BeanEditor :
> >>
> >> public static void
> >> contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
> >> configuration) {
> >> configuration.add(Address.class, "address");
> >> }
> >>
> >> And I stiil have the InstantiationException. If I make direct reference
> >> to
> >> the implementation classes that works fine (but I don't want to do it
> >> that
> >> way).
> >>
> >> I tried configuration.add(AddressImpl.class, "address"); but it does not
> >> work at all because tapestru can't detect the Address field in User bean.
> >>
> >> Any ideas ?
> >>
> >> Regards,
> >>
> >> Martin
> >>
> >>
> >>
> >>
> >> Sven Homburg wrote:
> >> >
> >> > this should help you
> >> > http://wiki.apache.org/tapestry/Tapestry5HowToIocAndHibernate
> >> >
> >> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
> >> >>
> >> >> Hi Everybody,
> >> >>
> >> >> I was wondering if ASO and BeanEditor can work with Interfaces ? At
> >> the
> >> >> first sight it seems not possible.
> >> >>
> >> >> Let's say I have this Interface and Classes :
> >> >>
> >> >> public interface User {
> >> >> public int getId();
> >> >> public void setId(int id);
> >> >> public String getName();
> >> >> public void setName(String name);
> >> >> }
> >> >>
> >> >> public class UserImpl implements User {
> >> >> //An implementation with Hibernate annotation for instance
> >> >> }
> >> >>
> >> >> Everywhere in Tapestry we use Interfaces for the IoC. But if I declare
> >> >> somewhere :
> >> >>
> >> >>
> >> >> @ApplicationState
> >> >> private User _user
> >> >>
> >> >>
> >> >> I have an InstanciationException (witch is normal, because Tapestry
> >> have
> >> >> no
> >> >> way to guess that it should instanciate UserImpl and it tries to
> >> >> instanciate
> >> >> an Interface).
> >> >>
> >> >> So my question is : is there a way to tell Tapestry to instanciate the
> >> >> right
> >> >> class and not the Interface (may be via contributing to some Service
> >> >> configuration or something ) ? Or should I wrote a simple data object
> >> >> that
> >> >> can be directly instanciated and some kind of translator that would
> >> >> convert
> >> >> my Data Object into the class used by my internal services ?
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15254725.html
> >> >> Sent from the Tapestry - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > with regards
> >> > Sven Homburg
> >> >
> >> > -
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >> >
> >> > -
> >> > best regards
> >> > Sven
> >> >
> >>
> >> --
> >> View this message in context:
> >> http:
Re: [T5] ASO, BeanEditor and Interfaces
Heu...
I allready have a full Hibernate/Spring instantiation system that works
perfectly well :-) .
I'm not trying to instanciate a Bean via Tapestry. I try to edit one that is
allready loaded.
The problem for me comes from Tapestry beanEditor that tries -I think- to
create an empty bean using the interface Address instead of AddressImpl when
it creates is BeanModel.
Maybe be I dont know how to explain my problem clearly enought... Sorry.
Thank you for your help :)
Martin
Sven Homburg wrote:
>
> i think you missunderstood completely the sense of hibernate entities
> and IOC serices.
>
> in your case i think it makes more sense to let instantiate the enties
> by a factory class
> please read http://www.hibernate.org/328.html
>
> 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
>>
>> Well by adding this to my module :
>>
>> public static void bind(ServiceBinder binder){
>> binder.bind(User.class, UserImpl.class);
>> binder.bind(Address.class, AddressImpl.class);
>> }
>>
>> I solved the User instanciation problem. But It didn't solve the Address
>> instanciation problem.
>>
>> In fact User model have an Address property. I want to user BeanEditForm
>> to
>> Edit both the User and is Address. This is the component :
>>
>>
>>
>>
>> Address
>>
>>
>>
>>
>>
>> I set this in the AppModule for my address field can be detected by the
>> BeanEditor :
>>
>> public static void
>> contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
>> configuration) {
>> configuration.add(Address.class, "address");
>> }
>>
>> And I stiil have the InstantiationException. If I make direct reference
>> to
>> the implementation classes that works fine (but I don't want to do it
>> that
>> way).
>>
>> I tried configuration.add(AddressImpl.class, "address"); but it does not
>> work at all because tapestru can't detect the Address field in User bean.
>>
>> Any ideas ?
>>
>> Regards,
>>
>> Martin
>>
>>
>>
>>
>> Sven Homburg wrote:
>> >
>> > this should help you
>> > http://wiki.apache.org/tapestry/Tapestry5HowToIocAndHibernate
>> >
>> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
>> >>
>> >> Hi Everybody,
>> >>
>> >> I was wondering if ASO and BeanEditor can work with Interfaces ? At
>> the
>> >> first sight it seems not possible.
>> >>
>> >> Let's say I have this Interface and Classes :
>> >>
>> >> public interface User {
>> >> public int getId();
>> >> public void setId(int id);
>> >> public String getName();
>> >> public void setName(String name);
>> >> }
>> >>
>> >> public class UserImpl implements User {
>> >> //An implementation with Hibernate annotation for instance
>> >> }
>> >>
>> >> Everywhere in Tapestry we use Interfaces for the IoC. But if I declare
>> >> somewhere :
>> >>
>> >>
>> >> @ApplicationState
>> >> private User _user
>> >>
>> >>
>> >> I have an InstanciationException (witch is normal, because Tapestry
>> have
>> >> no
>> >> way to guess that it should instanciate UserImpl and it tries to
>> >> instanciate
>> >> an Interface).
>> >>
>> >> So my question is : is there a way to tell Tapestry to instanciate the
>> >> right
>> >> class and not the Interface (may be via contributing to some Service
>> >> configuration or something ) ? Or should I wrote a simple data object
>> >> that
>> >> can be directly instanciated and some kind of translator that would
>> >> convert
>> >> my Data Object into the class used by my internal services ?
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15254725.html
>> >> Sent from the Tapestry - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> > --
>> > with regards
>> > Sven Homburg
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>> > -
>> > best regards
>> > Sven
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15255319.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> with regards
> Sven Homburg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> best regards
> Sven
>
--
View this message in context:
http://www.nabble.co
Re: [T5] ASO, BeanEditor and Interfaces
i think you missunderstood completely the sense of hibernate entities
and IOC serices.
in your case i think it makes more sense to let instantiate the enties
by a factory class
please read http://www.hibernate.org/328.html
2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
>
> Well by adding this to my module :
>
> public static void bind(ServiceBinder binder){
> binder.bind(User.class, UserImpl.class);
> binder.bind(Address.class, AddressImpl.class);
> }
>
> I solved the User instanciation problem. But It didn't solve the Address
> instanciation problem.
>
> In fact User model have an Address property. I want to user BeanEditForm to
> Edit both the User and is Address. This is the component :
>
>
>
>
> Address
>
>
>
>
>
> I set this in the AppModule for my address field can be detected by the
> BeanEditor :
>
> public static void
> contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
> configuration) {
> configuration.add(Address.class, "address");
> }
>
> And I stiil have the InstantiationException. If I make direct reference to
> the implementation classes that works fine (but I don't want to do it that
> way).
>
> I tried configuration.add(AddressImpl.class, "address"); but it does not
> work at all because tapestru can't detect the Address field in User bean.
>
> Any ideas ?
>
> Regards,
>
> Martin
>
>
>
>
> Sven Homburg wrote:
> >
> > this should help you
> > http://wiki.apache.org/tapestry/Tapestry5HowToIocAndHibernate
> >
> > 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
> >>
> >> Hi Everybody,
> >>
> >> I was wondering if ASO and BeanEditor can work with Interfaces ? At the
> >> first sight it seems not possible.
> >>
> >> Let's say I have this Interface and Classes :
> >>
> >> public interface User {
> >> public int getId();
> >> public void setId(int id);
> >> public String getName();
> >> public void setName(String name);
> >> }
> >>
> >> public class UserImpl implements User {
> >> //An implementation with Hibernate annotation for instance
> >> }
> >>
> >> Everywhere in Tapestry we use Interfaces for the IoC. But if I declare
> >> somewhere :
> >>
> >>
> >> @ApplicationState
> >> private User _user
> >>
> >>
> >> I have an InstanciationException (witch is normal, because Tapestry have
> >> no
> >> way to guess that it should instanciate UserImpl and it tries to
> >> instanciate
> >> an Interface).
> >>
> >> So my question is : is there a way to tell Tapestry to instanciate the
> >> right
> >> class and not the Interface (may be via contributing to some Service
> >> configuration or something ) ? Or should I wrote a simple data object
> >> that
> >> can be directly instanciated and some kind of translator that would
> >> convert
> >> my Data Object into the class used by my internal services ?
> >> --
> >> View this message in context:
> >> http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15254725.html
> >> Sent from the Tapestry - User mailing list archive at Nabble.com.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > --
> > with regards
> > Sven Homburg
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > -
> > best regards
> > Sven
> >
>
> --
> View this message in context:
> http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15255319.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
with regards
Sven Homburg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] ASO, BeanEditor and Interfaces
Well by adding this to my module :
public static void bind(ServiceBinder binder){
binder.bind(User.class, UserImpl.class);
binder.bind(Address.class, AddressImpl.class);
}
I solved the User instanciation problem. But It didn't solve the Address
instanciation problem.
In fact User model have an Address property. I want to user BeanEditForm to
Edit both the User and is Address. This is the component :
Address
I set this in the AppModule for my address field can be detected by the
BeanEditor :
public static void
contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
configuration) {
configuration.add(Address.class, "address");
}
And I stiil have the InstantiationException. If I make direct reference to
the implementation classes that works fine (but I don't want to do it that
way).
I tried configuration.add(AddressImpl.class, "address"); but it does not
work at all because tapestru can't detect the Address field in User bean.
Any ideas ?
Regards,
Martin
Sven Homburg wrote:
>
> this should help you
> http://wiki.apache.org/tapestry/Tapestry5HowToIocAndHibernate
>
> 2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
>>
>> Hi Everybody,
>>
>> I was wondering if ASO and BeanEditor can work with Interfaces ? At the
>> first sight it seems not possible.
>>
>> Let's say I have this Interface and Classes :
>>
>> public interface User {
>> public int getId();
>> public void setId(int id);
>> public String getName();
>> public void setName(String name);
>> }
>>
>> public class UserImpl implements User {
>> //An implementation with Hibernate annotation for instance
>> }
>>
>> Everywhere in Tapestry we use Interfaces for the IoC. But if I declare
>> somewhere :
>>
>>
>> @ApplicationState
>> private User _user
>>
>>
>> I have an InstanciationException (witch is normal, because Tapestry have
>> no
>> way to guess that it should instanciate UserImpl and it tries to
>> instanciate
>> an Interface).
>>
>> So my question is : is there a way to tell Tapestry to instanciate the
>> right
>> class and not the Interface (may be via contributing to some Service
>> configuration or something ) ? Or should I wrote a simple data object
>> that
>> can be directly instanciated and some kind of translator that would
>> convert
>> my Data Object into the class used by my internal services ?
>> --
>> View this message in context:
>> http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15254725.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> with regards
> Sven Homburg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> best regards
> Sven
>
--
View this message in context:
http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15255319.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] ASO, BeanEditor and Interfaces
this should help you
http://wiki.apache.org/tapestry/Tapestry5HowToIocAndHibernate
2008/2/3, Kheldar666 <[EMAIL PROTECTED]>:
>
> Hi Everybody,
>
> I was wondering if ASO and BeanEditor can work with Interfaces ? At the
> first sight it seems not possible.
>
> Let's say I have this Interface and Classes :
>
> public interface User {
> public int getId();
> public void setId(int id);
> public String getName();
> public void setName(String name);
> }
>
> public class UserImpl implements User {
> //An implementation with Hibernate annotation for instance
> }
>
> Everywhere in Tapestry we use Interfaces for the IoC. But if I declare
> somewhere :
>
>
> @ApplicationState
> private User _user
>
>
> I have an InstanciationException (witch is normal, because Tapestry have no
> way to guess that it should instanciate UserImpl and it tries to instanciate
> an Interface).
>
> So my question is : is there a way to tell Tapestry to instanciate the right
> class and not the Interface (may be via contributing to some Service
> configuration or something ) ? Or should I wrote a simple data object that
> can be directly instanciated and some kind of translator that would convert
> my Data Object into the class used by my internal services ?
> --
> View this message in context:
> http://www.nabble.com/-T5--ASO%2C-BeanEditor-and-Interfaces-tp15254725p15254725.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
with regards
Sven Homburg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 - ASO cannot be in the same package as the page?
Howard Lewis Ship wrote: > > By putting the ASO class into the pages package, Tapestry created an > enhanced version of the ASO class, as if it were a component. This > enhanced class is in the class loader used for pages, components and > mixins. The reference to the ASO in the page is a reference to the > enhanced version, not the normal version. The ASO that's injected is > from the normal class loader, not the enhanced class loader, thus a > ClassCastException. > I encountered the same problem by accident, but did suspect something quickly as I had moved the class and the exception showed up on the next refresh. Still it would be nice for Tapestry to report more precisely what has happened, if that's possible. Stephan -- http://www.stephan-schwab.com -- View this message in context: http://www.nabble.com/T5---ASO-cannot-be-in-the-same-package-as-the-page--tf3447765.html#a9622369 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 - ASO cannot be in the same package as the page?
By putting the ASO class into the pages package, Tapestry created an
enhanced version of the ASO class, as if it were a component. This
enhanced class is in the class loader used for pages, components and
mixins. The reference to the ASO in the page is a reference to the
enhanced version, not the normal version. The ASO that's injected is
from the normal class loader, not the enhanced class loader, thus a
ClassCastException.
On 3/22/07, Bogdan Calmac <[EMAIL PROTECTED]> wrote:
Hi Peter,
I see your point. Any class in the pages package can be accessed
through an URL and it doesn't make sense to store anything else than
pages there.
But on the other hand, the behaviour that I reported is totally
obscure and not in line with the nice error reporting of tapestry. If
somebody does put an ASO in the pages package because of ignorance (as
I did) a ClassCastException from a generated method is not likely to
guide to the source of the error. I see two ways to handle this
nicely:
1. When the @ApplicationState annotation is processed report an error
"An ASO cannot be part of the special tapestry packages". This way it
would take 2 minutes to fix the problem instead of 2 hours.
2. In the documentation for the ASO mention that it is not a good
practice to put the ASO in any of tapestry specific packages (pages,
components, ...) but let the people do it if they really want to.
This kind of small thing make quite a difference when starting to work
with a framework like Tapestry where there's a lot going on behind the
scene and as a newcomer you have no ideea that something apparently OK
is not what it seems.
Thanks,
Bogdan.
On 3/22/07, Anjana Gopinath <[EMAIL PROTECTED]> wrote:
> I beleive you are supposed to put only your page classes in the page
> folder. Refer tapestry 5 tutorial, page 19.
>
>
>
>
>
> Anjana Gopinath
>
>
>
>
>
>
> On Mar 22, 2007, at 10:07 AM, Bogdan Calmac wrote:
>
> > After creating my own ASO object, I kept getting the
> > ClassCastExeception below when accessing it, until I had the
> > inspiration to move the ASO in a different package than the page. Then
> > it worked fine. Is this just a bug or intentional design?
> >
> > This is the exception (with 5.0.3). The ASO reader throws a
> > ClassCastException:
> > Caused by: java.lang.ClassCastException:
> > org.byteberry.survey.pages.SurveySession
> > at org.byteberry.survey.pages.SurveyDetail2._$read_surveySession
> > (SurveyDetail2.java)
> > at org.byteberry.survey.pages.SurveyDetail2.getQuestion0
> > (SurveyDetail2.java:55)
> > at $PropertyConduit_11179d07ce4.get
> > ($PropertyConduit_11179d07ce4.java)
> > at org.apache.tapestry.internal.bindings.PropBinding.get
> > (PropBinding.java:54)
> >
> > For more details, the ASO is defined with:
> >
> > @ApplicationState
> > private SurveySession surveySession;
> >
> >
> > and then accessed in:
> >
> > public SurveyQuestion getQuestion0() throws SQLException
> > {
> >return surveySession.questions.get(0);
> > }
> >
> >
> > Thanks,
> >
> > Bogdan Calmac.
> >
> > -
> > 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]
Re: T5 - ASO cannot be in the same package as the page?
Hi Peter,
I see your point. Any class in the pages package can be accessed
through an URL and it doesn't make sense to store anything else than
pages there.
But on the other hand, the behaviour that I reported is totally
obscure and not in line with the nice error reporting of tapestry. If
somebody does put an ASO in the pages package because of ignorance (as
I did) a ClassCastException from a generated method is not likely to
guide to the source of the error. I see two ways to handle this
nicely:
1. When the @ApplicationState annotation is processed report an error
"An ASO cannot be part of the special tapestry packages". This way it
would take 2 minutes to fix the problem instead of 2 hours.
2. In the documentation for the ASO mention that it is not a good
practice to put the ASO in any of tapestry specific packages (pages,
components, ...) but let the people do it if they really want to.
This kind of small thing make quite a difference when starting to work
with a framework like Tapestry where there's a lot going on behind the
scene and as a newcomer you have no ideea that something apparently OK
is not what it seems.
Thanks,
Bogdan.
On 3/22/07, Anjana Gopinath <[EMAIL PROTECTED]> wrote:
I beleive you are supposed to put only your page classes in the page
folder. Refer tapestry 5 tutorial, page 19.
Anjana Gopinath
On Mar 22, 2007, at 10:07 AM, Bogdan Calmac wrote:
> After creating my own ASO object, I kept getting the
> ClassCastExeception below when accessing it, until I had the
> inspiration to move the ASO in a different package than the page. Then
> it worked fine. Is this just a bug or intentional design?
>
> This is the exception (with 5.0.3). The ASO reader throws a
> ClassCastException:
> Caused by: java.lang.ClassCastException:
> org.byteberry.survey.pages.SurveySession
> at org.byteberry.survey.pages.SurveyDetail2._$read_surveySession
> (SurveyDetail2.java)
> at org.byteberry.survey.pages.SurveyDetail2.getQuestion0
> (SurveyDetail2.java:55)
> at $PropertyConduit_11179d07ce4.get
> ($PropertyConduit_11179d07ce4.java)
> at org.apache.tapestry.internal.bindings.PropBinding.get
> (PropBinding.java:54)
>
> For more details, the ASO is defined with:
>
> @ApplicationState
> private SurveySession surveySession;
>
>
> and then accessed in:
>
> public SurveyQuestion getQuestion0() throws SQLException
> {
>return surveySession.questions.get(0);
> }
>
>
> Thanks,
>
> Bogdan Calmac.
>
> -
> 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]
Re: T5 - ASO cannot be in the same package as the page?
I beleive you are supposed to put only your page classes in the page
folder. Refer tapestry 5 tutorial, page 19.
Anjana Gopinath
On Mar 22, 2007, at 10:07 AM, Bogdan Calmac wrote:
After creating my own ASO object, I kept getting the
ClassCastExeception below when accessing it, until I had the
inspiration to move the ASO in a different package than the page. Then
it worked fine. Is this just a bug or intentional design?
This is the exception (with 5.0.3). The ASO reader throws a
ClassCastException:
Caused by: java.lang.ClassCastException:
org.byteberry.survey.pages.SurveySession
at org.byteberry.survey.pages.SurveyDetail2._$read_surveySession
(SurveyDetail2.java)
at org.byteberry.survey.pages.SurveyDetail2.getQuestion0
(SurveyDetail2.java:55)
at $PropertyConduit_11179d07ce4.get
($PropertyConduit_11179d07ce4.java)
at org.apache.tapestry.internal.bindings.PropBinding.get
(PropBinding.java:54)
For more details, the ASO is defined with:
@ApplicationState
private SurveySession surveySession;
and then accessed in:
public SurveyQuestion getQuestion0() throws SQLException
{
return surveySession.questions.get(0);
}
Thanks,
Bogdan Calmac.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 - ASO cannot be in the same package as the page?
Not 100% sure, but it seems like Tapestry has designated
my.package.pagesfor Tapestry Pages (convention) and
my.package.components for Tapestry Components (convention again). So
Tapestry will treat the classes in those packages as pages/components
respectively. It is likely a better idea anyway to keep your data objects in
a separate package from your pages :-)
On 3/22/07, Bogdan Calmac <[EMAIL PROTECTED]> wrote:
After creating my own ASO object, I kept getting the
ClassCastExeception below when accessing it, until I had the
inspiration to move the ASO in a different package than the page. Then
it worked fine. Is this just a bug or intentional design?
This is the exception (with 5.0.3). The ASO reader throws a
ClassCastException:
Caused by: java.lang.ClassCastException:
org.byteberry.survey.pages.SurveySession
at org.byteberry.survey.pages.SurveyDetail2._$read_surveySession(
SurveyDetail2.java)
at org.byteberry.survey.pages.SurveyDetail2.getQuestion0(
SurveyDetail2.java:55)
at
$PropertyConduit_11179d07ce4.get($PropertyConduit_11179d07ce4.java)
at org.apache.tapestry.internal.bindings.PropBinding.get(
PropBinding.java:54)
For more details, the ASO is defined with:
@ApplicationState
private SurveySession surveySession;
and then accessed in:
public SurveyQuestion getQuestion0() throws SQLException
{
return surveySession.questions.get(0);
}
Thanks,
Bogdan Calmac.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Peter Beshai
Computer Science Student
University of Waterloo
Re: T5 ASO
Thats true. My code is more clean now!! Thanks to everyone who helped me out, i am almost done with my mini project in Tapestry 5. This is the 5th day since i started it, i wouldnt have reached here without the support of this community. Thanks!!! Anjana Gopinath On Mar 21, 2007, at 11:20 AM, Ted Steen wrote: 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 appList; >> >> public ArrayList 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 defin
Re: T5 ASO
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 appList; >> >> public ArrayList 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, re
Re: T5 ASO
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 appList; public ArrayList 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
Re: T5 ASO
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 appList; public ArrayList 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
Re: T5 ASO
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 appList; public ArrayList 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]
Re: T5 ASO
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]
Re: T5 ASO
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]
Re: T5 ASO
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]
Re: T5 ASO
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]
Re: T5 ASO
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]
