Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <00aa01c0218f$9960ed00$2e022397@ARES>
Reply-To: "Nicola Ken Barozzi" <nicolaken@supereva.it>
From: "Nicola Ken Barozzi" <nicolaken@supereva.it>
To: <cocoon-dev@xml.apache.org>
References: 
 <Pine.LNX.4.21.0009141648230.28391-100000@balld-0.dsl.speakeasy.net><00e601c01edb$7b9ece10$e4022397@ARES>
 <p04330107b5e8ed84a8ba@[10.0.1.123]><019501c01ff9$d12bcbc0$98022397@ARES>
 <p0433010bb5ea4794116f@[10.0.1.123]>
Subject: Re: esql diff of the moment
Date: Mon, 18 Sep 2000 18:43:38 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Jeremy Quinn" <jeremy@media.demon.co.uk>

> At 17:50 +0200 16/09/00, Nicola Ken Barozzi wrote:
> >From: "Jeremy Quinn" <jeremy@media.demon.co.uk>
> >
> >> At 07:43 +0200 15/09/00, Nicola Ken Barozzi wrote:
> >> >Why not use the fixed DTD that is used now in Cocoon2 for notifications?
> >> >It's kinda standard ;-)
> >> >And all will have to go to C2 anyway.
> >> >Maybe I'm just plain dumb, but shouldn't all taglibs throw the same error
> >> >DTD? (IMHO)
> >>
> >> +1 on that!
> >>
> >> >If you agree I will make a small taglib that can be used by other taglibs
> >> >4 this.
> >>
> >> What I need for FP is to check whether any other tags had an error, so I
> >> can decide whether to serialise the DOM they are writing or not.
> >>
> >> I am adding errors to a Hashtable to do this, though it would be great if
> >> there was a general mechanism to share errors between all TagLibs on a
> >> page. They just add errors keyed to their own namespace.
> >>
> >> Wotcha reckon?
> >
> >Hmmm, I haden't thought of intra-taglib error handling... I thought that when
> >an error occurs, it is notified to the user via standard DTD... or to the
> >sitemap
> >(C2). I cannot imagine the use, because the need hasn't touched me yet, but
> >my fifth sense and 3/4 ;-) tells me I'm missing something important...
> >Could you please elaborate more on this, I'd be grateful.
> >Thanks :-)

First of all thank you for taking time to explain. :-)
And second, remember that I'm heart and soul in C2, so all my suggestions
and ideas are with C2.
Let's get going...
 
> My "vision" is that all TagLibs should be able to "play" together.

Ok. IMHO there seems to be a problem.
As I said other times, it seems wishful thinking that taglibs should
get along in some cases only because of mutual agreements between
authors, like in the case we had with session parameters.

> At the moment we can mostly pass the output of one to the input of another,
> though it can get tricky to write the logicsheets to allow this (bejesus, I
> still don't fully understand how this works :).

IMHO, or we have a _standard_ and _safe_ way of passing data from
taglib to taglim ("interface") or none at all.
As I explained to phone to Stefano, let's say you want to draw a chart
from data gotten from sql. You have SGL tags inside CHART tags.
The most linear, logical and Cocoon-like way of doing this is by
writing a Transformer for the chart!
It also gives you the possibility to change chart parameters in the sitemap if you
wish without changing the xml. 
Charting is not data production, it's data transformation.
On the other hand, Transformers are more difficult and less speed some say...
Well for difficulty I wrote a Transformer that can simplify things, and are planning
to make taglibs suitable for transformation (don't hope too much for it guys ;-) ).
As for speed... well to pass data around you need an interface and the SAX
on is concise enough I think... are you sure it's slower? We should test IMO.
And remember: taglibs bloat method size, and for now there's still the 64K limit.

<next day I wrote>
Now I've thought of this again and changed my mind ;-)
I've started another thread for this:
Content view separation... are we making a mess? ;-)


</next day I wrote>

> The next issue that arises under this scenario it seems to me would be a
> shared error report mechanism, whereby if a TagLib writer so chose, they
> could hold off on performing an action if another TagLib had thrown an
> error.

Now, if a taglib throws an error, it means that the method in the Generator
stops and the Sitemap gets notified and acts accordingly.
Everything stops automagically.
 
> The obvious example of this working internally in FP, is that it will not
> serialise a modified DOM if there was some problem manipulating it (maybe a
> selector did not match).

IMHO this is something peculiar in fp... hmmm...

> Let's say I wanted to have a TagLib send a "change notification" email to
> editors when a page was successfully modified by FP, it would be handy if
> the sendmail Taglib could check to see if there were any errors in the FP
> namespace on a global XSP Error Table, before perfoming that action.
> 
> At the moment in FP, errors get added to an fpErrorTable object (a tarted
> up Hashtable of Vectors of fpErrors). The LogicSheet determines a unique ID
> for each parent of an FP Tag (generate-id), writes it into the parent as an
> Attribute fp-id="N2876286428", and uses the ID as the key in the
> fpErrorTable to add new errors to the table. ie. each parent becomes a new
> key, each error happening inside that parent becomes an element of the
> Vector that has that key.
> 
> At the end of processing, the whole lot is DOMed and sent to the output
> (fpErrorTable and fpError both implement XObject :), leaving the job of
> relating errors to data to the StyleSheet using the IDs.

Well these are warnings, not errors...
It means that processing can continue but it notifies the problems.
It should be up to the next component in the itemap or better to the
logic in the sitemap to decide given the warnings.

> OK, so this may not be the most elegant of solutions ..... it was designed
> for internal use ..... but something like this could be supplied
> automatically by SiLLy, no?

I cannot reply to this, I have never seen SiLLy :-)

Anyway, it seems that we failed to fully understand each other in
the first place because you see everything in XSP, I am more keen
on the full sitemap chain.

IMHO we should not try to do everything in XSP just because it's
easy, cool and fast.
Everything has its place, otherwise we would not have a pipeline
with transformers.
Speed and semplicity can come in second, otherwise all can become 
a mess.
This is not meant for you in particular, Jeremy, just a general consideration
:-)

Are there any suggestions on the warning issue?
Now SAX warnings are sent to the user as errors, why not have the sitemap
decide how to handle them... don't have a clear idea yet though...

nicola_ken