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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
