Application State Objects, is there an alternative?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Application State Objects, is there an alternative?

richard.hensley
I've been reviewing the application state object idea in Tapestry 4.0, I
agree that it is a reasonable extension to the existing Visit and Global
objects, however I find the setup and use to be overly complex. I know I
could just use a Visit and be done, but I want something better.

My idea is to allow persistent page properties to be shared within a name
space. So, for example, the following property specification when used on
several components or pages, would have what ever value was last stored in
the property.

<property name="accountNumber" persistence="session"
shared="account.information" />

So, any component or page that declares a property named accountNumber with
a shared attribute of "account.information" would be sharing a common
object.

I think this would help answer the fairly common question of "how do I share
data amongst pages". The current thinking for Tapestry 4.0 would be "use
Application State Objects", and oh by the way you have to learn how to make
a hivemind configuration. I would like the answer to be "use shared
persistent page properties with the shared attribute".

I've been working on a design that seems workable, but I thought I would run
the general idea past the Tapestry developers before going much further.

I will start another thread called Shared Persistent Page Properties with
the design information in a little while.

Richard


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Application State Objects, is there an alternative?

Howard Lewis Ship
It's an interesting idea; I think injection would work a bit differently,
since if two pages are attached to a request that share data, changes in one
should be immediately visible in the other. That implies that the getter and
setter should delegate out to some common shared data object.

Outside the issue of contributing to HiveMind, I'm not seeing the big
advantage. The HiveMInd would be rather rote:

<contribution configuration-id="tapestry.state.ApplicationObjects">
<state-object name="myShared" scope="session">
<create-instance class="com.example.MyShared"/>
</state-object>
</contribution>

And, in your page spec:

<inject property="myShared" type="state" object="myShared"/>


On 5/13/05, Hensley, Richard <[hidden email]> wrote:

>
> I've been reviewing the application state object idea in Tapestry 4.0, I
> agree that it is a reasonable extension to the existing Visit and Global
> objects, however I find the setup and use to be overly complex. I know I
> could just use a Visit and be done, but I want something better.
>
> My idea is to allow persistent page properties to be shared within a name
> space. So, for example, the following property specification when used on
> several components or pages, would have what ever value was last stored in
> the property.
>
> <property name="accountNumber" persistence="session"
> shared="account.information" />
>
> So, any component or page that declares a property named accountNumber
> with
> a shared attribute of "account.information" would be sharing a common
> object.
>
> I think this would help answer the fairly common question of "how do I
> share
> data amongst pages". The current thinking for Tapestry 4.0 would be "use
> Application State Objects", and oh by the way you have to learn how to
> make
> a hivemind configuration. I would like the answer to be "use shared
> persistent page properties with the shared attribute".
>
> I've been working on a design that seems workable, but I thought I would
> run
> the general idea past the Tapestry developers before going much further.
>
> I will start another thread called Shared Persistent Page Properties with
> the design information in a little while.
>
> Richard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Reply | Threaded
Open this post in threaded view
|

Re: Application State Objects, is there an alternative?

Henri Dupre
On 5/13/05, Howard Lewis Ship <[hidden email]> wrote:
> <inject property="myShared" type="state" object="myShared"/>
Or what about being able to declare the injections in the .application file?
Something like:
<inject property="myShared" type="state" object="myShared" target="*"/>
to inject the property in all the pages?

It would be really nice a mechanism to inject a property in all pages.
In 90% of my pages, I just need to inject the main spring bean. I
ended up writing that lookup in Java in a page class that all my pages
inherit but I'd rather would write that in a declarative way.

Henri.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Application State Objects, is there an alternative?

Howard Lewis Ship
This is where annotations and a little bit of inheritance would go a long
way!

On 5/13/05, Henri Dupre <[hidden email]> wrote:

