hi hugo,

i think what you ask for is not possible because Tapestry 5 generates 
proxies to access the ASOs. If you set it to null no proxy will be 
available 
to check whether there is a new instance in the session. You have the 
same problem when you use Hibernate with lazy fields/lists. you always
see the proxies.

i'm not sure but all i can think of to implement your feature 
request/improvemnt 
would be to move the ASO logic into the pageAttached events.... but i 
think this
would require some changes... 

g
kris






Hugo Palma <[EMAIL PROTECTED]> 
21.12.2007 14:11
Bitte antworten an
"Tapestry development" <[email protected]>


An
Tapestry development <[email protected]>
Kopie

Thema
Re: [jira] Created: (TAPESTRY-1991) It should be easy to initialize an ASO 
to null






I know the workarounds, i just don't see the point in any of them.
This should be straight forward, i shouldn't have to use any workaround.

What's the downside of adding this behaviour to the ASO logic ?


Davor Hrg wrote:
>  a boolean value keeping score if the ASO was actually created is
> needed to avoid creating expensive objects on sites with hundreds of
> requests per second. Creating session data for users too early was
> a killer for many apps in all web languages/scripts/frameworks.
>
> instead forcing aso to be null, you can depend on properties inside it
>
> you can chack if aso.user_data!=null
>
> or have a boolean property for /logged in / not
>
>
> Davor Hrg
>
> On Dec 21, 2007 11:12 AM, Hugo Palma <[EMAIL PROTECTED]> wrote:
> 
>> Yes, the default semantics is that it will only create the ASO instance
>> once you try to access it.
>> Still, it seems to me that many times this semantics doesn't really 
make
>> sense, in the cases where the ASO being null has a meaning. The 
simplest
>> case being for example when you want to keep as an ASO the logged user.
>>
>> I know the docs say that you can keep a boolean value keeping score if
>> the ASO was actually created or not, but to me this seems to go against
>> everything T5 stands for. This kind of thing really should be easy.
>>
>>
>> Davor Hrg wrote:
>> 
>>> I haven't checked it in practice, I belived what docs say:
>>> 
http://tapestry.formos.com/nightly/tapestry5/tapestry-core/guide/appstate.html

>>>
>>> I think the object will not be created if you do not try to access the 
variable.
>>>
>>> Davor Hrg
>>>
>>> On Dec 20, 2007 4:36 PM, Hugo Palma (JIRA) <[email protected]> 
wrote:
>>>
>>> 
>>>> It should be easy to initialize an ASO to null
>>>> ----------------------------------------------
>>>>
>>>>                  Key: TAPESTRY-1991
>>>>                  URL: 
https://issues.apache.org/jira/browse/TAPESTRY-1991
>>>>              Project: Tapestry
>>>>           Issue Type: Improvement
>>>>           Components: Framework
>>>>     Affects Versions: 5.0.6
>>>>             Reporter: Hugo Palma
>>>>             Priority: Minor
>>>>
>>>>
>>>> By default an ASO is never null. It's automatically created using the 
ASO class default constructor.
>>>> It's many times needed to have the null value in an ASO, for example 
if i want to keep the logged in user in an ASO.
>>>>
>>>> Right now we can do this by contributing a new 
ApplicationStateCreator to the ApplicationStateManager but it seems to me 
that should be as easy as providing a parameter to the @ApplicationState 
indicating that you don't want it to be automatically initialized.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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]
>
>
> 

Reply via email to