cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist <mlundqui...@comcast.net>
Subject Re: What is the deal with "blocks"
Date Tue, 02 Jan 2007 23:16:48 GMT

On Jan 2, 2007, at 2:36 PM, Daniel Fagerstrom wrote:

> Finding some term that doesn't contain the word block for "polymorphic 
> servlet services", would be much less of a problem as it is different 
> from the original block concept and not that many people have used the 
> blocks-fw yet.Fair enough :-)

> So if someone have suggestions for a better terminology for the 
> "polymorphic servlet services" I at least would be prepared to go for 
> it.

How about just "services"?  E.g.,

	• services-fw
	• ServiceServlet		(or "CocoonServiceServlet"?)
	• ServiceContext		(or "CocoonServiceContext"?)
	• "service:" protocol

Seems like a reasonable shorthand for "polymorphic servlet services".  
I'll admit that "ServiceServlet" is a little unwieldy, but I could live 
with it.

>> [snipped... "plugins"?]
> Already 2.1 blocks provides services, classes and resources. Eclipse 
> plugins also provide services, classes and resources. It is not that 
> different.

Right, not all that different.  To me, "plugin" still implies "plugin 
API", but I wouldn't start a fight over it.  Anyway since we agree that 
the "polymorphic servlet services" is the thing that's to be renamed, 
"plugin" might not be a good choice for that, since as you say 2.1 
blocks already provide the things that to you (and presumably to 
others) comprise a "plugin".

> Maven modules OTH just provide classes and resources, no services.

Yes — maven modules provide classes and resources for the system being 
built.  Maven plugins (mojos), OTOH, do provide a primitive kind of 
"service" to maven itself.

BTW, thx for the great summary of the history/progression of the blocks 
framework development — that was really helpful.

cheers,
—ml—

Mime
View raw message