cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: [RT] A Unified Environment Model?
Date Thu, 03 Mar 2005 17:05:56 GMT
Carsten Ziegeler wrote:

>Ralph Goers wrote:
>  
>
>>What exactly is this interface buying us again?
>>
>>    
>>
>I think you missunderstood the idea, so I will try to explain it:
>
>Currently, the objects available in the object model are hard-coded, you
>can get a request object, a response object and some more. So something like
>
>objectModel.get(ObjectModelHelper.REQUEST_OBJECT)
>
>works.
>
>We don't want to change this! Or putting it in other words: accessing
>information contained in the object model will not change - the user
>side is not effected.
>
>So why are we doing this? Because we see the need in dynamically putting
>objects into the object model, so things like
>
>objectModel.get("systemproperties") or objectModel.get("user") will work
>. (This might be dumb examples, but I hope they get the idea across).
>
>So the question we try to answer is: how does this information get into
>the object model? And additionally we need a kind of a proxy here as
>well - some information are available beans, but it might be possible
>that other information needs some "calculation time" before it is
>available. In these cases we only want to generate it, when it is accessed.
>
>The basic idea is to have a component that delivers this information,
>when it is accessed. In our example, we register two components named
>"systemproperties" and "user" somewhere (this has to be defined) and
>when you do a get("user") on the object model the corresponding
>component fetches the user object from somewhere and returns it - this
>is totally transparent to the client site.
>
>HTH
>Carsten
>  
>
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());

I guess I can see your desire to hide the dynamic part of this, but I'm 
not sure it is worth the hassle when I can just enhance 
ObjectModelHelper to do

Object x = ObjectModelHelper.get(objectModel, "key", XFactory.getFactory());

with the get method implemented as

public Object get(Map objectModel, String key, Factory factory) {

    Object obj = objectModel.get(key);

    if (obj != null) { 
        return;
    }
    obj = factory.newInstance();
    objectModel.put(obj);
    return obj;
}

If cases exist where the factory needs parameters than have a method 
that also takes a Map and passes that to the factory. 

I would hate to see the "Object Model" have any understanding of the 
items it is storing.  Instead, if you want to hide the details of this 
stuff, do:

X x = X.get()

and have X implement

public static X get() {
    Map objectModel = (Map)ContextMap.getCurrentContext();
    return (X)objectModel.get(objectModel, "X", XFactory.getInstance());
}

To give a concrete example, if you wanted system properties you could do:

public class SystemPropertiesFactory implements Factory {
   public static SystemPropertiesFactory getInstance() {
       return new SystemPropertiesFactory();
   }
   public SystemProperties newInstance() {
       return new SystemProperties();
   }
}

public class SystemProperties extends Properties{
    public SystemProperties() {
       this.putAll(System.getProperties());
    }

    public static SystemProperties getProperties() {
        Map objectModel = (Map)ContextMap.getCurrentContext();
        return (SystemProperties)objectModel.get(objectModel, 
"systemproperties", SystemPropertiesFactory.getInstance());
    }
}
   
This is a rather silly example, but I hope it makes my point.
 


Ralph


Mime
View raw message