On Mon, 16 Jul 2001, Berin Loritsch wrote:
> On the developer's list, I have been proposing ways of limiting the sitemap's
> involvement in the overall method of creating your web resources. The reason
> is that the Sitemap MERGES certain concerns that hinder each site developer's
> role from functioning the way it is envisioned.
As a tool to map URIs to resources, it's great. This is an area which I'd
like to seperate out of an application, here SoC really makes sense.
Because I could come up with a different interface instead of URIs, which
would bring Cocoon2 much closer to a general app server and reduce the
drawbacks that come from the Sitemap being a proprietary concept. If I
could just plug-in my own "access interface", it would be great.
> Those who create complex sites tend to favor my
> approach, and those who create simple sites like the sitemap the way it is.
> That last statement is a broad generalization, and I have only had feedback
> from a few folks.
Count me in as an advocate for the Sitemap being a reference
implementation of a general access interface and thus an optional
component of Cocoon2. Much like XSP in Cocoon1 - you don't have to use it,
if you don't like it, and it has a clean XML interface and one
reference implementation (in Java) is provided. This has, after all, lead
to another implementation in Perl.
With "you don't have to use the Sitemap" I mean that it should be possible
to use a different implementation. A very simplistic example would be the
FileProducer from Cocoon1.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
