I'll jump in...
I have the shared frustration that it is really hard to get others who are
skilled in regular web development to jump in and help out when it comes to
XMLUI. I'm not supporting the overthrow of DRI, atleast not until an
improved way of doing things is available. So, if we can improve the themes
to make XMLUI development better, then lets work on themes.
(In-line editing)...
On Tue, Oct 12, 2010 at 11:50 AM, Walker, David <dwal...@calstate.edu>wrote:
> This is a very reasonable proposal, Tim.
>
> I feel compelled to put my development time where my mouth is -- and at
> least get something started. Although we need a cooler name than QuickStart
> theme. ;-)
>
To me, DRI kind of sounds like DRY, (Don't Repeat Yourself), in my
experience with structural.xsl, it feels like anything that could be
compacted into a single function has been done. So, for starters, I would
almost want a "Please Repeat Yourself" theme I'll call it PRY / prybar.
> But if the long-term outcome here is just an alternate Theme (albeit one
> that is fundamentally different from all the others), then I think we've
> just created more (and duplicate) work for everyone.
>
Well, I'm thinking we could have community maintained themes that can live
and grow outside of the central repository. May the best way of working with
xmlui win for each IR.
Think: not DRI+structural is wrong, but DRI+prybar works better for me.
The core-themes in XMLUI haven't had much if any attention recently:
1 -- They don't contain "bugs" or "lack features", atleast not much that has
made it into our bugtracker JIRA.
2 -- They're viewed as part of a local IR's customizations. (atleast in my
opinion).
That doesn't mean that an effort to improve them can't take place.
Down the road, to specify theme compatibility, one could say that you can
version the themes.
So, in the case of the hypothetical prybar theme.
-- Prybar-0.1 (released today) to Prybar-1.0 (released at end of the year)
will be compatible with dspace-xmlui-1.6 to dspace-xmlui-1.7 (which have no
DRI modifications).
-- dspace-xmlui-1.8 which could change the DRI it creates, or was refactored
to simply pass data to the presentation layer, then the maintainer of prybar
would need to update their theme to take advantage of these changes and
release prybar-2.0
This won't be maintained by the "DSpace developers", but by the theme
developer. Good themes that are created can get mentioned in the XMLUI
customization section of the documentation.
To support more experimentation with DSpace XMLUI themes, I suggest that we
consider doing distributed development (Git) for this. I sent out a proposal
on dspace-tech last week, and so far I have the
dspace-xmlui-webapp/src/main/webapp/ code up on Github. In there you can
find a clone of xmlui/webapp tag of
1.6.2<http://github.com/DSpace/xmlui-webapp>.
I have put my university's modifications
(OSUlibraries<http://github.com/osulibraries/xmlui-webapp>)
in, and SUNScholar <http://github.com/SUNScholar/xmlui-webapp> has put their
code up there as well.
P.S. The network graph looks kind of cool:
http://github.com/DSpace/xmlui-webapp/network
Other people can do the same (Individuals or Organizations / Institutions).
Fork the tag, add their code, and let others know what they can find from
their theme customizations.
My University's theme-directory has a book-reader theme, someone who wants
that can clone it, make some bug fixes to their own checkout, and I can see
what they've changed. Anyone who makes a "QuickStart" / "prybar" /
"one-file-per-page" theme could do the same, and let others know that now
that they've broken up their theme, its easier to modify and maintain.
So, good luck, this is just a suggestion. But I think this is also easier
than managing svn commit rights.
--
Peter Dietz
Systems Developer/Engineer
Ohio State University Libraries
>
> --Dave
>
> ==================
> David Walker
> Library Web Services Manager
> California State University
> http://xerxes.calstate.edu
> ________________________________________
> From: Tim Donohue [tdono...@duraspace.org]
> Sent: Tuesday, October 12, 2010 7:52 AM
> To: dspace-tech@lists.sourceforge.net
> Subject: Re: [Dspace-tech] manikin question
>
> Hi all,
>
> Very interesting discussion.
>
> I think there really are two layers of discussion going on here, one is
> much easier to tackle now, and one is something that may need ongoing
> discussion/analysis.
>
> -------------------------
> "Theme" Layer Discussions
> -------------------------
> This is basically the complaint that dri2xhtml/structural.xsl is both:
> (a) too confusing/complex, and (b) just does a very basic transformation
> of DRI elements directly into its XHTML counterparts.
>
> This is something that could be resolved immediately with no changes to
> the DRI schema, and likely little-to-no changes to Java Aspects.
>
> All we need is someone to volunteer to create a new theme (codename:
> "QuickStart" theme, or similar). This new "QuickStart" theme needs to
> *NOT* utilize dri2xhtml/structural.xsl. Instead, it will re-write it's
> own XSLT into an easier to manage theme, which could include separate
> templates per page (or XSLTs per page) -- based on what the theme
> designer(s) decides upon.
>
> I believe that building this basic theme would not go against the
> purposes of Manakin, and it may help in adoption (and also allow users
> to get up to speed more quickly). Notice, I'm not suggesting to remove
> or replace DRI2XHTML -- rather, we want an alternative "QuickStart"
> Theme, that people can build off of instead of DRI2XHTML. Themes which
> already use DRI2XHTML would be unaffected, and can continue to use that
> as the basis for their theme, if they choose to.
>
> --------------------------------
> "DRI" / Aspect Layer Discussions
> --------------------------------
> This is essentially David's (and others) point that perhaps DRI needs
> some redesign or re-thinking. This obviously is a larger issue, as
> reworking (or getting rid of) DRI would require major overhaul of all of
> Manakin. So, I'd deem this a longer term discussion -- still worthwhile
> to be having, but it needs more analysis.
>
> I also think that if we chose to build an "Easy-Start" theme, the
> creation of that simple theme may help us learn more about what may be
> limiting to the DRI that is created by aspects, and maybe even what
> parts of DRI schema could be done away with (maybe it could be vastly
> simplified).
>
> We could also work to apply small fixes to improve specific Aspects
> which may be "more limiting to Themes" than others. But, any larger
> scale changes would need more analysis and possibly a team of volunteer
> working on it.
>
> I'm not saying this to discourage discussion of DRI/Aspect changes.
> Rather, I just want to point out that we may be able to split this into
> two problems -- one of which we could tackle immediately, if we can find
> a volunteer or two!
>
> Just my quick thoughts,
>
> - Tim
>
>
> On 10/12/2010 8:45 AM, Walker, David wrote:
> >> the Aspect chain accumulates a big pot of potentially useful
> >> data related to the user's request, and the Theme selects
> >> and arranges them as required to make them presentable.
> >
> >> we need some way to represent logical structure of the data
> >> before they are selected and laid out.
> >
> > I think we fully agree, Mark, that conceptually this is how Manakin
> *should* work. And yet, I don't believe this is how Manakin actually does
> work.
> >
> > Themes don't select, arrange, or layout the data on the page. Rather,
> dri2xhtml/structural.xsl simply iterates over the DRI XML, converting
> individual DRI elements into its individual HTML counterpart.
> >
> > The actual order of the data, and thus the essential arrangement and
> layout of the page, is controlled by the Aspects, not the Theme. Just a
> quick glance at the<body> section of any DRI XML response shows quite
> plainly that the structure of the page is set-out here in the XML, not in
> the XSLT.
> >
> > The exception to that rule is the collections/community/item metadata.
> If all of Manakin was set-up like those templates are set-up, Manakin would
> be much, much easier to use.
> >
> >
> >> That's what I thought DRI was designed to be. If it isn't
> >> being used that way, I think we should fix *that*.
> >
> > To fix the problem -- i.e., to allow Themes to actually select, arrange,
> and layout the data on the page -- I see no other course of action but to
> rewrite the XSLT.
> >
> > To be able to control the layout, you've got to actually allow the XSLT
> to lay it out. Create page-based templates wherein someone can put down the
> HTML for the page, and thus decide the order and arrangement of the data.
> >
> > The thing is, once you do that, you'll quickly see that virtually all of
> the DRI can be ignored -- in fact it *has* to be ignored to allow the XSLT
> to decide the arrangement of the data.
> >
> > At that point, we no longer need an XML schema that defines layers,
> paragraphs, headings, unordered lists, and so on -- or, rather,
> pseudo-layers, pseudo-paragraphs, pseudo-headings, etc.
> >
> > We just need, as you said previously, a way to have structured, labeled
> data. We can do that very easily without the overhead, complexity, and
> ultimately the confusion that DRI brings with it.
> >
> > --Dave
> >
> > ==================
> > David Walker
> > Library Web Services Manager
> > California State University
> > http://xerxes.calstate.edu
> > ________________________________________
> > From: Mark H. Wood [mw...@iupui.edu]
> > Sent: Monday, October 11, 2010 8:15 AM
> > To: dspace-tech@lists.sourceforge.net
> > Subject: Re: [Dspace-tech] manikin question
> >
> > On Fri, Oct 08, 2010 at 11:04:51AM -0700, Walker, David wrote:
> > [quoting Mark Diggory, I believe]
> >>> So, to be clear, the ability to construct nested divisions,
> >>> lists, options, meta sections is quite powerful for getting
> >>> the structure of the content pushed into the presentation layer.
> >>
> >> I appreciate your opinion here, Mark. And, yet, I think this
> illustrates precisely why DRI is problematic.
> >>
> >> How the content is structured on the page *is* presentation.
> Conceptually, you cannot "push" that to the "presentation layer." Any code
> (regardless of where it lives) that defines the structure of the page *is*
> the presentation layer (or at least part of it).
> >
> > Data structure != page structure. We need to keep the namespaces in
> > mind. A dri:div is not the same kind of thing as an xhtml:div. One
> > *can* use them in such a way that you eventually transform one into
> > the other, but then again one might have some completely different use
> > for a container of unordered data, just as one might use a dri:list to
> > express something which would never be noticed as an ordered
> > collection in the XHTML -- it might disappear completely. For that
> > matter, it might be consumed by a subsequent Aspect and never reach
> > the Theme engine. Data are structured to make them readily
> > comprehensible by later stages. A Theme isn't required to treat that
> > structure as prescriptive of the structure of its output.
> >
> > Come to think of it, an Aspect *can't* reliably coerce the final page
> > structure, at least not in some ways you might want to try. An Aspect
> > has no way of knowing its position in the chain, or what other Aspects
> > are included before it, so it can't slot its work into the "right
> > place on the page"; if it has something to add, it may as well stick
> > it on the end and assume that some Theme will put it where that Theme
> > wants it. The DRI document *has to* be an abstract representation of
> > the content, because only the last stage in the pipeline has the
> > certainty required to produce a concrete one.
> >
> > It took me a while to work out what the parts were doing,
> > conceptually, but what finally made sense to me was that the Aspect
> > chain accumulates a big pot of potentially useful data related to the
> > user's request, and the Theme selects and arranges them as required to
> > make them presentable. At least, that's the way I've tried to use the
> > pipeline, and it seems to work.
> >
> > Regardless of how the physical structuring of the final page is done,
> > we need some way to represent logical structure of the data before
> > they are selected and laid out. That's what I thought DRI was
> > designed to be. If it isn't being used that way, I think we should
> > fix *that*.
> >
> > --
> > Mark H. Wood, Lead System Programmer mw...@iupui.edu
> > Balance your desire for bells and whistles with the reality that only a
> > little more than 2 percent of world population has broadband.
> > -- Ledford and Tyler, _Google Analytics 2.0_
> >
> ------------------------------------------------------------------------------
> > Beautiful is writing same markup. Internet Explorer 9 supports
> > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3.
> > Spend less time writing and rewriting code and more time creating great
> > experiences on the web. Be a part of the beta today.
> > http://p.sf.net/sfu/beautyoftheweb
> > _______________________________________________
> > DSpace-tech mailing list
> > DSpace-tech@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