>
> On 5/13/05, Howard Lewis Ship <[hidden email]> wrote:
> > <inject property="myShared" type="state" object="myShared"/>
> Or what about being able to declare the injections in the .application
> file?
> Something like:
> <inject property="myShared" type="state" object="myShared" target="*"/>
> to inject the property in all the pages?
>
> It would be really nice a mechanism to inject a property in all pages.
> In 90% of my pages, I just need to inject the main spring bean. I
> ended up writing that lookup in Java in a page class that all my pages
> inherit but I'd rather would write that in a declarative way.
>
> Henri.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Reply | Threaded
Open this post in threaded view
|

Re: Application State Objects, is there an alternative?

Ron Piterman
In reply to this post by Howard Lewis Ship
????? Howard Lewis Ship:

> It's an interesting idea; I think injection would work a bit differently,
> since if two pages are attached to a request that share data, changes in one
> should be immediately visible in the other. That implies that the getter and
> setter should delegate out to some common shared data object.
>
> Outside the issue of contributing to HiveMind, I'm not seeing the big
> advantage. The HiveMInd would be rather rote:
>
> <contribution configuration-id="tapestry.state.ApplicationObjects">
> <state-object name="myShared" scope="session">
> <create-instance class="com.example.MyShared"/>
> </state-object>
> </contribution>
>
> And, in your page spec:
>
> <inject property="myShared" type="state" object="myShared"/>

The (big) difference is that richards idea comes from tapestry - it
would be great if it would work that way. If I am working with tapestry
I want tapestry to give me the functionality, and not mess up with
hiveminde.

Ofcouse, howard, for you its straight forward, but not to us users of
tapestry. This deffinetley becomes too complex in order to accomplish
very simple tasks.

It would be threrfore great if tapestry would hook hivemind and not the
otherway around. Just like it will (probably?) will be done with the
visit object. I use it from tapestry. On the backstage, its really
doesn't mutter to me what saltos Tapestry does to come along with
hivemind, as long as I don't have to mess up with it.

So, the definition of such a state-object would belong to the
.application or .library, instrad of in the hivemind configuration. It
is a huge difference between (in the .application/.library):

<bean name="myShared" scope="session" type="com.example.MyShared"
instanciate="yes">...
</bean>

and the (excuse me...) mess written above in hiveminde.

Eventhough I am not a tapestry dev, I would suggest creating a list of
such common "tasks" and creating a tapestry hook for them (just like the
visit and the global...). This one should IMO be inside. All other tasks
which inject uncommon drugs like mathadon can stay on the hivemind side
of the moon, and junkies that want to can go through the deprivation
program...

Cheers,
Ron

>
>
> On 5/13/05, Hensley, Richard <[hidden email]> wrote:
>
>>I've been reviewing the application state object idea in Tapestry 4.0, I
>>agree that it is a reasonable extension to the existing Visit and Global
>>objects, however I find the setup and use to be overly complex. I know I
>>could just use a Visit and be done, but I want something better.
>>
>>My idea is to allow persistent page properties to be shared within a name
>>space. So, for example, the following property specification when used on
>>several components or pages, would have what ever value was last stored in
>>the property.
>>
>><property name="accountNumber" persistence="session"
>>shared="account.information" />
>>
>>So, any component or page that declares a property named accountNumber
>>with
>>a shared attribute of "account.information" would be sharing a common
>>object.
>>
>>I think this would help answer the fairly common question of "how do I
>>share
>>data amongst pages". The current thinking for Tapestry 4.0 would be "use
>>Application State Objects", and oh by the way you have to learn how to
>>make
>>a hivemind configuration. I would like the answer to be "use shared
>>persistent page properties with the shared attribute".
>>
>>I've been working on a design that seems workable, but I thought I would
>>run
>>the general idea past the Tapestry developers before going much further.
>>
>>I will start another thread called Shared Persistent Page Properties with
>>the design information in a little while.
>>
>>Richard
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Application State Objects, is there an alternative?

