> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cziegeler@sundn.de>:
>
> > > Giacomo Pati wrote:
> > >
> > > On Mon, 2 Jul 2001, DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) wrote:
> > >
> > > > Hi,
> > > > I need to understand the capabilities and limitations of
> > > sitemap/subsitemap.
> > > > Is there any documentation describing the sitemap/subsitemap design,
> > > > assumptions and  usage? If it does not exist - is it possible to ask
> > the
> > > > person who designed that behavior to put together the doc
> > > similar to "docs:
> > > > draft on matchers and selectors" just to have all the ideas,
> > > capabilities
> > > > and limitations in one place? ( I know that I can figure out it from
> > the
> > > > code - but it is time consuming and not always clearly showing all
> > > > capabilities and limitations).
> > > >
> > > > The second question is:
> > > > we have Generators which - generate
> > > > 	  Transformers which - transform
> > > >         Matchers 	which - match
> > > > 	  Selectors which - select
> > > > 	  Actions which - act
> > > > 	  ??      which - aggregate
> > > >
> > > > It is a pattern that the components used in the system are
> > > "declared" in the
> > > > sitemap before they are used as a part of pipeline definition.
> > > > Why the aggregation is not following the pattern?
> > >
> > > Yes, it is true for components but aggregation is not componentized.
> > > You will have noticed that there isn't a Mounter as well :)
> > >
> > Not to forget the hard coded ErrorGenerator...
>
> Are you trying to give a hint to us ;) (componentizing error-handlers?)
> Isn't a standard DTD/Schema enought for errors?
>
Ok ok, you got me ... ;-(

It was just a try.

But to raise this discussion again.... ;-)
I think it's not the DTD/Schema which is enough, but the own partial
pipeline where I can use any sitemap components I like. So using
for example transformers or actions inside the error handler
allows me to do the same I could with my own custom ErrorGenerator.
But I still think an own ErrorGenerator is the easier approach.

PS: Perhaps we should continue this discussion when we start talking
    about Cocoon 3!


Carsten


> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org