cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Object Model-related changes in Template generator
Date Sat, 14 Jul 2007 12:52:57 GMT
Grzegorz Kossakowski skrev:
> Hi,
> It's been three times that I reverted my changes introducing ObjectModel 
> interface and using it in Template generator. I must admit that I got 
> stuck in unproductive state because I'm constantly unhappy with the 
> design.

You are probably striving for perfection and think that you can achieve 
it by staying in the design phase just a little bit longer. But it 
doesn't work that way. Perfection takes for ever and we don't have that 
much time ;) Be happy with what is good enough.

Also you need to start implementing your design. Choose a design (NOW!), 
stick with it for a while and implement the important parts of it in the 
simplest possible way. By doing this you get *real* experience with the 
pros and cons of your design choices and can refactor and redesign if 
necessary until it becomes good enough. You will also get better 
feedback from the rest of us by committing code.

As a good rule of thumb: when the design phase stops to be stimulating 
and has become frustrating it is better to start to implement something ;)

Just as an example, the servlet service framework in its current shape 
is the fifth mayor reimplementation since we started to actually 
implement it. Before that the community did design for a couple of 
years, which in the end was really frustrating for everyone involved. 
Also we spent so much time implementing things that would have been 
certainly would have been nice to have but that is not part of the 
current implementation.

> Let me share my troubles in a hope that someone is much clever 
> than me and will give some advise.
> As discussed earlier[1][2], Object Model will be simple Map that can 
> contain more than item for each key and preserves order in which items 
> were added. I found (after several attempts to invent one myslef) 
> MultiMap[3] interesting and close to what I want to achieve. It resulted 
> in very simple ObjectModelImpl[4]

I'm not convinced. I would prefer to just use an implementation of the 
ordinary Map that returns *one* item for each key (respecting the stack 
order in the underlying stack based model).

While the MultiMap idea solves the problem of "../1" patterns in the 
map: EL, it complicates all the rest of the ELs. Normally, there is no 
point in being able to be able to access values for a parameter name 
that are shadowed by newer values in a stack based context. The only 
reason that this is needed in the map language is that the parameter 
naming is automatic 1,2,3,... so that values that you might need are 
shadowed automatically. It would have been better if the map language 
would have had user named parameters instead, it would have been easier 
to understand and we wouldn't have the current problem.

I would propose that we create a new interface that extends Map and 
provide a method like:

   List getStack(Object key);

or something similar. Then the map language implementation could depend 
on this interface for handling its stack access, while the rest of the 
ELs only needs to do access on a Map.

> that is only a prototype and will be 
> replaced by Spring's, scoped bean that will utilize CallStack as Daniel 
> proposed earlier.

I've changed my mind ;) I still believe that using a custom Spring scope 
that is similar to the CallStack is a good idea. But I think it might be 
overly complicated to evolve the current CallStack implementation so 
that it covers all our stack based bean access needs. I think it is 
better to have an own stack for the object model. Then we can see at a 
later stage if we can find some common abstraction. Right now I'm afraid 
that it would just complicate things.

> I wanted to use ObjectModel interface in cocoon-template-impl and 
> cocoon-expression-langauge-impl modules. After reading all the code I 
> found that current implementation is little unsatisfying. I'll explain 
> my concerns.
> Let's examine how ExpressionContext[5] class looks like and what's 
> purpose.

The design was based on Jex a 
whiteboard project in Jakarta commons. Compared to that it was 
simplified, Avalon based and adapted to Cocoon's needs. More about the 
design can be found here

> Basically, it's a holder for data passed to expression 
> evaluators. It can contain several named variables, context bean and 
> namespace table. This class is really vague for me because:
>   * it's not clear what's the difference between context bean and named 
> variables (you can put everything everywhere)
>   * namespace table is very mysterious thing when it comes to general 
> data holder and seems to be very specific
> To find out what's the purpose for variabales/context bean you must take 
> a look at all implementations of Expression interface and find that it's 
> rather JXPath-specific feature. If ExpressionContext holds something as 
> variable ("variable1") you can access that data by using 
> "$variable1/[...]" expression, if the same data is held as context bean 
> it's available by "./[...]".

It is a JXPath specific feature.

> Other expression languages implementations 
> ignore variables completely so if you happened to rely on this feature 
> you are in big trouble. How intuitive...

Might be. But it is not that easy, JXPath is supposed to be applied on a 
bean (or DOM) and optionally parameters. Jexl on a map. I felt that 
restricting to a common subset of input had been to limiting. You will 
be in big trouble if you try to access an XML DOM with Jexl, but it 
works fine with JXPath.

For our current use, my design was probably overly generic. We could 
remove the contextBean and replace it with a reserved variable name in 
the map in  the context.

> Namespace table is also very specific to JXPath (because only JXPath has 
> concept of namespace implemented) and I'll not discuss in detail how it 
> works. It only makes me wonder why it is put in rather general 
> ExpressionContext class.

No idea, I was not involved in implementing this part.

> Situation is even more worst because Template 
> generator uses this namespace table for its very internal reasons 
> (emitting right SAX events, cleaning up namespace declarations and so on).
> I'll show you, as an example, execute() method of 
> o.a.c.template.script.event.Event class:
>     public Event execute(final XMLConsumer consumer,
>                          ExpressionContext expressionContext,
>                          ExecutionContext executionContext,
>                          MacroContext macroContext, Event startEvent, 
> Event endEvent)
>         throws SAXException {
>         return getNext();
>     }
> You can see that method's signature is already quite fat - there are 
> three different contexts. What I'm going to propose is not much better 
> because I want to introduce one more argument (NamespaceTable 
> namespaces) and change existing ExpressionContext expressionContext to 
> ObjectModel objectModel. I just want to move namespace handling out of 
> general interface for data holders.
> Before calling Expression#evaluate() I would like to add namespace table 
> to Object Model with "namespace" (or similiar) key so it's available for 
> JXPath implementation.

Sounds reasonable.

> Ok, I'm not sure if such approach of slimming interface to absolute 
> minimum and putting things in a Map is right but nothing better comes to 
> my mind.
> Could you give your advice? I'm really afraid that I'd made a commit 
> only to realize that my changes are dumb and there is better design.

You are taking things to seriously. Don't worry, just commit things and 
refactor and change them later if you or anyone else get a better idea.

By not committing, you can be absolutely sure that your work will be of 
no use.


View raw message