cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [Ann/RFC] Virtual Sitemap Components
Date Tue, 12 Apr 2005 14:27:38 GMT
On Apr 12, 2005 9:05 AM, Daniel Fagerstrom <> wrote:
> Peter Hunsberger wrote:
> >On Apr 12, 2005 5:50 AM, Sylvain Wallez <> wrote:
> >
> >
> >>Daniel Fagerstrom wrote:
> >>
> >>
> >>
> >>>Sylvain Wallez wrote:
> >>>
> >>>
> >
> ><big snip/>
> >
> >
> >
> >>So in the end, my opinion is that sitemap fragments for VPCs should be
> >>declared in their own section of the sitemap, just as views, resources
> >>and flows. Components for VPCs will be added to the ServiceManager by
> >>the TreeBuilder (let's recall that TreeBuilder has full control on the
> >>ServiceManager as it is the one that creates it).
> >>
> >>Rather than having TreeProcessor and ServiceManager mix their stuff in a
> >>single <map:components>, this allows the TreeProcessor to augment the
> >>ServiceManager with components that are aliased to their corresponding
> >>processing nodes. Concerns a kept separate for the sitemap writer, but
> >>remain unified as regular components from the outside world.
> >>
> >>So, WDYT?
> >>
> >>
> >
> >That makes a whole lot of sense to me.  Even if you don't need to
> >implement any new kinds of sitemap processing on VPCs having a
> >separate section for them allows you to wrap the parsing of that
> >section in a clean way. If you reuse component parsing great, the VPC
> >wrapper can just inherit or reuse the component parsing, but if at
> >some point in the future a new use case is found where simple
> >component parsing is not sufficient then you've already got the hooks
> >in place for adding something new without requiring a new version of
> >the sitemap.
> >
> >IOW, having a separate VPC section in the sitemap helps make the
> >sitemap forward compatible for any future requirements, where as using
> >naming hacks in existing sections of the sitemap may be rather fragile
> >in the long run.
> >
> >
> There is not that much code to reuse or keeping forward compatible. 

No, no, you miss my point: by using a separate section in the sitemap
you make the sitemap itself forward compatible for any future
requirements added to VPC's.

If someday you come along with a case that say, for instance requires
adding a "src" attribute to a generator, you don't suddenly have to
come up with a new way of defining generator VPC's.  You can just keep
parsing the VPC section of old sitemaps as you always have and not
worry about the fact that the way you previously distinguished a
generator VPC from a regular pipeline generator has disappeared.

> You
> can take a look yourself in
> ComponentsNodeBuilder, VPCsNodeBuilder, VPCNodeBuilder and VPCNode.
> And the sitemap engine is so flexible that it would be rather easy to
> change syntax.

Yah, but not so easy to change 10,000's of sitemaps (after all they'be
fragmented into blocks by this point) that may already be using VPC's
when you suddenly discover that naming hacks make a powerful use-case
impossible to implement cleanly.

> So I don't see this so much as an implementation question as a
> conceptual question. Are we considering the VPCs as sitemap components
> or something else, to me they look like sitemap components.

Component is a very general concept. One could consider almost
everything in the sitemap is a component. By that reasoning, why not
just have _one_ section in the sitemap named "objects" and use nested
hierarchy and id and idref to glue all the objects together?   (Heck,
why not just useRDF to build the sitemmap... ;-)

I don't see that there is any harm in separating VPC's into a new
section, but I do see a lot of possible good in the long run.

Peter Hunsberger

View raw message