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
sands@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 [tdonohue@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.xsl file)

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 [tdonohue@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?

Manakin works 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
Manakin URL, 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