Hi Mark! (copy to the Development community)
I strongly agree with your message. I have been suggesting this
(improved JSTL/EL/JSP) long time ago. But many began to run after Manakin...
I think we will need to choose between JSP and Cocoon: we will never
succeed to support the two at same time on the long term: there will be
always one lagging and inconsistent.
One interesting thing about XML/UI: it has defined what information is
needed where. It should be now much easier to define JSTL which make
these information available and EL functions to access it.
Personnaly, I prefer JSTL/EL/JSP solution to Cocoon. But what is(will
be) the choice of the community? I think we may soon have enough
experience to choose.This choice will be needed if a needs analysis
finaly bring conclusions and when big application level developments
start up.
Have a nice week-end!
Christophe
Diggory Mark a écrit :
On Sep 26, 2008, at 1:11 PM, Mark H. Wood wrote:
On Thu, Sep 25, 2008 at 08:43:45PM -0700, Diggory Mark wrote:
Maybe an example of how to do it using MessageFormat and JSTL would
help get the point across...
Take...
Messages.properties:
jsp.home.search2 = Enter some text in the box below to search DSpace.
home.jsp
<p><label for="tquery"><fmt:message key="jsp.home.search2"/></
label></p>
---------- replace it with ---------------------------
Messages.properties:
jsp.home.search2 = Enter some text in the box below to search {0}.
home.jsp:
<p><label for="tquery">
<fmt:message key="jsp.home.search2">
<fmt:param value='<%=ConfigurationManager.getProperty("dspace.name")
%>'/>
</fmt:message>
</label></p>
I dislike turning something fairly readable:
browse.page-title = Browsing {dspace.name.short}
into something you have to find and grub through a JSP to comprehend:
browse.page-title = Browsing {0}
but if this method will satisfy everybody then I will do it.
The point is not to invent something new when the the support is there
by default. This is just JSTL, ResourceBundles and JSP. The {0}, {1},
{2} is a standard referencing behavior that has always been part of
JAVA properties based resource bundles since its inception. Its part
of most java certification exams. Its something you will always see
with java properties files and its best to stay aligned with that
given these files are being edited in tools like ResourceBuundleEditor
and will expect it as a standard syntax of localized java properties
files.
Now, If someone might invest the time to get us on JSP 2.0 rather than
this antiquated JSP 1.x version we are using, then we could upgrade
the JSLT libraries as well and use EL syntax to reference things
rather than JSP <%=%> tags. then it would look much cleaner to you.
JSP has come a long way since these JSP's were written, I can't
believe the community hasn't pushed to get this more updated, it
probably make customization of the JSPUI significantly easier and
allow the use of editors/services/tools that work better with the 2.0
syntax... I.E. Dreamweaver etc.
Finally, the dspace taglibrary is quite a horrid design, no taglibrary
should be generating html internally, they should just providing
iteration capabilities to the JSP author so that they can navigate the
datastructure an pick out the properties they want to show...
Interestingly this is exactly what JSTL/JSP 2.0 meant to alleviate, a
lot of custom JSP tag-libraries became obsolete with the creation of
JSTL. I think folks would be a lot happier if they could put what they
wanted into search/browse results and Item lists in the JSP page
directly rather than having to resort to hacking the taglibrary java
code when they want to have something else show up in a record or
row,. A perfect example of how not to write a taglibrary, rather than
separating the JSP out as where you do customization of presentation,
the taglibrary actually makes customization of the result sets and
views impossible without a Java developer. (sorry for the sharp
criticism dspace commiters).
[steps off soap box]
Cheers,
Mark
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
begin:vcard
fn:Christophe Dupriez
n:Dupriez;Christophe
org:DESTIN inc. SSEB
adr;quoted-printable:;;rue des Palais 44, bo=C3=AEte 1;Bruxelles;;B-1030;Belgique
email;internet:[EMAIL PROTECTED]
title:Informaticien
tel;work:+32/2/216.66.15
tel;fax:+32/2/242.97.25
tel;cell:+32/475.77.62.11
note;quoted-printable:D=C3=A9veloppement de Syst=C3=A8mes de Traitement de l'Information
x-mozilla-html:TRUE
url:http://www.destin.be
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
