> From: Michael Hartle [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > >The problem is that the sitemap exposes everything underneath to the > >end user. It would be much better if the sitemap markup EITHER > >supported the resource/view paradigm OR purely the pipeline > paradigm. > >The resource would specify the pipeline fragment that starts the > >pipeline. The view would specify the fragment that ends the > pipeline. > > > Hm, currently, we are processing the pipeline and caching its output, > but whenever there is a request, we at least have to verify in the > pipeline whether the cached output can be used or not. When > there is a > seperation into resources and views as described here, we > would be able > to (pre)generate content independently from requests based on the > underlying data (sources, etc) and its own updating cycles > (publishing > every x hours, by database-triggered notification, etc) and > deliver it > via views to the requestor and their request cycles (500 times per > hour), thous better decoupling both.
It satisfies 99% of all requirements. > I guess we might also get the same effect with a pure > pipeline paradigm, > Stefanos overloading/pipeline fragments and some sort of > Notifier that > can be set per pipeline fragment that triggers pregeneration for the > cache (on database updates, etc). IIRC, some time ago someone > (Berin ?) > spoke about the Monitor components in Excalibour and about > how it could > be used in conjunction with Sources and the expensive > getLastModified()-calls; that decoupling went in the same > direction, but > this seperation between resources and views makes it easier to see. The abstraction that lets the user get the most done is the correct one. What I outlined has nothing to do with the underlying architecture, but how it is *presented* to the end user. The pure pipeline approach is less intuitive for users exposed to web architectures. They are used to the resource concept. By mixing/matching the pipeline pattern and the resource/view concepts we are adding conceptual mud. Stick with one way of doing things and do it well. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
