cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zisch (Matthias Meier), NetHorizon AG" <>
Subject Re: Cocoon 2 suggestions
Date Tue, 11 Apr 2000 15:40:31 GMT
Hi all,

>Mike Engelhart wrote:
>> OK - although I haven't looked at the C2 CVS closely, here are 2 things that
>> I think need to be addressed in Cocoon 2.
>> 1)  XSP error handling.
>>     XSP needs to be able to be able to handle unexpected errors by returning
>> either a dynamic error page or rerouting to another predefined xml page that
>> is maybe set in or somewhere in the xsp taglib itself.
>> It's very painful while testing to see errors on populateDocument() being
>> spit out without being handled.   Obviously my web site will not have any
>> errors EVER but for those poor souls that have bugs in their code, I think
>> this would be very useful :-)
>totally +1

Me too! Rerouting to an arbitrary page would be cool. This could probably even 
be an XSP-page. (But it should be possible to fall back automatically to a -- 
probably dynamically generated --  "default-page" in case the error-page itself 
spits unexpected errors! Otherwise you could easily end up in an infinite loop.)

BTW: The rerouting seems -- for rerouting to documents served by the same Cocoon 
instance -- just a special case of the internal-subrequests-theme to me! (Or is 
it just, that I see everything as a subrequest, now I'm working on that?)

>> 2)  Internationaliztion
>>     I've ranted about this several times on this list but haven't gotten any
>> response so I'll rant again....Internationalization using ResourceBundle's
>> with Cocoon/XSLT sucks!  With XSP, you can't access ResourceBundle classes
>> for some unknown reason.  I've posted this to cocoon-dev about 5 times and
>> haven't gotten any response as to why you can't access ResourceBundle
>> classes in the same classpath. Something must be going on behind the scenes
>> with ResourceBundle's and the classloader that I don't understand.  Also, I
>> don't think XSP is where the language lookup's necessarily should take place
>> (although I wouldn't mind it happening right now). Thoughts on this???
>Hmmmm, never thought about this, anyone else?

Internationalization is a critical issue to us for some years now.

My conclusion: I think, the whole ResourceBundle-business in the Java Core 
Library sucks somewhat. For example, it is assumed, that for every set of 
resources in every locale a dedicated class is created and that (therefore ;-) 
resources are always loaded by Classloader's. Further, ResourceBundle is not an 
interface, as it should be, but a class, making it difficult to provide your own 
implementations! (OK, you can work around these limitations, but since the 
limitations are built in, the workarounds always remain dirty hacks!)

My solution would be to specify an interface (!) "ResourceBundle" with the basic 
methods needed by a resource-bundle (well, probably it should have another name, 
maybe just "Resources" ;-) and another interface "ResourceBundleLoader" with 
probably just a single method like "ResourceBundle loadResources(String/URL? 
path, Locale locale)". This would give you much more freedom in the 
implementation of the actual resource-bundles and the resource-loading-process. 
For example, it would be easy to implement a ResourceBundleLoader which loads 
the resources from the class-repository, as it is done currently in 
"ResourceBundle.getBundle()". But -- for servlets ;-) -- it would also be easy 
to load resources from the document directory of the web-server etc.

I don't know, if this problem is really in the scope of Cocoon. Actually 
Javasoft should do it in the Java Core Library, but I don't know, if there are 
any plans for this.

Another point would be to replace the ugly properties-file with something 
XML-ish. As I understand, this is -- in a way -- yet done in Cocoon (-> 
XMLConfigurations), but actually I dream of an XML format (and the associated 
ResourceBundleLoader -- sic!) which would allow me, not only to specify string's 
as values, but also any other Java-Object, say, a NumberFormat or an Image 
(specified by a URL to the image-file). The format should be extensible with 
custom tags. _Really_ cool would be the possibility to reference the value of 
other resource-objects (from the same or another bundle) to build the value a 
specific resource-object.

Probably the way to get this would be to allow arbitrary Java-Expressions to be 
evaluated for a resource-value in the first place and then do something like the 
XSP-tag-libraries to implement often used expressions as custom tags.

That sounds, as if XSP (probably combined with a special resource DTD) comes 
near to what I wish from -- only the result should (once again ;-) not be 
written to a stream, but given to a caller in the form of a ResourceBundle 
object. (I will have to think about this...)


| Matthias Meier  |
| NetHorizon AG     |
|                                                  |
| City Server of Winterthur |
| Swiss Internet CD Shop |
| Web Application Framework |

View raw message