cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Sitemap inheritance
Date Sun, 26 Oct 2003 11:58:03 GMT

On Sunday, Oct 26, 2003, at 11:16 Europe/Rome, Gianugo Rabellino wrote:

> Stefano Mazzocchi wrote:
>> On Saturday, Oct 25, 2003, at 18:01 Europe/Rome, Gianugo Rabellino 
>> wrote:
>>> Is that OK to everyone?
>> No. I still have to understand what's wrong with the sitemap 
>> inheritance that blocks introduce.
>
> Probably I should be more aware of what kind of inheritance exactly 
> block introduce in your design.

I might be wrong, but I think that the current block inheritance 
mechanism does exactly what you were describing in your previous emails.

> So far I haven't been able to find anything explicitly oriented to 
> pipeline reuse/inheritance: it's pretty clear that components 
> (classes) will be inherited, and the same goes for resources, but what 
> about pipelines?

I'm not sure we are using the same terminology here. but let me give 
you an example of how the blocks will work:

  block a

   ...
   <pipeline>
    <match pattern="*.html">
     ... do something ...
    </match>
   </pipeline>
   ...

  block b

   ...
   <pipeline>
    <match pattern="ciao.html">
     ... do something different ...
    </match>
   </pipeline>
   ...

cases:

  1) block a is mounted on /
     asking for "/ciao.html" will give you the "do something" pipeline
     asking for "/whatever.html" will give you the same pipeline

  2) block b is mounted on /
     asking for "/ciao.html" will give you the "do something different" 
pipeline
     asking for "/whatever.html" will give you 404

  3) block b extends block a and is mounted on /
     asking for "/ciao.html" will give you the "do something different" 
pipeline
     asking for "/whatever.html" will give you the "do something" 
pipeline

> I'm not *that* sure that it makes actually sense to inherit them by 
> default.

It's not by default, it's up to you to choose if your block inherits or 
not (as above)

> But then again, I don't think that blocks will be enough, if blocks 
> are to be the only way to have inheritance. The final user won't 
> package every single application as a block, and even inside the sime 
> application she/he might find himself with more than one sitemap, not 
> being able to reuse preexisting logic.
>
> To me, having inheritance only in blocks look a bit like saying that 
> you can extend only from java.*, while user classes have to be always 
> final. It's rough and inaccurate, but can you see my point?

hmmm, not really. blocks are application level components that isolate 
your logic. this is exactly what you are going to need. it would be 
like saying that object orientation is overkill for datatypes and 
nothing is wrong with C unions.

I do agree that it looks like overkill to come up with a block for your 
own stuff that you need to inherit, but i think that this will force 
you to define contracts betweeen stuff and this will help you later on 
(just like OOP datatypes vs. unions)

but, supposing for a second we allow sitemap inheritance without 
blocks, how would you make it work for both?

--
Stefano.


Mime
View raw message