On 4/4/07, Grzegorz Kossakowski <gkossakowski@apache.org> wrote:
Alexander Klimetschek napisał(a):
> Grzegorz Kossakowski schrieb:
>
> We do need the circular dependency: the basic principle is a super
> block that runs cforms that are mainly defined in a child block - the
> model lies in the child block and it contains a selection-list whose
> source is block:child:/some/matcher - hence the circle, because the
> selection-list will be resolved inside the super block.

Let me tell you how i *imagine* servlet-service-fw should deal super
calls and tell me how it's different from current situation. This should
help us both.
Let's have two blocks, one named "base" and one "extending", base is
super block for extending. I've imagined (before using super calls) that
it would work that way:
extending block is requested for "someResource" and suppose it has not
any matching pattern for it, then super (base in our case) block is
automatically asked for the same. You don't have to provide any generic
matcher that redirects processing to super block.
Now someResource is catched by base block but it asks for
"internalResource" by calling "servlet:internalResource". Given that
base block is called as super of extending, first extending block is
asked for this resource (because it may override it) and if it does not
provide one, it's taken from base block.

In short: I mean that super should work as fallback mechanism. I guess

The idea directly applies to OO's inheritance definition. However,
it might not be easy to implement because it is hard to define "the looked-up resource does not exist in the extending servlet." Take flowscript as example, it is usually a javascript error when calling a method of a non-existent javascript object which exists in the super servlet but matched in the extending servlet's sitemap.
 

it does not work that way now. However, this would eliminate need for
circular dependencies and give cleaner design.

What do you think?

--
Grzegorz Kossakowski