Hi, Howard M. Lewis Ship wrote:
>However, I'm loath to do this ... primarily because I'm nervous about giving >the developer the rope needed to easily hang themself. > > i think caching on the HTML level is actually useful (you might have display logic that is quite complex, or has a relatively large overhead but at the same time pretty much static - i know, i do :). In the JSP world, i've been using the OpenSymphony cache tags, works fine.. and of course, you can hang yourself with it :) but at least it's very easy :) having HTML caching is _not_ a replacement for various application specific caches, it's an additional level. >More caching problems: do you cache for a single user, for a single locale, >etc. > > the cache key has to be generated by the application developer. also, making a runtime decision about _not_ caching for this request is also fundemental, as it also remedies the following problem >Finally, theres' the issue of URLs which may have to be encoded with the >caller's HttpSession id. > > not caching in this case is probably a decent solution for most cases. how many users have cookies turned off anyway? caching is for the other 99% :) >efficiently than Tapestry can quickly generate the appropriate HTML. If I >*ever* get a chance to work on Sabertooth again ... it'll have a lot of >smart caching built in. > btw, i've seen your plans for sabertooth. i think you should take a look at Hibernate (http://hibernate.sourceforge.net/), seems to be pretty close in spirit... best regards, viktor _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
