I had the idea while looking at this benchmark here: http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/throughput.gif
I am currently trying out Resin as it allows to use PHP and Servlets at the same time - so you can mix old PHP code with Tapestry on a single webserver and replace parts of the web application with PHP or Tapestry depending on whats faster in a certain situation. A typical example I have problems with in Tapestry/Hibernate is the following: - a table that displays an object - buttons or additional components on the table cells that depend on other objects In this case you have several database queries....one for the outer loop and one for the inner loops. In theory you could define a virtual new object in Hibernate that does some joins or unions that will result in just one query in the outer loop...and then it works quite fast. I like Hibernate as long as you can use your objects directly...but using Hibernate for joins and unions is not much fun.... So such a table would benefit a lot if is was cached...even if the individual queries would be cached you still had to do all the loops and parsing of the templates. -------- Original-Nachricht -------- > Datum: Tue, 18 Mar 2008 18:22:01 +0100 > Von: "Martin Kersten" <[EMAIL PROTECTED]> > An: "Tapestry users" <users@tapestry.apache.org> > Betreff: AW: @Cached and caching in general > You might want to know what tapestry does with your templates. > Tapestry reads your template and parses it - only once it changes! > So generating two pages (even with different content) just results > in using a parsed, preprocessed in memory representation of your > template. So tapestry strictly avoids disk-access and parsing > in production (when processing all templates on startup is > enabled). > > So there is no need for the older cache it hack. As I mentioned > it is easy to play with your own cache implementation. But be > carefull about the components you place inside your cache. You > know context and event handling. But for displaying 'cached' content > it might be an option. > > If you go ahead and try it you may post your benchmarks. I don't > know who has stretched it before but I guess caching is always a > hot topic so if you can provide new insides your are welcome. > > > Cheers, > > Martin (Kersten) > > > > -----Ursprüngliche Nachricht----- > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 18. März 2008 18:15 > An: Tapestry users > Betreff: AW: @Cached and caching in general > > > The problem is context I guess. Usally your component depends on lots > > of stuff. Parameters, URL, Services, Page-state, component state, > > HTTP-Parameters and so on. > > Yes...but it must be possible somehow as some PHP template engines also do > it. Isn't there already some mechanism in the internals of Tapestry that > keeps track of that even now? > > --------------------------------------------------------------------- > 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]
