On 4/4/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> 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
