On Tue, 2007-12-18 at 15:18 -0600, Dorothea Salo wrote: > If this is completely unworkable, feel free to scoff at me, but...
Not at all! > Is there *any* way that Manakin can be nudged to give more information > about XSLT problems in a theme? What information are you lacking? > As it is, when I break something > non-obviously (that is, not a gross XML well-formedness error), all I > can do is guess wildly what I just broke. Given that every Manakin > tweak means a Subversion commit, checkout, rebuild... this is > uncommonly tiresome and time-consuming when things break often. (And I > break stuff a lot.) Are you editing Java code or just a theme with sitemaps and xslt? If the latter, and you have a local installation, can I suggest you just hack your theme on the live Manakin instance? It's a lot quicker and more convenient. When you have something working you can copy it to your development workspace and Do The Right Thing. > Surely SAX knows where it is when a stylesheet blows up? Can it be > persuaded to disgorge that information? Yes it does; when something in the pipeline throws an exception Cocoon should catch the exception and dump the Java stack to your browser with a message. I just tried it here and I got: An error has occured javax.xml.transform.TransformerException: Could not find variable with the name of metadata context:/file:/opt/apache/apache-tomcat-5.5.17/webapps/manakin/themes/embeddable/dri-to-xhtml.xsl - 86:8 ... and a stacktrace. Is that the kind of thing you get? BTW the resulting stack dump looks worse than it really is. The reason is that the SAX pipeline is essentially a giant stack of Java method calls (i.e. the pipeline generator calls the transformer, which calls the serializer). Any XSL transforms in your theme are (depending on the XSLT interpreter used) either interpreted by a Java XSLT interpreter or are themselves compiled to Java byte code. In either case, some of your XSLT code will be represented in that stack trace, so it can be worth a look. Again, depending on your XSLT interpreter, error in your XSLT will end up as Java errors, so an unitialised <xsl:variable> can become a java.lang.NullPointerException for instance. -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
