Help for Dryad theme development (DryadLab)

[Jim Allman]

Hi all,

I'm working on a custom theme for DryadLab and its module pages (see attached screenshots). I'm working with the recommended Dryad VM[1] on my local machine and keeping the work in a fork on GitHub[2]. So far, so good, but I'm running into some blockers and would appreciate any advice. 

I’m struggling to find the right place to make edits in DSpace templates. For instance, the “item display” page for the Extinction module [3] is composed of the old DryadLab header, plus a modified/simplified item listing, and I can’t find the source of the latter. 

I’m aware of the URL-munging trick to see a page as XML[4], so I’m backtracking from there. But progress is slow and frustrating, so I wonder if there’s someone who can give some guidance on the best way to sort out these issues. Short of spiking every similar piece of markup with a visible change, is there some way to "trace" the rendering of a page to see which templates contributed, and where?

Also, the VM’s test database has a few collections, but no actual data packages. It seems all the search indexes (indices?) are also missing or empty. Not surprisingly, this makes testing the package-display page kind of tough. Ryan mentioned that there is a process for submitting test files to the VM and “approving" them for publication, but I'm not clear on how to do this.

Again, any advice would be greatly appreciated!

  =jimA=

Jim Allman
Interrobang Digital Media

[1]    https://github.com/datadryad/vagrant-dryad/

[2]    https://github.com/jimallman/dryad-repo/commits/dryad-master

[3]    http://datadryad.org/handle/10255/dryad.40384
[4]    http://datadryad.org/handle/10255/dryad.40384?XML

[Nathan Day]

Hi Jim,

I found debugging the stylesheets to be a challenge sometimes in the Mirage theme, although I have never worked with the DryadLab theme, so I am not sure whether the challenges are the same. Here are a few things I would suggest:

If you are using an XSLT processor with the XML file, use the XSL stylesheet deployed to /opt/dryad/webapps/xmlui/themes/DryadLab/ in the Vagrant VM, rather than the one in ~/dryad-repo/…/themes/DryadLab/. The deployment process may pull in files from outside a theme (at least, it does for Mirage).

I am not aware of any technique for displaying debug/trace information for Xalan or libxslt that would give you access to the name/matcher of the template called in the stylesheet. If you have a text editor with regex find/replace, you could do a quick pass over a stylesheet to update any <xsl:template> with a debug line like so, replacing

<xsl:template match="a">

with

<xsl:template match="a"><xsl:comment>xsl:template match="a"</xsl:comment>

find: (<(xsl:template[^>]+)>)

replace: \1<xsl:comment>\2</xsl:comment>

If you are using Saxon for XSLT, I believe there is a -T flag that outputs trace info. I have a license for Oxygen, which allowed me to take advantage of a single-stepping debugger that was useful for determining which <xsl:template> had been called during a transform, where breakpoints could be set in either the XML file or the XSL file.

I am not entirely sure about this, but you may be able to use the REST API (http://wiki.datadryad.org/Dryad_REST_API_Technology) to quickly populate your local DB with test content. I am aware of there being a few SQL scripts among the application test files that could be used to add test data to your DB, but I’m not sure any of it would be sufficient to represent fully curated and published data. In any case, your Solr cores would need to be reindexed for certain parts of the site to be aware of new data (http://wiki.datadryad.org/Search_System_Technology#Maintenance).

HTH,

Nathan

--
You received this message because you are subscribed to the Google Groups "dryad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dryad-dev+...@googlegroups.com.
To post to this group, send email to drya...@googlegroups.com.
Visit this group at http://groups.google.com/group/dryad-dev.
For more options, visit https://groups.google.com/d/optout.

[Jim Allman]

Thanks, Nathan! I'm trying some of your XSL tracing tips, but it's still slow going here.

I had hoped to use XSL:MESSAGE elements[1] to trace which templates are used, but I can't figure out where their output should appear. They're not showing up in any log files I can find.

  =jimA=

[1]    http://www.ibm.com/developerworks/library/x-debugxs/

[Nathan Day]

I am not sure how to configure Xalan/Cocoon to send xsl:message output to the log4j logs, if you are attempting to debug in the application. The xsl:comment approach I suggested should allow you use the HTML output from the application to provide something of a trace, although a fairly scattered one.

Based on the configuration of the xslt transformer in the xmlui sitemap [1], transformations are handled by a TraxTransformer object [2]. That class does have options for enabling and configuring a logger, so I assume it is possible to do so from the sitemap, but having debugged otherwise myself I am not sure of that.

If you are running the stylesheets at the command line (e.g., with xsltproc), the xsl:message output should go to stdout.

Nathan

[1] https://github.com/rnathanday/dryad-repo/blob/dryad-master/dspace/modules/xmlui/src/main/webapp/sitemap.xmap#L66

[2] https://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/TraxTransformer.html