cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: esql diff of the moment
Date Sun, 17 Sep 2000 10:36:35 GMT
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 :-)

My "vision" is that all TagLibs should be able to "play" together.

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 :).

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.

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).

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.

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?


regards Jeremy




-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
    <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>

Mime
View raw message