>> I considered this, but the documentation for SessionState makes it >> sound like it is a very heavy handed solution, > > Why? Just curious. :)
>From an implementation perspective... * 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. * 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. * 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... >.< >From a performance perspective: * from the docs "Scalable web applications do not create the server-side session needlessly. If you can avoid creating the session, especially on first access to your web application, you will be able to handle an order of magnitude more users. So, if you can avoid 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. That being the case I wasn't clear whether SSOs incurred a higher penalty than using flash persistence or not. * I'm just speculating here, but since flash persistence has a well defined lifespan I imagine that there are optimizations that could be done to improve it's performance especially with respect to server clustering (even if no optimizations are done currently). However, as I have little experience with this kind of thing I could be very wrong. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
