cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Access to the object model
Date Fri, 23 May 2003 10:01:02 GMT
Sylvain Wallez wrote:
> Marc Portier wrote:
>> Sylvain Wallez wrote:
> <snip/>
>>> Hey, wait a bit ! We have to define first how the object model is to 
>>> be accessed from the context.
>>> I see two ways :
>>> 1 - the object model as a whole is accessible as a context entry :
>>>      Map objectModel = (Map)context.get(CTX_OBJECT_MODEL);
>>> 2 - each of the element of the object model can be accessed separately :
>>>      Request req = (Request)context.get(CTX_REQUEST);
>>> I don't like solution 1, as it exposes the fact that object model 
>>> elements are stored in a Map, which really is an implementation 
>>> detail (remember discussions long ago about defining an ObjectModel 
>>> class ?).
>>> So my preference goes to solution 2, which exposes directly the 
>>> elements of the object model, without caring if they are all gathered 
>>> in a Map, or independently set in the context though ThreadLocals, or 
>>> whatever implementation choice is made. Furtheremore, the Context 
>>> being already analoguous to a Map, there's no need, from the user 
>>> point of view, for an additional indirection (the map may however be 
>>> kept under the hood for the implementation).
>> with you all the way,
>> on the side, don't know for sure but maybe it makes sense to introduce 
>> at the mean time the pattern more formally so it gets used at more 
>> places in future (Map return from Actions comes to mind)
>> I've always liked the pattern of get- set- remove- Attribute and 
>> getAttributeNames on the HttpSession, HttpRequest, and ServletContext
>> (it's less hard to implement this then the full Map interface if you 
>> have something specific in mind, e.g entrySet() ) 
> Hehe, this is a thought that came recently to my fruitful mind ;-)

watch out: Bruno told me yesterday that our beloved Steven is on 
a fruit diet: he'll be brainpicking you :-)

> Considering that the various "scopes" of the servlet architecture 
> (context, session, request) all share this ability to store attributes 
> and that Cocoon has abstracted them from javax.servlet, I was thinking 
> of an "AttributeHolder" interface that would provide the methods you 
> mention, and have Context, Session and Request implement it.

yep, when I said 'formalize the pattern' I was suggesting an 
interface too, still doubthing if we would want to split it up in 
a readonly and read-write version? (a thought introduced by 
Stefano mentioning a read-only-map for flow lately)

> What can it be used for ? Well, there are a lot of places where 
> storing/getting a value is needed, but the storage scope of this value 
> is not relevant and defined elsewhere. Using this AttributeHolder method 
> could then be the needed abstraction.
>>> Of course, if the object model is extended, e.g. with flow values, 
>>> this will mean an additional entry in the context.
>> IMHO I think the main thing is stepping away from Map for these things 
>> in general, having this technique nested down on 
>> child-object-attributes seems quite innevitable? 
> Sorry, I don't get it...

Let me try again:
Your proposal (and explanatin) for '2' says two things to me
- access directly on the context
- get rid of the Map interface

Then at the end you added the flow values to the scene, which 
hooks back to the SOC-FLOW thread we had were Stefano mentioned 
the introduction of the readOnlyMap for that...

IMHO that map will be holding quite arbitrary (business) objects 
of which the child-properties are going to be expressed in a very 
attribute-like way through the use of jxpath?

So, already we end up in a position of an attribute-value-object 
that has its own attributes?  Which breaks a bit the 'direct 
access' idea?


Trying to get back into your 'direct access idea' (and I thought 
similar stuff was expressed between you and Carsten as well, no?)

we could make the statement equivalent to

Actually when I see you mention 'the storage scope of this value
is not relevant and defined elsewhere' is basically the same, no?

>>> And we will have a ContextHelper class, counter part of 
>>> ObjectModelHelper.
>> maybe overdoing it:  but, if the pattern comes up we might even push 
>> up a Dynamic Proxy AttributeHelper for the general case and for reuse 
>> in user apps
> Isn't this the AttributeHolder I mentioned above ?

well, you didn't mention it with so many words in the previous 
mail so it was hard for me to make references to it ;-)

rereading I'ld have to admit that the dynamic proxy wording is a 
bit overdone (if not wrong) what I think about is indeed having 
the interface implemented by your own class (or maybe better its 
anonymous inner classes or what)

class MyClass {
   private Type prop;
   public Type getProp();
   public void setProp(Type t);

   public AttributeHolder getAttributeHolder(){
     return new AttributeHolder() {
       public Object getAttribute(String attName) {
          // checking name, delegating to parrent getProp()

with some introspection helper class we can avoid all this inner 
classing, and provide cleaner objects, in stead of

MyClass mc =...

flowMap.setAttribute('my', mc.getAttributeHolder())

we could get

flowMap.setAttribute('my', new DynamicAttributeHolder(mc))

current feeling though is that we are very re-inventing jxpath?
someone who went deep enough in jxpath that can confirm/deny or 
point out more sensible reuse?

>>> Thoughts ?
>> yes :-)
>> hope I made them clear
> Not totally ;-)

sorry, I'm getting this strong 'everything is connected feeling'
and that is most of the time not when my thoughts are best expressed

I should revise my LSD intake to regain some balance :-)
thx for pointing this out, hoping it is better now?

> Sylvain

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message