I mean exactly that, I'm comfortable with my html code, css and js I can inline what I need, I'm not proposing this as a general approach, but I like doing just that: take part of rendered content and do something with it.
if something is a compoenent framework, a component should be independant, even after the html code is rendered. Davor Hrg On Wed, Mar 19, 2008 at 10:45 AM, Martin Kersten <[EMAIL PROTECTED]> wrote: > > ...this king of component is useful for capturing output so it can be sent > > via email for example. > > This does not sound like a good idea. Do you mean requesting a page and cut > it out or grabbing part of the DOM during same request. Just wondering... . > > -----Ursprüngliche Nachricht----- > Von: Davor Hrg [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 19. März 2008 10:42 > An: Tapestry users > Betreff: Re: AW: @Cached and caching in general > > > > I agree that this is not something to take on lightly, and data should be > cached, and rendering left as is. > but besides caching this king of component is useful for capturing output so > it can be sent via email for example. > > I like to keep most things stateless (only dependant on parameters), so from > time to time I can use some of these nasty tricks. > > Davor Hrg > > On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > > :) > > > > True. I definitely won't say that this will solve all cases 100%. > > But for basic rendering.. this allows you to essentially set > > "expires" for fragments of the page. And yes it caches all > > operations that go through PageRenderSupport. And if I could take > > over the markupWriter properly, I would have cached and replayed > > those already.. but i couldn't easily do that.. But on second > > thought, you're right, maybe I should have cached a DOM tree.. since > > it would have a much better guarantees for replaying. > > > > But on most cases, this component works pretty darn good, and we love it. > > > > Of course trying to do evict cache on particular events is hard.. but > > if you are alright with "updates within 30hr" sort of cases. this is > > a good start. > > > > > > > > > > > > Howard Lewis Ship wrote: > > > I'm generally against these approached. > > > > > > Cache the data, make it fast to access. > > > > > > Let Tapestry do a full render every time. > > > > > > You'll end up with confusing, unforseen consequences. > > > > > > Rendering is increasingly a complex dance between components. > > That's > the power and the penalty of Tapestry. Components inside > > that cached > zone are not just rendering a character stream, they > > are generating > JavaScript, assigning unique ids (via > > PageRenderSupport) interacting > with an enclosing Form components, > > and doing other user-specific > things. > > > > > > I would always look elsewhere first for places that need > > optimization, > and I'd start with database access and queries. > > > > > > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> > wrote: > > >> We have a component that we call "Buffer" :) it takes a timeout, > > >> optional cachekey, and optional lastmodified (to tell you) >> >> > > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > > >> liberate it.. you would just have to change the cache hooks to use > > >> whatever cache you want to use... > > >> > > >> The easiest way to add caching to the app. :) >> >> >> >> > > Martin Kersten wrote: > > >> > @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]
