cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [RT] A Unified Environment Model?
Date Thu, 03 Mar 2005 20:27:45 GMT
Carsten Ziegeler wrote:

>Ralph Goers wrote:
>>Carsten Ziegeler wrote:
>>OK.  I'm not sure I'd try to solve the problem that way though.  I'd 
>>probably just use the existing object model.  Since its a Map I can put 
>>anything I want into it.  To get at things I'd just put objects in the 
>>map to get them like:
>>objectModel.put("systemproperties", System.getProperties());
>Sure, and this will of course still be possible. But where do you do
>this put operation? 

Actually, in the implementation that followed, you wouldn't.  The caller 
would do:


Mind you, this example is pretty stupid since one could just do 
System.getProperties(), but I think it illustrated the point.

>Imagine you want to access these systemproperties in
> your template, in order to access them in your template someone has to
>put them there beforehand. 
No. I code {SystemProperties}.  To make things standardized the class 
could just be expected to implement a static method named 
getInstance().  Then that method gets called to locate it.

>If you do this by hand, *you* have to take
>care about this and either do this in flow or somewhere else.
>So the basic idea is to provide an automatic way for such things - you
>once configure that you might want to use the "systemproperties" stored
>in the object model somewhere - and as soon as you access them, they're
>I see real use cases for the authentication-fw and the portal. For
>example the portal "enhances" the object model with a portal object, so
>you can do something like objectModel.get("portal").getPortalUser() in
>Java or ${cocoon.portal.user} in your template.
I'd prefer PortalUser.getInstance() in Java or {PortalUser} in a 

>Obviously not everyone needs this portal axis in the object model and
>this portal object is not available with every request - just every
>request targetted at the portal.
>Of course, if you're using plain java there are other ways of getting
>this information. But we want to have a unified way, so the same "paths"
>work in Java, in flow and in your template.

View raw message