Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 50628 invoked by uid 500); 6 Nov 2001 17:08:04 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 50617 invoked from network); 6 Nov 2001 17:08:04 -0000 From: "Bernhard Huber" To: cocoon-dev@xml.apache.org Message-ID: <12aebd125825.12582512aebd@i-one.at> Date: Tue, 06 Nov 2001 17:08:04 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: de Subject: Re: Cocoon-view, Cocoon-sitemap documentation X-Accept-Language: de Content-Type: multipart/mixed; boundary="--638fc4ed6561b9" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----638fc4ed6561b9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, I don't mind having an attribute called label. The only objection I have I get confused if a map:transform element has a label attribute. A map:label element helps me more visually to see the point in the pipeline where the view takes its xml content. Having an attribute label I will be somehow unsure wheter content of the view is taken from before or after the transformation. But let's see for the different components: For generators it is absolutly clear, as there is no xml prior to a generator the label means: The content of the view is "after" the generator has been run. For transformers a label may mean before the transformation or after the transformation. I think it makes more sense to define: The content of the view is "after" the transformer has been run. As the you may use a "generator" label to get the content before the transformation step. For map:aggregate a label has the same definition as for map:transforms. Thus the definition is: The content of the view is "after" the aggregation - being the merge of all parts. For map:part of an map:aggregate the label means what? I am not sure if it makes sense to let map:part having an attribute label. I don't know. Thus for all elements so far it is always: After the map:generate, map:transform, map:aggregate has run, the content of this step is the content of the view defined by the label attribute. The element map:serialize has no label attribute. The element map:handle-errors has no label attribute, but the components inside may have label attributes. The element map:match, map:select, map:otherwise has no label attribute. So that's my suggestion regarding label attribute. Is it okay? Are there any other sitemap elements I have forgotten? bye bernhard ----- Originalnachricht ----- Von: Stefano Mazzocchi Datum: Dienstag, November 6, 2001 11:01 am Betreff: Re: Cocoon-view, Cocoon-sitemap documentation > giacomo wrote: > > > I've talked to Stefano (he is my guest for some days here) about the > > map:label stuff and we found that the approach was wrong. It > should be > > an attribute. > > Let me give you more details about why I think an element is wrong. > > A "label" indicates the exit point that is matched by the view > handler. > For example (again from the cocoon site sitemap): > > name="file" > src="org.apache.cocoon.generation.FileGenerator" > label="content" > /> > > the file generator is implicitly given the label "content". > > > > > > This "view" connects to the label "content". It means that if you ask > for the "content" view of a resource, the pipeline will stop the > regularprocessing as soon as it encounters a "content" label, > either implicit > or explicit. Then continue the processing defined in the > tag > (which normally includes some transformers and a serializer). > > > > > > > > > > > > there are cases where the "content" is generated out of aggregating > (say, on a news page) and other cases where the content is simply > one of > the aggregated parts (like in the case where you aggregate a document > with the sitebar). > > In all cases, a label (either implicitly defined in the component > declaration) must be matched to exit the regular pipeline and go > to the > "view" one that terminates the processing on that resource for that > particular view. > > So, I believe it's much easier to say understand something like > > > > > > > ... > > > than it is for > > > > > > > > > ... > > > or even worse compare this > > > > > > > > > > > > > > > with this > > > > > > > > > which provide the "exact" same information. > > Now, I don't see any drawback in this approach, but if you see any > it'sthe best time to tell since views will place an vital role in > the future > of Cocoon we must do out best effort to make it a very solid contract > with our users. > > If we choose to go the attribute way (and hopefully we do), there are > two options: > > 1) use the undefined namespace > 2) use the sitemap namespace > > so, either > > > > or > > > > but since we never used the sitemap namespace for attributes, I'd > suggest 1) > > What do you think? > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > Friedrich Nietzsche > ------------------------------------------------------------------- > - > > > > ------------------------------------------------------------------- > -- > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org > For additional commands, email: cocoon-dev-help@xml.apache.org > > ----638fc4ed6561b9 Content-Type: text/x-vcard; name="bh22351.vcf"; charset=us-ascii Content-Disposition: attachment; filename="bh22351.vcf Content-Description: Card for Content-Transfer-Encoding: 7bit begin:vcard n:Huber;Bernhard fn:Bernhard Huber version:2.1 email;internet:bh22351@i-one.at end:vcard ----638fc4ed6561b9 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org ----638fc4ed6561b9--