Tobias is right to ask about his, I'm usin php for a long time now and output_buffer functions "ob_*" are great for simplifying complex pages, adding caching without interferring with internal code....
people have asked about getting html output of page and etc. if framework would allow access to markup on afterRenderTemplate and if markup could be forced to serialize all HTML of the current element it would allow creating a simple component that can wrap a part of (processor heavy) code and catch the rendered markup. Then it would allow it self to be rendered normaly only in some intervals and produce cached raw output otherwise. this would be very similar to output_buffer tricks in php. Davor Hrg On Tue, Mar 18, 2008 at 6:25 PM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: > That's a special case, really. Do what you want. > > -Filip > > > > On 2008-03-18 18:20, Tobias Marx wrote: > > Ok...let's say factor 10 (unless you have many loops inside of loops > inside of loops that use queries on large tables). > > > > -------- Original-Nachricht -------- > >> Datum: Tue, 18 Mar 2008 18:14:28 +0100 > >> Von: "Filip S. Adamsen" <[EMAIL PROTECTED]> > >> An: Tapestry users <users@tapestry.apache.org> > >> Betreff: Re: AW: @Cached and caching in general > > > >> A factor 100?? C'mon. If, and I stress IF, your application would > >> benefit that much from this, fine. But Tapestry 5 applications in > >> general would - I guarantee you - not see such an improvement. > >> > >> -Filip > >> > >> On 2008-03-18 18:07, Tobias Marx wrote: > >>> My theory is that such a disk-caching behaviour could speed up Tapestry > >> applications by factor 100....although Tapestry 5 is quite fast. > >>> The template parsing is still quite slow because it uses Velocity and > >> everything that avoids template parsing would increase the speed a lot. > >>> > >>> -------- Original-Nachricht -------- > >>>> Datum: Tue, 18 Mar 2008 18:01:40 +0100 > >>>> Von: "Martin Kersten" <[EMAIL PROTECTED]> > >>>> An: "Tapestry users" <users@tapestry.apache.org> > >>>> Betreff: AW: @Cached and caching in general > >>>> @Chached is only used during a single page rendering cycle. It would > >> not > >>>> apply to your situation. (as far as I know) > >>>> > >>>> Source: > >>>> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >>>> > >>>> Your scenario would be implementable using your own component. > >>>> The component would represent a fragment and read the file (even > >>>> use a inmemory cache strategy (soft/weakreferences)) and write > >>>> the ouput directly to stream (or actually the dom tree of your > >>>> document being returned). > >>>> > >>>> Using your own solution enables you to mimic the behavior you talk > >> about. > >>>> Another idea would to write / cache only datas needed to render the > >> tables > >>>> (e.g. cache only content not markup). Never the less I am in doupt, > >>>> if such a solution is necessary (dynamically cache results of > >>>> database queries in memory or on disk). > >>>> > >>>> So after all you might want to port your application. As always use > >>>> the simpliest solution first. So database queries without any caches. > >>>> Once you see any problems (performance is below required) just go for > >>>> optimization. Since you have a fallback solution at hand (cron-jobs + > >>>> disk fragments) you are at the safe side. But I am in doupt if you > >>>> really need the markup being cached. Caching the database results > >>>> and recreate markup sounds more reasonable. You might save you lots > >>>> of seeking time. > >>>> > >>>> But you always know: Only the code / application will tell you! > >>>> > >>>> > >>>> Cheers, > >>>> > >>>> Martin (Kersten) > >>>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: Tobias Marx [mailto:[EMAIL PROTECTED] > >>>> Gesendet: Dienstag, 18. März 2008 17:45 > >>>> An: Tapestry users > >>>> Betreff: @Cached and caching in general > >>>> > >>>> I have not used T5 yet, but would @Cached use the file system for > >> caching > >>>> HTML fragments similiar to caching mechanisms in some php frameworks? > >>>> > >>>> Or is this a pure memory-based cache? > >>>> > >>>> I am thinking about migrating an old PHP application to T5 - it has > >> really > >>>> a lot of traffic and any users are logged in at the same time. > >>>> > >>>> It is quite a low-level application that is still quite fast due to > >> cron > >>>> jobs in the background that generate HTML fragments that are included > >> to > >>>> reduce the database-query bottleneck (e.g. grouping/ordering and > >> sorting of > >>>> huge tables). > >>>> > >>>> Somehow I don't trust Hibernate for high-performance database queries > >> on > >>>> huge tables .... as I think if tables are huge and many people access > >> it, it > >>>> will always lead to problems...no matter how good the queries are and > >> how > >>>> well you have splitted the data across several tables. > >>>> > >>>> So I think the best solution is always to generate HTML fragments in > >> the > >>>> background that take a long time and simple "include" them....this is > >> even > >>>> quicker then parsing templates when the data is cached. So you save the > >> time > >>>> necessary for querying the database plus the time necessary for > >> processing > >>>> the templates that are involved. > >>>> > >>>> Currently the setup on this application uses one-way database > >> replication > >>>> and the cron jobs access the the huge data table on the replicated > >> database > >>>> and generate those HTML fragments without disturbing the > >> web-applications > >>>> performance. So the main application simply includes those HTML > >> fragments > >>>> within milliseconds. > >>>> > >>>> But maybe the T5 caching mechanism would make all of those low-level > >>>> tricks redundant? > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >>> > >> --------------------------------------------------------------------- > >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
