I think Sands hits the problem on the head: The way virtually every other interface templating system works, each "page" in the system corresponds to an individual template or file.
If I want to make a change to my DSpace home page, I should be able to easily find and edit a "home page" template. If Jose wants to edit the "confirm item" page, there should be a "confirm item" template. Obviously, common elements like the header, footer, sidebar, etc., should be pushed into their own templates. But, otherwise, I should be able to see and edit "pages." That is what I think most people expect to see (I know I did). In so far as Manakin doesn't work that wat, it's confusing. I'll write some additional thoughts in a second email. --Dave ================== David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Sands Alden Fish [sa...@mit.edu] Sent: Thursday, September 30, 2010 1:42 PM To: Tim Donohue Cc: Walker, David; dspace-tech@lists.sourceforge.net; Blanco, Jose Subject: Re: [Dspace-tech] manikin question I think one of the real challenges people run into with Manakin's templating is that there is no direct corollary between specific pages and individual templates or template files. Templates apply all over the site to an array of pages. You can't say "oh, i'm in submission, i'll go edit submission.xsl." Further, you can't go looking for the template named "submission_page". On top of that, there is also a lot of calling in between templates, passing parameters, etc. But I think one of the biggest difficulties is that some of the UI construction spans across the Java Cocoon generator code into the templates that depend on their output. I'll echo David's sentiment that this is a massive improvement over the JSPUI and that we owe a lot of thanks to its architects and developers. It is a challenge though, for anyone coming into it for the first time, even with a lot of experience in more standard templating architectures, to get to a point where the UI design & modification process feels smooth, uninhibited and agile. The fact that there is an abstract document model in the middle of the processing that bears a resemblance to some of the markup it generates does not help matters for the uninitiated. As far as improvements, I could imagine some refactoring of global XSL templates into more feature-specific/page-specific templates, to ease the task of locating the point in the code that needs to be changed for a particular UI element. Early on in my use of Manakin, I started inserting xsl:comment tags at the start and end of the XSL templates so that in the generated source, I could have a better idea of which piece of code had generated that markup. This was only mildly helpful. I also tossed around the idea of putting some multi-purpose HTML <div> elements into each page so that there would be an anchor that could be used for additional page elements using CSS positioning, etc. though that always felt like a messy hack to me. -- sands fish Senior Software Engineer MIT Libraries Technology Research & Development sa...@mit.edu E25-131 On Sep 30, 2010, at 3:28 PM, Tim Donohue wrote: Hi Dave, Feedback (whether positive or critical) is always welcome! Though, obviously, it is even more helpful if we can better understand what is difficult and perhaps even how it could be improved upon or changed. Obviously, you mentioned the dri2xhtml being confusing and other systems doing things in a clearer way. I guess it leaves me wondering whether you (or anyone else) has suggested improvements which may make it less confusing/complex to deal with? For instance, would it be helpful if somehow the structural.xsl is "split up" (so it's not so large), or is it the templates themselves which are not as easy as in other systems? In general, if there are ways you or anyone else feel Manakin (or any part of DSpace for that matter) could be improved, we'd definitely be interested to hear them. Manakin, as an interface framework, really hasn't changed much since it's initial release in DSpace 1.5. Obviously, any good system/interface/etc should adapt and make improvements over time. So, I feel that all the Dspace developers would be interested to hear of suggestions for improvements or examples of easier to use interface templating systems which we could look at emulating, etc. Thanks! Feel free to send thoughts/suggestions to this mailing list. If you have specific code/template changes to suggestion you can also enter those into our issue tracker at http://jira.dspace.org/ - Tim On 9/30/2010 1:52 PM, Walker, David wrote: Unfortunately, I think this is a serious weakness of Manakin. It's realtively easy to change the header, the footer, and the display of metadata (collections, communities, items). But if you need to change anything else, you're in for a world of hurt. The way dri2xhtml renders the interface is both complex and confusing -- not at all the way other interface templating systems (including others that use XSLT) are set-up. I don't mean to be too critical here -- Manakin is a *big* improvement over JSPUI , and it cost me precisely $0, so I'm grateful to the developers, regardless. But Jose is not the first, nor likely the last, to scratch their head at how dri2xhtml is set-up. It would be great if a future version of Manakin might take a different approach. --Dave ================== David Walker Library Web Services Manager California State University http://xerxes.calstate.edu ________________________________________ From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, September 30, 2010 7:25 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class="ds-table"). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for<dri:table> contents: <xsl:template match="dri:table"> But, notice that template calls several other XSL templates in the file, by using the<xsl:apply-templates> or<xsl:call-template> tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class="ds-table". If you search for "ds-table" in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xslfile) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose ________________________________________ From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Jose, I'm not sure I fully understand the question? Manakinworks much differently than JSPUI -- so there is never really a "one template" to "one page" relationship. XSL Templates (in a theme) are usually used across many different pages in the system. Also, obviously many templates are used to generate a single page. The template you are looking for should be either in your Theme's XSL file or in the main 'dri2xhml.xsl' file (which is where most of the default templates reside -- as this file just basically transforms DRI into XHTML). If you are having trouble finding the exact template, sometimes it helps to look at the DRI structure of that page (add ?XML to the end of the ManakinURL, or&XML if there's other stuff on the querystring already). You also may find it useful to use a tool like FireBug (http://getfirebug.com/) to analyze the structure of the generated XHTML, so that you can search through the templates in your Theme's XSL to find where that structure is generated. Hopefully that's helpful. Let us know if any of this doesn't make sense. - Tim On 9/29/2010 3:48 PM, Blanco, Jose wrote: I'm trying to get a better understanding of Manakin, and I've made a change in the aspect ConfirmItemForm.java And would like now to experiment with the theme that handles the display of DRIs coming from this aspect, but I can't find the template that is responsible for displaying the page that goes with this aspect. By page I mean the main body, not the header and footer display. Thank you! Jose ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
