cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Interpreted Sitemap?
Date Wed, 30 Jan 2002 16:21:07 GMT
Berin Loritsch wrote:

> Sylvain Wallez wrote:
>
>> At the first request, you may see an error message complaining about 
>> undefined "xmldb" or "parentcm" generators. You'll then have to 
>> comment out these pipelines in sitemap.xmap, since the interpreted 
>> sitemap is more strict than the compiled engine.
>>
>> Please report any problem you may have with this new engine.
>
> Once the bugs have been shaken out of the new system, I would like to
> see the interpreted Sitemap be the default Sitemap.  Do you have any
> input on how resiliant it is to bad sitemap syntax?  For instance,
> if you had one pipeline entry that was not correct (but valid XML),
> is that particular pipeline entry disabled and all others still used? 

The pipeline is not disabled, but the whole sitemap doesn't load : it's 
a "fail fast" approach where checks are made as soon as possible.

There are several levels of checks :
- syntax : invalid XML element are reported because the engine doesn't 
know what to do with them (there is no corresponding "node" declaration 
in the config).
- coherence : for example, references for undeclared components produce 
errors.

For the "xmldb" and "parentcm" mentioned above, the syntax is correct, 
but their use in pipelines raise an error since the corresponding 
generators aren't declared in the <map:components> section if the 
necessary .jars aren't in the classpath at build time.

With the compiled engine, the corresponding error is only raised when 
there's a try to use these undefined generators. This results in some 
"sleeping" failures that are just waiting a user to stimulate them, but 
nobody knows when...

> That IMNSHO is reason enough to switch.  With the compiled approach,
> if the Sitemap.xmap syntax is not done in a valid manner, the compiler
> does not produce valid code, and the prospect is an all or nothing deal.

The problem also with the compiled engine is that the sitemap is the 
first element that handles a request in Cocoon. If sitemap compilation 
fails, it's often difficult to know why and it's *really* frustrating 
for beginners.

The interpreted engine is in a sense also all or nothing since it breaks 
on the first error encountered. But the round-trip time is so fast that 
correcting one error at a time and reloading for further checks 
shouldn't be a problem. Also, the interpreted engine gives the file 
name, line and column number of the offending statement !

I still have some pending work to speed up the reload time by making the 
tree builder recyclable (for now a new one is created each time)... and 
still docs to write ;)

As for the last issue with view and aggregation, could some view-guru 
explain exactly how are to be handled the different parts of an 
aggregate with the different cases (no label, label on map:part and/or 
map:generate).

Thanks,
Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message