I concur, the two StateObjectFactories and the tests that I wrote were
very light classes.
They essentially just copy/inject their immutable state to the new
instance they are generating -- functionality that mimics, in a very
inflexible and watered down way, the DI facilities provided by Hivemind
>> Are you referring to the simplicity of implementing the
StateObjectFactory or bypassing
>>it?
>
>Implementing.
I concur, the two StateObjectFactories and the tests that I wrote were
very light classes.
They essentially just copy/inject their immutable state to the new
instance they are genera
Implementing.
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/engine/state/InstantiateClassStateObjectFactory.java?view=markup
On 11/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
--> how simple / easy it is to replace StateObjectFacto
--> how simple / easy it is to replace StateObjectFactory itself
Are you referring to the simplicity of implementing the
StateObjectFactory or bypassing it?
Carlos
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
I think the reasoning might be because of how simple / easy it is to
replace StateObjectFactory itself. Perhaps this area could use some
work though. Not sure.
On 11/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I was wondering why the tapestry.state.StateObjectContribution does not
suppor
