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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
