Am 02.02.2011 um 08:16 schrieb Kalium:
Sorry if this is a dead horse that's being resurrected, I just got thinking about it though. I've read this in regards to stateless widgets http://docs.turbogears.org/1.0/StatelessWidgets http://groups.google.com/group/turbogears/tree/browse_frm/thread/74926e779c1da137/0189b1618e09b9c4 Whilst I can understand the use of using widgets in a stateless manner, none of the arguments seem to really give me a good reason why not to create various instances of the same widget (apart from the validate decorator issue). The other reasons are a bit wishy washy and somewhat dogmatic (no offence intended). One of the reasons I don't always rely on stateless widgets is that sometimes I may be wanting to use a large number of variable attributes(I'm talking about 20+ perhaps) for the one widget. This means that each time I return from my controller with the widget I have to pass all those variables as well. I find it easier (both to code and to read) to create the instance with all the vars in the controller, then simply return the widget, rather that to return the slew of vars as well and then account for them in the template where the display() is called. Am I a bad person for thinking about widgets in this manner? Are there other caveats I am missing?
I have to admit that my last working with TG widget is >3 years back, since then I've moved on to the slightly greener pastures of TW1. But they are static as well, and there are a few reasons to keep them stateless:
- static content, such as JS, CSS + at the least the template. If you instantiate these every time, you end up with either needlessly complex code to determine that you can use cached versions (which might actually not even possible to do so), or you simply create memory leaks. - said static content can be extracted from your application for static serving through a faster web-server, such as apache. And even aggregated. Both isn't possible with runtime widgets. - validation of forms becomes impossible or hard to do, or dependend on flaky constructions based on sessions.
So, I think there are some valid points for designing widgets stateless. But if using them stateful *actually* harms you only profiling of performance and memory utilization can show.
Diez -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
