You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mark Lundquist <ml...@wrinkledog.com> on 2007/01/02 20:32:11 UTC
Re: What is the deal with "blocks"
On Dec 28, 2006, at 3:08 PM, Daniel Fagerstrom wrote:
> As you can see there was a quite gradual divergence from the original
> concept to what we have today. IMO it would be preferable to just use
> the word "block" in one of the two uses of the the word.
+100. Please, please, yes.
I really think that "block" should be reserved for the new "Block"
things!
> As we have used the term block for the container aspect for so long we
> probably have keep that (although "plugin" probably would be easier to
> understand for outsiders).
To me, the term "plugin" has a distinct connotation: that of something
conforming to some "plugin API" published by the hosting framework,
like in Eclipse or Maven. In Cocoon, with the 2.1-style "blocks" there
is (as Reinhard said) no contract in view at all, and in the new Blocks
when we speak of the block "contract" we mean the block-specific
contract that expresses the service(s) provided by the block, right?
IIUC, the "interface" that makes a Block function like a plugin is not
an API at all, rather it's the structure+content "conventions" (e.g.
COB-INF, etc.) that you spoke of... is that correct? In that case, I
don't see "plugin" as a natural term to apply to either the old-skool
"blocks" or the c2.2 "Blocks". I think "plugin" has the potential to
engender more confusion than it alleviates... :-/
IMHO, going forward the things like CForms, Ajax, Batik etc. should no
longer be called "blocks" at all... rather they should be called
"optional modules", because that's all they are. They are Maven
"modules", and they are "optional" because you have the choice whether
or not to name them in your POM (in 2.1, blocks were "optional" because
you had the choice whether or not to build them, but... that was then,
this is now! :-). Even though these were called "blocks" before, I
don't think that should stand in the way of this nomenclature shift.
If all of a sudden we start talking about the "CForms module" instead
of the "CForms block", that's not going to cause anybody's brain to
melt. It's pretty obvious what is going on and people will pick up the
change readily. Right now we have core/ and blocks/; I would propose
renaming the "blocks" directory to "optional", changing the
nomenclature in the docs, and the text of the "Block Samples" section
of the samples page rewritten (that's horribly out of date and was in
need of a rewrite even in 2.1!)
Don't you love nomenclature changes? [1]
Cheers,
—ml—
[1] — http://en.wikipedia.org/wiki/Knights_who_say_Ni
Re: What is the deal with "blocks"
Posted by Mark Lundquist <ml...@comcast.net>.
On Jan 2, 2007, at 11:32 AM, Mark Lundquist wrote:
> IMHO, going forward the things like CForms, Ajax, Batik etc. should no
> longer be called "blocks" at all... rather they should be called
> "optional modules", because that's all they are.
OTOH, I should think that it would be perfectly OK if some "optional
modules" happened to include real Block(s). My proposed nomenclature
change isn't meant to imply some mutually exclusive thing, nor should
the structure of our sources or artifacts.
For instance, maybe Portal, Lucene, and/or Captcha are things that
would work well as Blocks. I don't really know enough yet to say for
sure. Other things like CForms don't really provide "services", they
are more like infrastructure things.
cheers,
—ml—
Re: What is the deal with "blocks"
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 2, 2007, at 3:07 PM, Reinhard Poetz wrote:
>>> Don't you love nomenclature changes? [1]
>> Actually, no ;)
>
> neither do I
hey, I was kidding about the "love it" part :-)
—ml—
Re: What is the deal with "blocks"
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
>> Don't you love nomenclature changes? [1]
>
> Actually, no ;)
neither do I
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: What is the deal with "pipelines" :-) (was Re: What is the deal with "blocks")
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 10, 2007, at 7:35 PM, Vadim Gritsenko wrote:
> You might find this useful.
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101053457412921
Yes I do :-). I haven't had a chance to go through it to any depth,
but IMHO this is about the level of formalism that we need from the
user documentation standpoint. Just to have a consistent, well-defined
and documented nomenclature would be great.
—ml—
Re: What is the deal with "pipelines" :-) (was Re: What is the deal
with "blocks")
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Mark Lundquist wrote:
>
> On Jan 3, 2007, at 9:29 AM, Alexander Klimetschek wrote:
>
>> BTW: In sitemaps you have multiple usage of the term "pipeline": there
>> is the element <pipeline> which typically contains multiple matcher
>> with their own pipeline - so you have pipelines there. And inside of
>> act statements you have "internal" pipelines where at the same time
>> you can declare a <pipeline> as internal-only="true"... All a bit
>> confusing to me ;-)
>
> Yes... informally we use the term "pipeline" all the time to mean
> "matcher or selector", which is different from the formal meaning of the
> sitemap <pipeline> (which is more like a network of pipes than a single
> pipe). I've never been able come up with a satisfying unambiguous
> nomenclature.
You might find this useful.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101053457412921
Vadim
What is the deal with "pipelines" :-) (was Re: What is the deal with "blocks")
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 3, 2007, at 9:29 AM, Alexander Klimetschek wrote:
> BTW: In sitemaps you have multiple usage of the term "pipeline": there
> is the element <pipeline> which typically contains multiple matcher
> with their own pipeline - so you have pipelines there. And inside of
> act statements you have "internal" pipelines where at the same time
> you can declare a <pipeline> as internal-only="true"... All a bit
> confusing to me ;-)
Yes... informally we use the term "pipeline" all the time to mean
"matcher or selector", which is different from the formal meaning of
the sitemap <pipeline> (which is more like a network of pipes than a
single pipe). I've never been able come up with a satisfying
unambiguous nomenclature.
I think at one point I was also considering trying to introduce the
term "subpipeline" in some documentation that I haven't yet got around
to writing. I think I probably would have used that to to mean any
sequence of components, where "pipeline" would have continued to mean a
full pipeline that originates with generation and terminates with
serialization.
If my proposed new matching language for the sitemap catches on, then
there will be no more <select>, so we could just start using the term
"matchers" for some of the things we today refer to colloquially as
"pipelines".
The language "internal pipeline" for <act> is probably a poor choice of
wording, "subpipeline" is probably better. BTW these are no different
than the subpipelines (to use my new term) inside a nested matcher or
selector (or resource).
stuff to think about... :-)
—ml—
Re: What is the deal with "blocks"
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Daniel Fagerstrom schrieb:
> Another advantage of dropping the prefix "block" from the "polymorphic servlet
> service" stuff is that I get the impression that many people believe that
> anything that is prefixed with block is incredibly complicated. While the
> current stuff actually isn't.
>
> WDYT?
Sounds good.
servlet-services, ServiceServlet, ServiceServletContext,
"servlet:"-protocol and all the setting simplifications you proposed are
good. I found the difference between "blocks" as cocoon modules and
blocks as BlockServlets confusing, too.
BTW: In sitemaps you have multiple usage of the term "pipeline": there
is the element <pipeline> which typically contains multiple matcher with
their own pipeline - so you have pipelines there. And inside of act
statements you have "internal" pipelines where at the same time you can
declare a <pipeline> as internal-only="true"... All a bit confusing to
me ;-)
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: What is the deal with "blocks"
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 3, 2007, at 7:16 AM, Daniel Fagerstrom wrote:
> Mark Lundquist skrev:
>> 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"?
> To generic in my taste.
I kinda felt that too :-) I actually almost suggested
"servlet-services" but I thought maybe that sounded too unwieldy.
> I think that "servlet:" protocol would describe pretty well what it
> all is about. Also it is implemented using the named dispatcher
> mechanism in the ServletContext, so it really is named servlets that
> the protocol dispatches to.
Then "servlet:" makes perfect sense. I like the transparency.
>> E.g.,
>> • services-fw
> I would prefer servlet-services-fw or just servlet-services.
yeah, bag the "-fw" :-)
>> • ServiceServlet (or "CocoonServiceServlet"?)
> ServletService would be OK.
That class does implement Servlet (extends HttpServlet IIRC) so maybe
"ServiceServlet" emphasizes the right "is-a" relationship there?
>> • ServiceContext (or "CocoonServiceContext"?)
> ServiceServletContext maybe.
yup
> Also we could add some Spring bean factory and XML-schema based
> configuration, that put the focus on the embedded servlet instead of
> the "blocks fw" so [...] we could have something like:
> <bean id="org.apache.cocoon.blocks.sample.block1"
> class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mountPath="/cocoon-blocks-fw-sample1"
>
> contextPath="blockcontext:/cocoon-blocks-fw-sample/test1">
> <servlet:context-param name="foo" value="bar"/>
> <servlet:connection name="test2"
> value-ref="org.apache.cocoon.blocks.sample.block2"/>
> </servlet:context>
> </bean>
>
> The point here is that the sitemap servlet is considered as an
> ordinary bean and the elements in the servlet name space sets up a
> bean factory that embeds the sitemap servlet in a block servlet and
> make sure that the somewhat special life cycle of servlets is
> respected. Using a servlet in the Spring framework would be as easy
> as:
> <bean id="myservlet" class="com.mycompany.MyServlet">
> <servlet:context mountPath="/my">
> </bean>
>
> And would be usable outside Cocoon.
Very nice.
cheers,
—ml—
Re: What is the deal with "blocks"
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
I have started to implement what we discussed bellow.
I started by applying all outstanding patches that I found and then took
a copy of the blocks-fw stuff.
The blocks-fw-impl module will not be removed until the new stuff
stabilizes. I don't recommend anyone to start update yet as there are a
number of refactorings and changes I'd like to do first.
/Daniel
Daniel Fagerstrom skrev:
> Mark Lundquist skrev:
>> 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
> I would prefer servlet-services-fw or just servlet-services.
>> • ServiceServlet (or "CocoonServiceServlet"?)
> ServletService would be OK.
>> • ServiceContext (or "CocoonServiceContext"?)
> ServiceServletContext maybe.
>> • "service:" protocol
> To generic in my taste. I think that "servlet:" protocol would describe
> pretty well what it all is about. Also it is implemented using the named
> dispatcher mechanism in the ServletContext, so it really is named
> servlets that the protocol dispatches to.
>
> Also we could add some Spring bean factory and XML-schema based
> configuration, that put the focus on the embedded servlet instead of the
> "blocks fw" so instead of:
>
> <bean id="org.apache.cocoon.blocks.sample.block1" class="org.apache.cocoon.blocks.BlockServlet">
> <property name="mountPath" value="/cocoon-blocks-fw-sample1"/>
> <property name="servletClass" value="org.apache.cocoon.sitemap.SitemapServlet"/>
> <property name="blockContextURL" value="blockcontext:/cocoon-blocks-fw-sample/test1"/>
> <property name="properties">
> <map>
> <entry key="foo" value="bar"/>
> </map>
> </property>
> <property name="connections">
> <map>
> <entry key="test2" value-ref="org.apache.cocoon.blocks.sample.block2"/>
> </map>
> </property>
> </bean>
>
>
> we could have something like:
>
> <bean id="org.apache.cocoon.blocks.sample.block1" class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mountPath="/cocoon-blocks-fw-sample1"
> contextPath="blockcontext:/cocoon-blocks-fw-sample/test1">
> <servlet:context-param name="foo" value="bar"/>
> <servlet:connection name="test2" value-ref="org.apache.cocoon.blocks.sample.block2"/>
> </servlet:context>
> </bean>
>
> The point here is that the sitemap servlet is considered as an ordinary
> bean and the elements in the servlet name space sets up a bean factory
> that embeds the sitemap servlet in a block servlet and make sure that
> the somewhat special life cycle of servlets is respected. Using a
> servlet in the Spring framework would be as easy as:
>
> <bean id="myservlet" class="com.mycompany.MyServlet">
> <servlet:context mountPath="/my">
> </bean>
>
> And would be usable outside Cocoon.
>
> Another advantage of dropping the prefix "block" from the "polymorphic
> servlet service" stuff is that I get the impression that many people
> believe that anything that is prefixed with block is incredibly
> complicated. While the current stuff actually isn't.
>
> WDYT?
>
> /Daniel
>
Re: What is the deal with "blocks"
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>> we could have something like:
>>
>> <bean id="org.apache.cocoon.blocks.sample.block1"
>> class="org.apache.cocoon.sitemap.SitemapServlet">
>> <servlet:context mountPath="/cocoon-blocks-fw-sample1"
>>
>> contextPath="blockcontext:/cocoon-blocks-fw-sample/test1">
>> <servlet:context-param name="foo" value="bar"/>
>> <servlet:connection name="test2"
>> value-ref="org.apache.cocoon.blocks.sample.block2"/>
>> </servlet:context> </bean>
>
> Does the property placeholder configurer still work for constructs
> like this? I guess yes, because it operates on the bean methods and
> the elements in the servlet namespace are only "syntactical sugar",
> right?
Yes, AFAICS. The custom xml handling basically transforms a bean
definition. And the property place holder will act on the resulting bean
definition. So as long as the resulting bean definition contain
reasonable properties, it should work. We need to think about it during
the design of the formats so that the property path corresponds to the
XML format in some way that seem natural for the user.
/Daniel
Re: What is the deal with "blocks"
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> we could have something like:
>
> <bean id="org.apache.cocoon.blocks.sample.block1" class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mountPath="/cocoon-blocks-fw-sample1"
> contextPath="blockcontext:/cocoon-blocks-fw-sample/test1">
> <servlet:context-param name="foo" value="bar"/>
> <servlet:connection name="test2" value-ref="org.apache.cocoon.blocks.sample.block2"/>
> </servlet:context>
> </bean>
Does the property placeholder configurer still work for constructs like this? I
guess yes, because it operates on the bean methods and the elements in the
servlet namespace are only "syntactical sugar", right?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: What is the deal with "blocks"
Posted by Mark Lundquist <ml...@comcast.net>.
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—
Re: What is the deal with "blocks"
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Mark Lundquist skrev:
>
>
> On Dec 28, 2006, at 3:08 PM, Daniel Fagerstrom wrote:
>
> As you can see there was a quite gradual divergence from the
> original concept to what we have today. IMO it would be preferable
> to just use the word "block" in one of the two uses of the the word.
>
>
> +100. Please, please, yes.
>
> I really think that "block" should be reserved for the new "Block" things!
-100 ;)
Seriously, we have used the term block for the container aspect for like
5 years, and it is used in that sense everywhere in the documentation,
code and in the mailing list. People would be seriously confused if we
tried to change that now.
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.
So if someone have suggestions for a better terminology for the
"polymorphic servlet services" I at least would be prepared to go for it.
> As we have used the term block for the container aspect for so long
> we probably have keep that (although "plugin" probably would be
> easier to understand for outsiders).
>
>
> To me, the term "plugin" has a distinct connotation: that of something
> conforming to some "plugin API" published by the hosting framework, like
> in Eclipse or Maven. In Cocoon, with the 2.1-style "blocks" there is (as
> Reinhard said) no contract in view at all, and in the new Blocks when we
> speak of the block "contract" we mean the block-specific contract that
> expresses the service(s) provided by the block, right? IIUC, the
> "interface" that makes a Block function like a plugin is not an API at
> all, rather it's the structure+content "conventions" (e.g. COB-INF,
> etc.) that you spoke of... is that correct? In that case, I don't see
> "plugin" as a natural term to apply to either the old-skool "blocks" or
> the c2.2 "Blocks". I think "plugin" has the potential to engender more
> confusion than it alleviates... :-/
Already 2.1 blocks provides services, classes and resources. Eclipse
plugins also provide services, classes and resources. It is not that
different.
> IMHO, going forward the things like CForms, Ajax, Batik etc. should no
> longer be called "blocks" at all... rather they should be called
> "optional modules", because that's all they are. They are Maven
> "modules", and they are "optional" because you have the choice whether
> or not to name them in your POM (in 2.1, blocks were "optional" because
> you had the choice whether or not to /build/ them, but... that was then,
> this is now! :-). Even though these were called "blocks" before, I don't
> think that should stand in the way of this nomenclature shift. If all of
> a sudden we start talking about the "CForms module" instead of the
> "CForms block", that's not going to cause anybody's brain to melt. It's
> pretty obvious what is going on and people will pick up the change
> readily. Right now we have core/ and blocks/; I would propose renaming
> the "blocks" directory to "optional", changing the nomenclature in the
> docs, and the text of the "Block Samples" section of the samples page
> rewritten (that's horribly out of date and was in need of a rewrite even
> in 2.1!)
>
Maven modules OTH just provide classes and resources, no services.
> Don't you love nomenclature changes? [1]
Actually, no ;)
/Daniel