Ron Piterman
I if I am already on drugs...
maybe calling Tapestry 4.0 heroin would be better than picasso... ;-)


????? Ron Piterman:

> ????? Howard Lewis Ship:
>
>> It's an interesting idea; I think injection would work a bit
>> differently, since if two pages are attached to a request that share
>> data, changes in one should be immediately visible in the other. That
>> implies that the getter and setter should delegate out to some common
>> shared data object.
>>
>> Outside the issue of contributing to HiveMind, I'm not seeing the big
>> advantage. The HiveMInd would be rather rote:
>>
>> <contribution configuration-id="tapestry.state.ApplicationObjects">
>> <state-object name="myShared" scope="session">
>> <create-instance class="com.example.MyShared"/>
>> </state-object>
>> </contribution>
>>
>> And, in your page spec:
>>
>> <inject property="myShared" type="state" object="myShared"/>
>
>
> The (big) difference is that richards idea comes from tapestry - it
> would be great if it would work that way. If I am working with tapestry
> I want tapestry to give me the functionality, and not mess up with
> hiveminde.
>
> Ofcouse, howard, for you its straight forward, but not to us users of
> tapestry. This deffinetley becomes too complex in order to accomplish
> very simple tasks.
>
> It would be threrfore great if tapestry would hook hivemind and not the
> otherway around. Just like it will (probably?) will be done with the
> visit object. I use it from tapestry. On the backstage, its really
> doesn't mutter to me what saltos Tapestry does to come along with
> hivemind, as long as I don't have to mess up with it.
>
> So, the definition of such a state-object would belong to the
> .application or .library, instrad of in the hivemind configuration. It
> is a huge difference between (in the .application/.library):
>
> <bean name="myShared" scope="session" type="com.example.MyShared"
> instanciate="yes">...
> </bean>
>
> and the (excuse me...) mess written above in hiveminde.
>
> Eventhough I am not a tapestry dev, I would suggest creating a list of
> such common "tasks" and creating a tapestry hook for them (just like the
> visit and the global...). This one should IMO be inside. All other tasks
> which inject uncommon drugs like mathadon can stay on the hivemind side
> of the moon, and junkies that want to can go through the deprivation
> program...
>
> Cheers,
> Ron
>
>>
>>
>> On 5/13/05, Hensley, Richard <[hidden email]> wrote:
>>
>>> I've been reviewing the application state object idea in Tapestry 4.0, I
>>> agree that it is a reasonable extension to the existing Visit and Global
>>> objects, however I find the setup and use to be overly complex. I know I
>>> could just use a Visit and be done, but I want something better.
>>>
>>> My idea is to allow persistent page properties to be shared within a
>>> name
>>> space. So, for example, the following property specification when
>>> used on
>>> several components or pages, would have what ever value was last
>>> stored in
>>> the property.
>>>
>>> <property name="accountNumber" persistence="session"
>>> shared="account.information" />
>>>
>>> So, any component or page that declares a property named
>>> accountNumber with
>>> a shared attribute of "account.information" would be sharing a common
>>> object.
>>>
>>> I think this would help answer the fairly common question of "how do
>>> I share
>>> data amongst pages". The current thinking for Tapestry 4.0 would be "use
>>> Application State Objects", and oh by the way you have to learn how
>>> to make
>>> a hivemind configuration. I would like the answer to be "use shared
>>> persistent page properties with the shared attribute".
>>>
>>> I've been working on a design that seems workable, but I thought I
>>> would run
>>> the general idea past the Tapestry developers before going much further.
>>>
>>> I will start another thread called Shared Persistent Page Properties
>>> with
>>> the design information in a little while.
>>>
>>> Richard
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Application State Objects, is there an alternative?

Eugene Lucash
In reply to this post by richard.hensley
Agree with (some points of) Ron Piterman
Hivemind extension points too complicated for
simple things. Moving to application or library is better


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]