Vadim Gritsenko wrote: > Most of the changes are done. PLEASE: test with your setup/sitemap, add > more test cases to the lint/sitemap.xmap. > > >>From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] >> >>Vadim Gritsenko wrote: >> >>>>Summary of the proposed changes: >>>> >>>>1. A pipeline may contain *all* components at the first level. >>>> >>+5 >> > > Done, as far as I can test it - working all right. > > > >>>>2. Pipelines are to be validated against following rules: >>>> (1) all pipelines must have generator or >>>> reader|mount|redirect|call. >>>> (exclusion: handle-errors already have a generator) >>>> >>+1 >> > > Done, add aggregator to the list. > > > >>>> (2) pipelines with generator|transformer must have serializer >>>> (exclusion: handle-errors always must have serializer) >>>> >>+1 >> > > Done, also add aggregator to the list. > > > >>>> (3) readers|serializers|mount|call|redirect must never have >>>> > other > >>>> sitemap components after them. >>>> >>+1 >> > > Done. > > > >>>> (4) matchers and selectors without nested direct components are >>>>illegal >>>> >>>> >>-0, this is again a restriction which I think is not necessary >> > > Commented out. > > > >>>>3. Token expansion is allowed for all attributes. >>>> >>>> >>+5 >> > > Done; yet there is an issue with the views, labels, and > map:generate|serialize|transform's type attribute. The issue is how to > determine label of the particular component if at compilation time name > of the component is not known (because of substitution).
Sorry to jump in lately (I have hard times to follow the list), but I'm not sure it desirable to allow substitution in component types and view labels. This could lead to very obscure sitemaps (refer also to "dynamic sitemap" Stefano is strongly against), and since source/parameters for sitemap statements often are component-specific, I don't see any real functional use for this. > Thinking about views, why it is necessary to declare views and > component's labels in every sub-sitemap? If first is just inconvenience, > second poses more serious treat: every sub sitemap dealing with views > must define own pool of components (read: use (sometimes: lots of) > memory), leading to scalability issues. I think there is need to come up > with the mechanism to lookup view labels on run-time. Any ideas? This could be achieved by a using a specialized ComponentSelector that holds the labels for each component. But this means the sitemap is no more self-contained (views behaviour can depend on the parent sitemap). > And I have another view-related question: what should be the correct > view behavior for the following sitemap fragment: > > <map:generators default="file"> > <map:generator type="file" src="..." label="content"/> > <map:generators> > ... > <map:generate src="data"/> > <map:transform src="data2page" label="content"/> > <map:serialize/> > > Now it seems invokes view right after generator. Jumping to a view occurs at the first statement having the label the view refers to, i.e. the generator in this case. > Would like to hear comments/opinions/etc, > > Regards, > Vadim Sylvain -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
