> > Hi Terro, > > On Dec 3, 2005, at 7:37 AM, Tero Vaananen wrote: > > > Can Cocoon handle most of the publishing work? > > Yes. > > > Are there mechanisms to > > trigger a group of page updates based on the changes in the > XML? What > > needs to be added if there is no support out of the box? > > One way or another... can you describe this "XML message queue"? Is > that something you have now, or is it part of the architecture you > conceive of to implement with whatever publishing technology you > choose? > > In the Cocoon world, I would think the most natural approach might be > to think not of a triggered "push" update, but rather to let Cocoon > pull from the XML source and cache the result. In general there must > be some way to tell Cocoon to invalidate its cache. But this > would my > first instinct, though it's hard to tell w/o knowing more about what > you need to do. While it's certainly possible to use Cocoon to > generate static HTML pages, it's really oriented more toward building > everything dynamically but caching heavily, and that naturally leads > you to more of a "pull" model.
Publishing the lot is not the way you want to go indeed. So, what you need is 1) caching 2) a triggering mechanism telling cocoon that certain pages should be invalidated. It is common for cocoon users not do re-generate pages on invalidation, but just wait for the request. When a request comes in, cocoon "knows" the request uses xml parts that are invalidated, so cocoon generates the page again, after which it is cached again. Look at the Event Cache Block and the JMS Block (the messages for invalidation) at http://jsn-server5.com/cocoon/samples/blocks/ AS > > best regards, > —ml— > > --------------------------------------------------------------------- > 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]
