Re: [Dspace-tech] Debugging XSLT in Manakin
Dorothea, Sorry for the late reply, catching up on email from the break I see you've already had your specific problem answered. But I'd like to chime in with a bit general advise. When doing development with XSL it's a pain to have it running live on the site as you pointed out. The errors are confusing and sometimes are pointing you in the wrong direction - or just don't give you any hint other than something went wrong. Typically when adding a new XSL feature I've found that it works best to download the a specific DRI page. Then in a separate IDE load the DRI page along with the XSL and debug it there in an isolated environment. We use Oxygen XML which is a low-cost, but not free, xml IDE ($48 USD for an academic license). It will allow you to step through the XSL one line at a time viewing the input, relevant XSL template, and the output all at the same time. Once we have the XSL working for one particular page then we load it back into Manakin to see if it works. If you find that it doesn't work in another case (i.e. on another page) take that DRI page and repeat the processes. I have to admit that this strategy work a whole lot better with Manakin 1.1 where METS documents were included inline. With DSpace 1.5 these documents are no longer included inside the single DRI page. Thus if the page you are dealing with requires references to METS documents you'll also need to download those documents as well and store them locally as static files. To make sure that the resolving works you'll then need to edit the original DRI page to adjust for the locally stored METS documents. Again, Hope this helps. Scott-- On Dec 18, 2007, at 3:18 PM, Dorothea Salo wrote: If this is completely unworkable, feel free to scoff at me, but... Is there *any* way that Manakin can be nudged to give more information about XSLT problems in a theme? 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.) Surely SAX knows where it is when a stylesheet blows up? Can it be persuaded to disgorge that information? Dorothea -- Dorothea Salo[EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 - 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Debugging XSLT in Manakin
If I were you I'd look for any select attributes containing curly braces. Good catch. That's what it was, though I'm still bemused as to why it would sometimes crash the system and sometimes not. And I finally got community and collection logos moved where I wanted them. Life is good! New and completely unrelated problem: The Profile page Null Pointer Exceptions on me. What chunk of the stack trace should I post -- or is this a known and/or corrected problem, given that I'm a version or so back? Dorothea -- Dorothea Salo[EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Debugging XSLT in Manakin
What information are you lacking?
Well, I've gotten the messages you mention when I forgot to rename ALL
the occurrences of a particular new variable... but this is different,
and it's kicking my rear. Sum total of error message:
javax.xml.transform.TransformerException: A location path was
expected, but the following token was encountered: {
And no information as to WHERE it was expecting a location path. I
can't find any extraneous {'s anywhere, especially in the bit where I
suspect the problem is. Googling about a bit, I suspect the answer can
be found somewhere in the stack trace, but the full stack trace isn't
returned to the Web, and the bit I need is buried too deep.
For what it's worth, what I'm trying to do is move community and
collection logos out of the body of the collection and into the h1
containing the community/collection name. It's been surprisingly
difficult to accomplish.
Dorothea
--
Dorothea Salo[EMAIL PROTECTED]
Digital Repository Librarian AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Debugging XSLT in Manakin
Shame you don't get a line number, alright.
From the message though it looks like you are accidentally using an
attribute value template (i.e. curly braces) in an attribute which
expects a location path, e.g.
xsl:variable name=foo select={$bar[baz]}/
... when you meant to type:
xsl:variable name=foo select=$bar[baz]/
If I were you I'd look for any select attributes containing curly
braces.
C
On Thu, 2007-12-20 at 08:33 -0600, Dorothea Salo wrote:
What information are you lacking?
Well, I've gotten the messages you mention when I forgot to rename ALL
the occurrences of a particular new variable... but this is different,
and it's kicking my rear. Sum total of error message:
javax.xml.transform.TransformerException: A location path was
expected, but the following token was encountered: {
And no information as to WHERE it was expecting a location path. I
can't find any extraneous {'s anywhere, especially in the bit where I
suspect the problem is. Googling about a bit, I suspect the answer can
be found somewhere in the stack trace, but the full stack trace isn't
returned to the Web, and the bit I need is buried too deep.
For what it's worth, what I'm trying to do is move community and
collection logos out of the body of the collection and into the h1
containing the community/collection name. It's been surprisingly
difficult to accomplish.
Dorothea
--
Conal Tuohy
New Zealand Electronic Text Centre
www.nzetc.org
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Debugging XSLT in Manakin
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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Debugging XSLT in Manakin
If this is completely unworkable, feel free to scoff at me, but... Is there *any* way that Manakin can be nudged to give more information about XSLT problems in a theme? 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.) Surely SAX knows where it is when a stylesheet blows up? Can it be persuaded to disgorge that information? Dorothea -- Dorothea Salo[EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 - 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
