So, wrapping up this long-winded criticism -- you did say this was okay right, 
Tim? ;-) -- I don't think it would actually take much to improve Manakin.

First, just do away with the DRI schema.  

Have the aspects Java code simply create XML that is semantically (rather than 
presentationally) marked-up.  Just give us the data for communities, 
collections, items, and the submission process.  Just the data as XML.

Second, push all of the presentational logic into the XSLT files. 

Create templates that correspond to "pages" in the system.  If the interface 
needs a <div> or a paragraph or a submit button, that should all go into the 
XSLT.  That is where it belongs, in the presentational layer.

You'll then have a clean separation of concerns, easy to figure out templates, 
and happier developers.

Easy for me to say, right? ;-)

--Dave

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: Walker, David
Sent: Thursday, September 30, 2010 2:42 PM
To: Tim Donohue
Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net
Subject: RE: [Dspace-tech] manikin question

The root of the problem, IMO, is that Manakin takes a fundamentally wrong 
approach to XSLT.

The way Manakin works now, it generates XML that is already *presentational* in 
its orientation.  The DRI schema includes elements that are, for all intents 
and purposes, layers, paragraphs, lists, and so on.

The XSLT, then, applies templates recursively to that already very HTML-like 
XML, in order to turn each element into true HTML.

This creates two fundamental issues:

(1) People don't design pages "recursively."

Applying templates recursively to XML is great (and considered best practice) 
if you are going from one XML document to another XML document -- by that I 
mean, from one metadata schema to another, like from MODS to Dublin Core.

But when you go from XML to HTML for *presentation* (which is what Manakin is 
doing), it's not the right approach.  At all.

As I mentioned earlier, the templates should more-or-less correspond to pages, 
so developers can see, position, and layout the HTML.  That is how other 
systems that use XSLT for presentation work.

(2) It mixes concerns.

The aspects Java code (e.g., CollectionViewer.java) includes code for things 
like querying the database.  But it also includes code for things like 
positioning layers, paragraphs, and buttons in the interface.  You've got 
business logic and presentational logic in one file.

But then you've also got *additional* presentational logic in the XSLT.  So 
you've got presentational logic in two different places in the system.  It just 
adds to the confusion.

--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 12:28 PM
To: Walker, David
Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

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
 templatingsystems 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.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 [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?
>>
>> 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

Reply via email to