cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [design] Cocoon Blocks 1.1
Date Sun, 03 Nov 2002 22:50:09 GMT
Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>
>> The contract of a block should be services identified by their URI, 
>> and not files at well-known locations (even if these 'files' are in 
>> fact produced by a pipeline).
>>
>> <snip/>
>>
>> By considering blocks as pipeline services, we really achieve true
>> polymorphism for blocks, because we totally abstract the way their
>> contracts are implemented.
>>
>> [note that all the above isn't in fact block-specific and can be made
>> today inside a single sitemap]
>>
> Gotcha!
>
> What can I say: I agree!


Cool ;-)

>> After this we had a long conversation about the semantics to be used 
>> to identify which part of a pipeline we want the caller to use, which
>> unfortunately fell flat because I wasn't able to make you understand 
>> my thoughts. I'd like someday to have the luck Carsten had recently 
>> to meet you for real. Too bad the GetTogether is the same week as the 
>> ApacheCon :-(
>
>
> Yeah :/ well, you know, you were next on my list anyway :)


Super-cool ;-))

> Ah, BTW, I'm going to be travelling a lot in the next month or so, 
> I'll post a schedule so that if anybody is around and want to have a 
> beer and talk geek, I'm game.


Ok, just tell us the "Stefano tour" locations ;-)

>> Anyway, let's forget for now these syntactic problems. The important
>> thing above is that a block should provide services by means of 
>> pipeline URIs and not resources.
>
>
> Good, I like it. Care to edit the version 1.2 of that document to show 
> us what you mean also syntactically? I think that would help a lot.


I won't be able to do it soon as I'm damn late for things I have to 
prepare for the 3 coming weeks : Cocoon training next week, "Forum XML" 
exhibition in Paris the week after (BTW, any people going there ?), and 
GetTogether presentation still after. This leads to 20 november :-/

>> > The best solution is to allow my block to explicitly "extend" that
>> > block and inherits the resources that it doesn't contain.
>>
>> Side note : we must not forget to allow a block to call
>> services/resources of its parent block (like a "super" call in Java).
>
>
> How do you envision this to happen? Can you come up with a real need 
> for such a thing? Just checking you are designing by parallel here. In 
> fact, I added inheritance after I noticed that one of my customers I 
> did consulting for had a problem that could be solved wonderfully with 
> block inheritance (mostly, it was block personalization for different 
> customers).


This came after thinking that a block could "extend" its parent services 
or even resources by wrapping them. Imagine for example a skin block 
that formats documents like its parent, but adds a legal notice at the 
bottom of each page. There are certainly lots of good use cases for this.

> Also, how do you make this happening? something like
>
>  <map:call resource="block:parent://whatever/service"/>
>
> would that be enough? could that be harmful or provide security concerns?


Well, I'm too tired at present for further thinking. Let's add it to the 
todo list !

<snip what="discussion on version management"/>

>> Ok. I hope this time this notion of "pipeline services" will go 
>> further and that we will solve the misunderstanding we had 4 months 
>> ago...
>
>
> Yeah, I think it will. Last time you threw in the syntactic concern 
> hoping that others understood the semantic concern underneath it, but 
> this time is definately clearer :)


Hey, I just copy/pasted my 4 months old post :-)

But you're right : last time, my explanation failed because we each 
understood something different through a syntactic construct. I'll try 
differently this time... when I'll be able to find the time...

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message