On Wed, 19 May 2010 18:09:43 -0300, Pete Poulos <pete.pou...@gmail.com>
wrote:
* I would need to create a class to wrap the message since I don't
like the idea of using the String type for an SSO since SSO are
injected based on type and not name.
Absolutely right.
* SSOs are not cleared automatically after a Flash persisted item and
could therefore be a source of bugs if I forget to clear it to null.
Absolutely right.
* There's also the fact that you can't check whether an SSO is null
without forcing it to be instantiated. Therefore you have to
introduce an extra boolean field to track whether it has been set...
Not quite right. :P Use @SessionState(create = false) and it will not be
created automatically, leaving the corresponding field null.
creating the SSO, you should do so." However, I suspect that using
flash persistence incurs a similar penalty, however the docs say
nothing about this.
From what I understood from the FlashPersistentFieldStrategy and
AbstractSessionPersistentFieldStrategy classes, just checking if a
@Persist("flash") is null doesn't create a session.
That being the case I wasn't clear whether SSOs
incurred a higher penalty than using flash persistence or not.
Just a little bit more of memory comsumption because of the extra class.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
