Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42277341.5040101@dslextreme.com>
Date: Thu, 03 Mar 2005 12:27:45 -0800
From: Ralph Goers <Ralph.Goers@dslextreme.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] A Unified Environment Model?
References: <42239FC2.3020503@nada.kth.se>
 <d00cn8$ri7$1@sea.gmane.org>	 <422444FC.4040207@nada.kth.se>
	 <cc159a4a0503020707272c2b4d@mail.gmail.com>	 <4225F490.4000805@nada.kth.se>
	 <cc159a4a05030211012139ccfb@mail.gmail.com>	 <42261931.5060703@nada.kth.se>
 <cc159a4a05030212053e897fc8@mail.gmail.com> <42264C8E.9010207@nada.kth.se>
 <4226C0C3.6010501@apache.org> <42272E3E.4040308@dslextreme.com>
 <42273556.2090707@apache.org> <422743F4.6030702@dslextreme.com>
 <42274C83.7080800@apache.org>
In-Reply-To: <42274C83.7080800@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:

SytemProperties.getProperties();

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
>available.
>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 
template.  

>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.
>
>Carsten
>
>  
>