You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jorg Bauer <jo...@rabbit.co.uk> on 2000/06/23 13:28:45 UTC
Cocoon2 and Dynamic Site maps
I really like the concept of the site map where site managers can associate
different pipelines to requested URIs.
Will it be possible to configure the site map in a way that the pipeline
specifications are created dynamically?
I am thinking of a mechanism which would allow me to use a different
pipeline with each request of a given URI. The pipe information (or
pipe sections) could be obtained from a java class:
<process match="/press/en/*.pdf">
<dynapipe type="java">
<parameter name="class" value="uk.co.rabbit.PipeConf"/>
</dynapipe>
</process>
or through another HTTP request:
<process match="/some/path/">
<dynapipe type="HTTP">
<parameter name="URI" value="/pipe/pipe3.pl"/>
</dynapipe
</process>
Jorg
Re: Cocoon2 and Dynamic Site maps
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> Niclas Hedhman wrote:
> >
> > You bet some more!!!
> > And what I miss, I can obtain with AspectJ.
>
> Uh, guess I missed this one. What is it?
It's worth a look. Never heard of Aspect Oriented Programming? It look
quiet interesting. I didn't noticed that there is a AOP implementation
available (and even with java).
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Cocoon2 and Dynamic Site maps
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Stefano Mazzocchi wrote:
>
> > > And what I miss, I can obtain with AspectJ.
> >
> > Uh, guess I missed this one. What is it?
>
> Aspect Oriented Programming is a 'higher' level of programming than OOP. It probably
> has a highly academic background, of that I am not sure, but Xerox has implemented AOP
> for Java, so called AspectJ (www.aspectj.org).
>
> It allows you to define interclass rules in a pretty simple manner. You can, for
> instance, define standardized parameter checking in all methods, overall exception
> handling policies and much more, and AspectJ will add that code everywhere at compile
> time.
>
> The product has been around for more than a year, and is now getting stablized on
> feauters, but I have yet to commit to it on production code.
>
> Don't know if it will gain any wide popularity, but I believe that many companies will
> introduce it as a quality improvement tool.
Thanks, I'm going to take a look right away.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Cocoon2 and Dynamic Site maps
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> > And what I miss, I can obtain with AspectJ.
>
> Uh, guess I missed this one. What is it?
Aspect Oriented Programming is a 'higher' level of programming than OOP. It probably
has a highly academic background, of that I am not sure, but Xerox has implemented AOP
for Java, so called AspectJ (www.aspectj.org).
It allows you to define interclass rules in a pretty simple manner. You can, for
instance, define standardized parameter checking in all methods, overall exception
handling policies and much more, and AspectJ will add that code everywhere at compile
time.
The product has been around for more than a year, and is now getting stablized on
feauters, but I have yet to commit to it on production code.
Don't know if it will gain any wide popularity, but I believe that many companies will
introduce it as a quality improvement tool.
Niclas
Re: Cocoon2 and Dynamic Site maps
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> This is not an argument, just thoughts that are coming through my head.
>
> Stefano Mazzocchi wrote:
>
> > Niclas Hedhman wrote:
> > > I am not exactly sure I understand the thoughts are this, but a dynamically
> > > created/modified sitemap, is as powerful as a nuclear bomb with a 10 second
> > > fuse.
> >
> > ROTFL :)
>
> ????
Rolling on the floor laughing :)
> > The FS antipattern goes like this:
> >
> > 1) there is 1
> > 2) somebody sees that 1 is not enough and 2 fixes the problem
> > 3) your symmetry esthetics come up and say, why not any number?
>
> "1" Fixes X% of the cases.
> "2" fixes Y% of the remaining cases
> "3" fixes Z% of the remaining cases
> :
>
> handled = 1 - (1 - solves(fix) )^NoOfFixes
>
> Where to stop?? That should actually be a design policy determined in the early
> analysis work.
It's not easy at it seems since each iteration bring new complexity and
increases the number of possible problems.
> > 1) we had PIs. This was not a good design, but PI could be dynamically
> > generated.
> > 2) the sitemap was proposed to patch this
> > 3) now 1 + 2 = let's have a dynamically generated sitemap.
> >
> > This is the pattern that (IMHO) leads to unnecessary software
> > complexity.
>
> Componentized frameworks reduces complexity. But each component involved *may* in
> turn be componentized at a lower level.
> Looking at the whole, complexity might increase, but at each level complexity is
> largely reduced to a small number of contracts.
Hey, sounds like my "separation of concerns" vangel is making roots :)
> > The sitemap indicates which components are used to create a resource,
> > when and how.
> >
> > A few decades ago, a big antipattern was proposed: "don't use GOTO".
> > This radically changed the way we think about programming, ever
> > experienced the transition between BASIC and Pascal?
>
> Are you saying that "Using GOTO" is an antipattern, or that "Not Using GOTO" is the
> antipattern??
Oh, yeah sorry, "Using GOTO" is the antipattern, of course.
> > On the other hand, I believe that carefully engineered practices that
> > don't limit your functionality but limit the possible ways you do
> > things, might greatly help in reducing costs and frustration.
>
> Hence, the pluggable architecture found in Cocoon.
yep
> There is another angle that I have been driving lately in my own products.
> By reducing the scope of a class to an absolute minimum, its implementation becomes
> easier. The users of the classes, never use the classname directly, only the
> defined interface, and having that in place, letting the user instantiate via a
> factory out of a 'parameter', the factory can be 'enhanced' with more advanced
> structures later on, without redesign.
> This somewhat shows your 1,2,3 FS detection, but I just believe it simplify
> long-term extendibility.
No, there are some cases where 1,2,3..n is obvious. Object polymorphism
is such a case.
> > There are times when you learn Java that you wish you had this or that
> > feature from this or that other programming language. I guess everybody
> > had the same feeling.
>
> You bet!!!
>
> > But after careful design, you were able to obtain
> > the same functionality and, in my experience, gain code stability,
> > readability and reduce further management costs.
>
> You bet some more!!!
> And what I miss, I can obtain with AspectJ.
Uh, guess I missed this one. What is it?
> > XML is more flexible than ASCII and note that _all_ programming
> > languages are written in ASCII.
>
> Most, but not all. There are programming languages going straight from visual to
> binary. For instance, ladder diagrams for programming PLCs, some programmable logic
> tools goes from visual to bitmasks, and I am sure we have a few more out there.
Good point.
> > > Just wondering in the light of Jorg's question...
> >
> > Jorg introduce a new dimension into the picture.
> >
> > I might be totally wrong, but I don't see why we need such a thing. It's
> > not only FS, it's about unnecessary complexity.
>
> I agree...
>
> > True, many of my reasonings are pure speculations. Sometimes not even
> > based on personal working experience (I am, admittedly, not that
> > experienced).
>
> Noone can be experienced in new fields. (Don't you love those 'Programmer with 5
> years of Java experience', that started a couple of years ago.)
:)
> > But I never put down opinions and I'm never opposed to something just
> > because I didn't think about it. I wouldn't be here if I was like that,
> > don't you think?
>
> Hm. I would say; Everyone else wouldn't be here, if you were like that.
Yeah, better way to put it.
> I essentially agrees with everything, and has not been opposing anything.
> The bootom line, regarding Jorg's question;
>
> a) The proposed SiteMap specification, including the sitemap.xml, is the default
> component and has the No. 1 priority in this project.
>
> b) Then there is a contract between Cocoon and the SiteMap component, which
> (I presume) does not include the sitemap.xml file.
Correct. The sitemap.xml will be the standard way to compile the
pipeline interpreters, just like you can write your own generators by
hand instead of using XSP. You can also create your own XSP-clone if you
want.
> The proposed SiteMap component
> *can* be exchanged for other simpler or more complex SiteMaps. Those SiteMaps are
> not part of Cocoon.
Correct. You can think of creating sitemap-- schemas and use XSLT to
move to the original Cocoon sitemap, or you can write your compiled
sitemap component by hand, so you can introduce anything you want there.
This is not FS, but component polymorphism.
Of course, if your new sitemap design contains FS and becomes a hell to
maintain, well, it's your problem, not ours :)
Note: this doesn't mean the sitemap won't be complete, rather the
opposite, but it should be tuned and balanced between functionality and
complexity.
I know it doesn't mean anything really... but this is the main design
goal anyway.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Cocoon2 and Dynamic Site maps
Posted by Niclas Hedhman <ni...@localbar.com>.
This is not an argument, just thoughts that are coming through my head.
Stefano Mazzocchi wrote:
> Niclas Hedhman wrote:
> > I am not exactly sure I understand the thoughts are this, but a dynamically
> > created/modified sitemap, is as powerful as a nuclear bomb with a 10 second
> > fuse.
>
> ROTFL :)
????
> The FS antipattern goes like this:
>
> 1) there is 1
> 2) somebody sees that 1 is not enough and 2 fixes the problem
> 3) your symmetry esthetics come up and say, why not any number?
"1" Fixes X% of the cases.
"2" fixes Y% of the remaining cases
"3" fixes Z% of the remaining cases
:
handled = 1 - (1 - solves(fix) )^NoOfFixes
Where to stop?? That should actually be a design policy determined in the early
analysis work.
> 1) we had PIs. This was not a good design, but PI could be dynamically
> generated.
> 2) the sitemap was proposed to patch this
> 3) now 1 + 2 = let's have a dynamically generated sitemap.
>
> This is the pattern that (IMHO) leads to unnecessary software
> complexity.
Componentized frameworks reduces complexity. But each component involved *may* in
turn be componentized at a lower level.
Looking at the whole, complexity might increase, but at each level complexity is
largely reduced to a small number of contracts.
> The sitemap indicates which components are used to create a resource,
> when and how.
>
> A few decades ago, a big antipattern was proposed: "don't use GOTO".
> This radically changed the way we think about programming, ever
> experienced the transition between BASIC and Pascal?
Are you saying that "Using GOTO" is an antipattern, or that "Not Using GOTO" is the
antipattern??
> On the other hand, I believe that carefully engineered practices that
> don't limit your functionality but limit the possible ways you do
> things, might greatly help in reducing costs and frustration.
Hence, the pluggable architecture found in Cocoon.
There is another angle that I have been driving lately in my own products.
By reducing the scope of a class to an absolute minimum, its implementation becomes
easier. The users of the classes, never use the classname directly, only the
defined interface, and having that in place, letting the user instantiate via a
factory out of a 'parameter', the factory can be 'enhanced' with more advanced
structures later on, without redesign.
This somewhat shows your 1,2,3 FS detection, but I just believe it simplify
long-term extendibility.
> There are times when you learn Java that you wish you had this or that
> feature from this or that other programming language. I guess everybody
> had the same feeling.
You bet!!!
> But after careful design, you were able to obtain
> the same functionality and, in my experience, gain code stability,
> readability and reduce further management costs.
You bet some more!!!
And what I miss, I can obtain with AspectJ.
> XML is more flexible than ASCII and note that _all_ programming
> languages are written in ASCII.
Most, but not all. There are programming languages going straight from visual to
binary. For instance, ladder diagrams for programming PLCs, some programmable logic
tools goes from visual to bitmasks, and I am sure we have a few more out there.
> > Just wondering in the light of Jorg's question...
>
> Jorg introduce a new dimension into the picture.
>
> I might be totally wrong, but I don't see why we need such a thing. It's
> not only FS, it's about unnecessary complexity.
I agree...
> True, many of my reasonings are pure speculations. Sometimes not even
> based on personal working experience (I am, admittedly, not that
> experienced).
Noone can be experienced in new fields. (Don't you love those 'Programmer with 5
years of Java experience', that started a couple of years ago.)
> But I never put down opinions and I'm never opposed to something just
> because I didn't think about it. I wouldn't be here if I was like that,
> don't you think?
Hm. I would say; Everyone else wouldn't be here, if you were like that.
I essentially agrees with everything, and has not been opposing anything.
The bootom line, regarding Jorg's question;
a) The proposed SiteMap specification, including the sitemap.xml, is the default
component and has the No. 1 priority in this project.
b) Then there is a contract between Cocoon and the SiteMap component, which
(I presume) does not include the sitemap.xml file. The proposed SiteMap component
*can* be exchanged for other simpler or more complex SiteMaps. Those SiteMaps are
not part of Cocoon.
Niclas
Re: Cocoon2 and Dynamic Site maps
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> I am not exactly sure I understand the thoughts are this, but a dynamically
> created/modified sitemap, is as powerful as a nuclear bomb with a 10 second
> fuse.
ROTFL :)
> However, I can imagine that certain applications would possibly want different
> pipelines depending on the request that is currently not possible with the
> sitemap specification, but I think I would recommend (at least for the
> moment) a custom designed Sitemapper in such a case. (The Sitemapper is
> pluggable, is it not?)
Exactly.
The pipeline is composed by turing-complete components. The sitemap has
nothing to do with turing functionality, it must reflect the internals
of the pipeline component model and give enough "componentization"
power.
Sure, we could do a bunch of "class.forname()" like Turbine does. I like
more structured approaches, but I totally understand they should not
limit functionality.
> Stefano, I just came to think about what you said about Perl; "Common things
> should be easy, complex things should be possible." Ring a bell??
> Is that not what you quickly stamp as FS?
I _never_ "quickly stamp" anything. Keep this in mind.
The FS antipattern goes like this:
1) there is 1
2) somebody sees that 1 is not enough and 2 fixes the problem
3) your symmetry esthetics come up and say, why not any number?
FS is when "you follow symmetry 'alone' as design constraint".
This is a perfect example:
1) we had PIs. This was not a good design, but PI could be dynamically
generated.
2) the sitemap was proposed to patch this
3) now 1 + 2 = let's have a dynamically generated sitemap.
This is the pattern that (IMHO) leads to unnecessary software
complexity.
The sitemap indicates which components are used to create a resource,
when and how.
A few decades ago, a big antipattern was proposed: "don't use GOTO".
This radically changed the way we think about programming, ever
experienced the transition between BASIC and Pascal?
Another pattern was: "don't reassemble you code at runtime". I
admittedly did this a couple of times to optimize some ASM routines I
wrote for 3D rendering ages ago. But it's the ultimate obfuscating
contest... even to your eyes. What you gain in speed, you loose in code
manageability. But it's not obvious to understand at first.
More recently: "don't use multiple inheritance".
In a close future: "don't use DTD, use XMLSchema".
In my book: "don't base your progams on XML PIs, use namespaces".
Now, how does this apply to us and FS? Some people believe there should
be no limitation in your power. Sendmail and mod_rewrite, for example,
both have this belief right into their core.
On the other hand, I believe that carefully engineered practices that
don't limit your functionality but limit the possible ways you do
things, might greatly help in reducing costs and frustration.
There are times when you learn Java that you wish you had this or that
feature from this or that other programming language. I guess everybody
had the same feeling. But after careful design, you were able to obtain
the same functionality and, in my experience, gain code stability,
readability and reduce further management costs.
XML is more flexible than ASCII and note that _all_ programming
languages are written in ASCII.
I admittedly could not find any good use of XML before XSLT was
proposed. In fact, the Cocoon pipeline was created to fill the whole on
the server side left by the XSLT language (which is what we now call
"serialization" and was later on proposed as xsl:output)
So, each time, I smell a "1 + 2 = 3" reasoning that is based on adding
functionality in a very foggy direction, I "stamp" FS on it.
> Just wondering in the light of Jorg's question...
Jorg introduce a new dimension into the picture.
I might be totally wrong, but I don't see why we need such a thing. It's
not only FS, it's about unnecessary complexity.
Besides, this is "only" Cocoon2, we have a lifetime to improve on it,
but we need on-field experience to do this.
Cocoon pasts is full of simple choices that was good for 90% of problems
but failed miserably for the rest 10% and required complete redesign to
overcome their limitations.
True, many of my reasonings are pure speculations. Sometimes not even
based on personal working experience (I am, admittedly, not that
experienced).
Sometimes they are good, sometimes they are plain wrong.
But I never put down opinions and I'm never opposed to something just
because I didn't think about it. I wouldn't be here if I was like that,
don't you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Cocoon2 and Dynamic Site maps
Posted by Niclas Hedhman <ni...@localbar.com>.
I am not exactly sure I understand the thoughts are this, but a dynamically
created/modified sitemap, is as powerful as a nuclear bomb with a 10 second
fuse.
However, I can imagine that certain applications would possibly want different
pipelines depending on the request that is currently not possible with the
sitemap specification, but I think I would recommend (at least for the
moment) a custom designed Sitemapper in such a case. (The Sitemapper is
pluggable, is it not?)
Stefano, I just came to think about what you said about Perl; "Common things
should be easy, complex things should be possible." Ring a bell??
Is that not what you quickly stamp as FS? Just wondering in the light of
Jorg's question...
Niclas
Jorg Bauer wrote:
> I really like the concept of the site map where site managers can associate
> different pipelines to requested URIs.
>
> Will it be possible to configure the site map in a way that the pipeline
> specifications are created dynamically?
>
> I am thinking of a mechanism which would allow me to use a different
> pipeline with each request of a given URI. The pipe information (or
> pipe sections) could be obtained from a java class:
>
> <process match="/press/en/*.pdf">
> <dynapipe type="java">
> <parameter name="class" value="uk.co.rabbit.PipeConf"/>
> </dynapipe>
> </process>
>
> or through another HTTP request:
>
> <process match="/some/path/">
> <dynapipe type="HTTP">
> <parameter name="URI" value="/pipe/pipe3.pl"/>
> </dynapipe
> </process>
>
> Jorg
Re: Cocoon2 and Dynamic Site maps
Posted by Stefano Mazzocchi <st...@apache.org>.
Jorg Bauer wrote:
>
> I really like the concept of the site map where site managers can associate
> different pipelines to requested URIs.
>
> Will it be possible to configure the site map in a way that the pipeline
> specifications are created dynamically?
Talking about flexibility syndrome...
> I am thinking of a mechanism which would allow me to use a different
> pipeline with each request of a given URI. The pipe information (or
> pipe sections) could be obtained from a java class:
>
> <process match="/press/en/*.pdf">
> <dynapipe type="java">
> <parameter name="class" value="uk.co.rabbit.PipeConf"/>
> </dynapipe>
> </process>
>
> or through another HTTP request:
>
> <process match="/some/path/">
> <dynapipe type="HTTP">
> <parameter name="URI" value="/pipe/pipe3.pl"/>
> </dynapipe
> </process>
I would be against this for two reasons:
1) it breaks context separation: sitemap maintainers need not be
programmers.
2) it doesn't add any functionality.
I'm totally sure for #1 but I might be missing some of your points for
#2.
Do you envivion something you can't do with the sitemap today that would
require that feature?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------