Hi,
As the main protagonist of the WebMVC project, I should probably step in
and say something. It's good to see that there are others who wish to
develop a UI using the Spring MVC framework, however, there are a few
comments I would like to make about this proposal.
If you look at the project organisation of WebMVC, you'll see that it was
always conceived to keep the 'M' and the 'C' separate from the 'V'. Whilst
I chose to use Freemarker for the 'V', I always intended that the 'M' & 'C'
present a common, consistent layer on which different flavours of 'V' could
be implemented. I'm not claiming that it perfectly achieves those aims
right now, and there may well be some refactoring required, but the basic
intention is there.
I would be very cautious of another full MVC implementation that did not
take into account that the 'V' could be entirely replaced with something
else, keeping the 'M' and the 'C'.
Whilst I share some of your concerns over Cocoon, I personally think the
poor state of support, and relatively low level of adoption throughout the
Java community is a much bigger cause for concern. The resource
requirements are excessive, but it's the health of Cocoon itself which
really pushes me to think there should be a compelling alternative
available for the community.
Our existing JSP interface is not a good example of separation, but that
doesn't mean JSP as technology does not support MVC. Our existing
implementation is a very light, non-framework based and poorly followed
through MVC architecture. You can use JSP as the view in an MVC
architecture, but what you can't do is prevent people from abusing the
architecture by throwing Java into the JSP.
I've not heard of Twig before, but it seems with good reason - it is a PHP
templating language. Looking around, I can't find a Java implementation of
it, so I'm struggling to see what it is you are proposing here. Is there a
library that I'm not familiar with? Or are you writing an implementation of
Twig in Java?
Either way, I would very, very strongly caution against using an
unfamiliar, unproven templating language - regardless of what cool features
it may have. That way just leads back into the same problems that we are
seeing with the Cocoon framework.
I chose to use Freemarker specifically because it is very widely used (*),
and actively supported. It's quite simple to use (very similar to
Velocity), and whilst essentially enforcing that you can't simply dump code
into the templates, it's quite extensible in the way that you can use it
(for example, being able to use JSP tag libraries if you really need to).
(* A few of the Java based CMS apps use it, as does Vivo, and some major
frameworks like Hibernate).
With regards inheritance, no you can't inherit a template file in the way
that Twig allows. But I'm not convinced how useful that is, and you quickly
get into much more complicated templates, rather than the simple HTML + CSS
that you are envisioning.
As it stands, I've put a lot of work into the theming support with the
Freemarker UI, and whilst you can't inherit a template, you can inherit a
theme (so you could have a base theme for your overall repository, with
derived themes for each of your collection, for example). Also, the themes
allow you to overwrite any of the base templates. So, your ability to
inherit / customize the output depends on how you structure the templates -
break them down to enough granularity, and you can effectively get the same
inheritance effect.
One other thing the Freemarker implementation has going for it, there is a
lot of support for I18n - you can have replaceable messages within the
templates, or you can completely overwrite a template for a given locale /
language (potentially very useful in some cases).
Regards,
G
On 20 July 2012 04:12, DSpace @ Lyncode <[email protected]> wrote:
> Hi all,
>
> some of the current lyncode developments for DSpace, in fact, begin by
> some specific requirements of the SpringUI, that is, an under development
> UI for DSpace. As we are willing to develop a robust, wide accepted UI and
> giving it to the DSpace community as a code contribution, we would like to
> have, firstly, some feedback from the DSpace devel team.
>
> Let me invite you to read the following draft:
> https://wiki.duraspace.org/display/~lyncode/SpringUI
>
> As you could see at the end of the referred page, our contact with the
> DSpace community in this specific will start by *"**1. Compile an about
> page with all necessary info"*. So, is there anything left to say?
>
> We would be pleased, based on your expertise, to listen to your
> advices/doubts.
>
> --
>
> Thanks, DSpace @ Lyncode
> DSpace Department
> *Lyncode*: Official website <http://www.lyncode.com/>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
