You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Rogier Peters <ro...@hivemind.nl> on 2005/02/18 14:06:39 UTC
[OT]Re: [RT] How scripting made me hate java
quoting Stefano Mazzocchi <st...@apache.org>:
> Greg Weinger wrote:
> > This may be way off course, but have you thought about a Cocoon in
> > Squeak?
The thought must have crossed a lot of minds - but I don't actually know of
success-stories of the
"project-X-based-on-project-Y-but-in-a-different-language"
> No and I'm *NOT* rewriting 4 million lines of code (cocoon + all the
> libraries it depends on!) in another language, thanks.
But maybe an interesting question would be: how would cocoon be different when
written in another language. Would you need an XML sitemap if you could just
write your sitemap in a dynamic language?
Not completely relevant link, by way of Bruce Eckel:
http://osteele.com/archives/2003/08/test-versus-type
Re: [OT]Re: [RT] How scripting made me hate java
Posted by Stefano Mazzocchi <st...@apache.org>.
Rogier Peters wrote:
> But maybe an interesting question would be: how would cocoon be different when
> written in another language. Would you need an XML sitemap if you could just
> write your sitemap in a dynamic language?
Yes, that is a very interesting question, but it's not something I want
to spend my time on right now, there are way more important things to
work on and language wars tend to get religious very very fast.
--
Stefano.
Re: [OT]Re: [RT] How scripting made me hate java
Posted by Mark Lowe <me...@gmail.com>.
this might be useful, it might not be. But personally I'd like to be
able to store the mappings information in something like the
cocoon.xconf in an xml format, it could be the struts/jsf/spring
talking but having the servlet configuration in one place makes sense
(to me, there could be good reasons why it wouldn't).
This could cause problems with reloads and suchlike, but the one clear
advantage I see is that it would help prevent the temptation of
coupling the directory struture to the view controllor logic.
definition/binding/template files also seem to cover the same ground
in different ways. I haven't thought the case through yet or seen
whats going on in 2.2 enough to have even any weak views on this. But
on the surface couldn't all this stuff live in one form.xml file? The
validations to be performed, the ids of the fields, the bindings?
To really go off on one, an efficent way of accessing the binding
object. form.getBinding().getPath() or form.binding.path, so when a
command is executed the target method can be accessed.
var insertCMD = cocoon.parameters.insertCMD:
var deleteCMD = cocoon.parameters.deleteCMD:
var businessObject = cocoon.parameters.businessObj;
var form = ...
var commandExecutor =
var setMethod = form.getBinding().getPath();
var bo = Packages.java.lang.Class.forName(businessObject).newInstance();
and so on.
The idea being that the same java class or flowscript can deal with
the crud actions and make the most of cocoon's binding mechanism.The
actions/commands defined as parameters when the function is called. A
new form and its processing could be a matter of creating a new xml
file (assuming the 3 in 1 isn't complete crack smoking).
Sorry I only meant to write the first paragraph.
Mark
On Tue, 22 Feb 2005 10:29:23 -0600, Peter Hunsberger
<pe...@gmail.com> wrote:
> On Tue, 22 Feb 2005 17:00:19 +0100, Stefano Mazzocchi
> <st...@apache.org> wrote:
> > Wojciech Gdela wrote:
> > > Hello,
> > >
> <sni>OO pipeline discussion (sorta)</snip>
>
> > It's also true that we know a lot more than pipeline caching is more a
> > myth than a real useful thing, at times and more so in complex web
> > applications.
>
> Hmm, I wouldn't say that, it's just hard to do well: you end up
> having to break down every different level of data provider into it's
> own generator or source and having some kind of complex cache
> invalidation that can walk orthogonally across the validity objects
> for these generators/sources. Having more-or-less completed this for
> our app I can say we get definite performance benefits.
>
> If I had time I'd like to comment more, but basically we ended up
> building a sort of miniature (3 table) relational database in memory
> to manage the cache (maps many screens to many data sources). Sources
> register invalidation event handlers within it by "invalidation key
> type". Invalidation keys can determine if they match a particular
> event (which passes in a candidate key) and if they do they blow away
> the validity. Different types of keys can decide whether they care
> about other types of keys and to what extent (complete equality,
> partial equality, etc.) That way we get out of the hassle of trying to
> inter-relate every sources dependencies with every other source in
> some kind of complex graph.
>
> Under this scheme we no longer use the Cocoon sitemap for matching,
> pretty much everything is a single generic Cocoon generator. We then
> use Java based lookups (a factory pattern into our EJB layer) to
> determine the sources for various requests. So basically, we already
> have an existence proof that you can have dynamic pipeline
> construction and caching living in coexistence within Cocoon.
>
> > Am I ready to surrender to 'dynamic pipelines'? not yet, but I'm ready
> > to admit that we know better today and given what cocoon has become, it
> > might open the door to even better innovation.
> >
> > So, I welcome RTs on the topic of the 'unification' of sitemap + flow
> > into a 'cocoonscript' that has SAX pipelines as native constructs, even
> > if I urge people to realize that sitemaps will have to be supported for
> > a long time in the future, given our user base.
>
> Well, you may recall my old push for an XSLT based sitemap.... Still
> think it would be conceptually a good way of doing this, but it seems
> pretty obvious that what people want is something more script like and
> not more XSLT!
>
> Given that, having a way to configure component declarations (in an
> XML sitemap type thing) that are then only referenced/matched in some
> kind of flowscript like language (taking the sitemap pipelines out of
> the picture) seems natural? Eg, prebuilt Javascript pipeline objects.
> If you want to do this in Java, then really, source resolvers already
> give you (more-or-less) the Cocoon way of doing this...
>
> --
> Peter Hunsberger
>
Re: [OT]Re: [RT] How scripting made me hate java
Posted by Peter Hunsberger <pe...@gmail.com>.
On Tue, 22 Feb 2005 17:00:19 +0100, Stefano Mazzocchi
<st...@apache.org> wrote:
> Wojciech Gdela wrote:
> > Hello,
> >
<sni>OO pipeline discussion (sorta)</snip>
> It's also true that we know a lot more than pipeline caching is more a
> myth than a real useful thing, at times and more so in complex web
> applications.
Hmm, I wouldn't say that, it's just hard to do well: you end up
having to break down every different level of data provider into it's
own generator or source and having some kind of complex cache
invalidation that can walk orthogonally across the validity objects
for these generators/sources. Having more-or-less completed this for
our app I can say we get definite performance benefits.
If I had time I'd like to comment more, but basically we ended up
building a sort of miniature (3 table) relational database in memory
to manage the cache (maps many screens to many data sources). Sources
register invalidation event handlers within it by "invalidation key
type". Invalidation keys can determine if they match a particular
event (which passes in a candidate key) and if they do they blow away
the validity. Different types of keys can decide whether they care
about other types of keys and to what extent (complete equality,
partial equality, etc.) That way we get out of the hassle of trying to
inter-relate every sources dependencies with every other source in
some kind of complex graph.
Under this scheme we no longer use the Cocoon sitemap for matching,
pretty much everything is a single generic Cocoon generator. We then
use Java based lookups (a factory pattern into our EJB layer) to
determine the sources for various requests. So basically, we already
have an existence proof that you can have dynamic pipeline
construction and caching living in coexistence within Cocoon.
> Am I ready to surrender to 'dynamic pipelines'? not yet, but I'm ready
> to admit that we know better today and given what cocoon has become, it
> might open the door to even better innovation.
>
> So, I welcome RTs on the topic of the 'unification' of sitemap + flow
> into a 'cocoonscript' that has SAX pipelines as native constructs, even
> if I urge people to realize that sitemaps will have to be supported for
> a long time in the future, given our user base.
Well, you may recall my old push for an XSLT based sitemap.... Still
think it would be conceptually a good way of doing this, but it seems
pretty obvious that what people want is something more script like and
not more XSLT!
Given that, having a way to configure component declarations (in an
XML sitemap type thing) that are then only referenced/matched in some
kind of flowscript like language (taking the sitemap pipelines out of
the picture) seems natural? Eg, prebuilt Javascript pipeline objects.
If you want to do this in Java, then really, source resolvers already
give you (more-or-less) the Cocoon way of doing this...
--
Peter Hunsberger
Re: [OT]Re: [RT] How scripting made me hate java
Posted by Stefano Mazzocchi <st...@apache.org>.
Wojciech Gdela wrote:
> Hello,
>
>> But maybe an interesting question would be: how would cocoon be
>> different when
>> written in another language. Would you need an XML sitemap if you
>> could just
>> write your sitemap in a dynamic language?
>
>
> I've recently developed very small cocoon-like framework in php
> language. What I really love about it is writing pipelines in OO php
> code instead of xml. Here are some examples of pipelines:
>
> 1. Simple pipeline like in cocoon:
>
> class DealersListPipeline extends COPipeline {
> function execute() {
> $this->generate('dealers-list', null, this->parameters);
> $this->transform('xslt', 'dealers-list2html.xslt');
> $this->transform('xslt', 'address2html.xslt');
> $this->serialize('html');
> }
> }
>
> 2. I can have any code in pipelines:
>
> class FooBlaPipeline extends COPipeline {
> function execute() {
> if (rand(0,1) == 1) {
> $this->generate('file', 'foo.xml');
> } else {
> $this->generate('file', 'bla.xml');
> }
> $name = $this->do_some_magic_computations();
> $this->transform('xslt', "layout-$name.xslt");
> $this->serialize('html');
> }
>
> function do_some_magic_computations() {
> // magic
> }
> }
>
> 3. I can create abstract pipelines:
>
> class CenterIframePipeline extends COPipeline {
> function execute($sourcePrefix, $page) {
> if ($page == 'page' || $page == 'content') {
> $source = "{$sourcePrefix}.xml";
> } else {
> $source = "{$sourcePrefix}-{$page}.xml";
> }
> $this->generate('file', $source, $this->parameters);
> if ($page == 'page') {
> $this->transform('xslt', 'center-iframe-page.xslt');
> } else {
> $this->transform('xslt', 'center-iframe-content.xslt');
> }
> $this->serialize('html');
> }
> }
>
> class ReviewPipeline extends CenterIframePipeline {
> function execute() {
> parent::execute('review', $this->parameters->get('page'));
> }
> }
>
> class WallsPipeline extends CenterIframePipeline {
> function execute() {
> parent::execute('walls', $this->parameters->get('page'));
> }
> }
>
> I think it's very flexible to have pipelines defined as classes. I can
> code in OO manner, use business classes (services) directly with no need
> to code action classes. And i have one language (php) instead of two
> (xml+flowscript).
>
> Pipelines are mounted in sitemaps definitions, also implemented as php
> classes, but this is not so usefull and I would prefer to have this in
> xml file:
>
> class MainSitemap extends COSitemap {
> function components(&$container) {
> $container->registerMatcher('string-uri',
> 'matching/StringUriMatcher.php');
> $container->registerMatcher('uri',
> 'matching/WildcardUriMatcher.php');
>
> $container->registerGenerator('file',
> 'generation/FileGenerator.php');
>
> $container->registerTransformer('xslt',
> 'transformation/XsltTransformer.php');
>
> $container->registerSerializer('xml',
> 'serialization/XmlSerializer.php');
> $container->registerSerializer('html',
> 'serialization/HtmlSerializer.php');
> }
>
> function sitemaps(&$manager) {
> $manager->mount('string-uri', '/building', 'building/Sitemap.php');
> $manager->mount('string-uri', '/service', 'service/Sitemap.php');
> }
>
> function pipelines(&$manager) {
> $manager->mount('uri',
> '/dealers-list/{*:type}/{*:value}/{#:services}',
> 'DealersListPipeline');
> $manager->mount('uri', '/messages-list', 'MessagesListPipeline');
> $manager->mount('uri', '/message/{#:id}', 'MessageViewPipeline');
> }
> }
Yes, I've been thinking about this *a lot* over the last 2 years, since
I've been using flowscript a lot.
The idea of having sitemap and flowscript separated was that they were
normally written by different people with different skills.
It turns out this is really not the case, so this is not SoC but OSoC
(over-separation of concerns), an anti-pattern and it is harmful in some
scenarios.
In scenarios when Cocoon is still used in publishing stateless
environments, the sitemap still rocks, because of it declarative nature.
When you have control transferred by the sitemap to flow and back
several times for a single request (and this is happening more and more
as cocoon web applications become more complex and people start to
appreciate the use of continuations!) this 'duality' is actually making
things more fragile, because a change in one file has to be matched by
another change in another file... a clear indication of OSoC.
Note that the above makes it possible to build 'dynamic pipelines'...
which I have been considered 'sinful' since years, mostly because there
are big caching prices to pay (how can you tell if a pipeline is not
cacheable?)
It's also true that we know a lot more than pipeline caching is more a
myth than a real useful thing, at times and more so in complex web
applications.
Am I ready to surrender to 'dynamic pipelines'? not yet, but I'm ready
to admit that we know better today and given what cocoon has become, it
might open the door to even better innovation.
So, I welcome RTs on the topic of the 'unification' of sitemap + flow
into a 'cocoonscript' that has SAX pipelines as native constructs, even
if I urge people to realize that sitemaps will have to be supported for
a long time in the future, given our user base.
--
Stefano.
Re: [OT]Re: [RT] How scripting made me hate java
Posted by Torsten Curdt <tc...@apache.org>.
>> But maybe an interesting question would be: how would cocoon be
>> different when
>> written in another language. Would you need an XML sitemap if you
>> could just
>> write your sitemap in a dynamic language?
This is not the first time this comes up...
To be honest: a "map:match" always felt like a function
to me. With the request and other variables as parameters
and the pipeline output as the result.
...so this not does sound too far out for me.
cheers
--
Torsten
Re: [OT]Re: [RT] How scripting made me hate java
Posted by Wojciech Gdela <el...@poczta.onet.pl>.
Hello,
> But maybe an interesting question would be: how would cocoon be different when
> written in another language. Would you need an XML sitemap if you could just
> write your sitemap in a dynamic language?
I've recently developed very small cocoon-like framework in php
language. What I really love about it is writing pipelines in OO php
code instead of xml. Here are some examples of pipelines:
1. Simple pipeline like in cocoon:
class DealersListPipeline extends COPipeline {
function execute() {
$this->generate('dealers-list', null, this->parameters);
$this->transform('xslt', 'dealers-list2html.xslt');
$this->transform('xslt', 'address2html.xslt');
$this->serialize('html');
}
}
2. I can have any code in pipelines:
class FooBlaPipeline extends COPipeline {
function execute() {
if (rand(0,1) == 1) {
$this->generate('file', 'foo.xml');
} else {
$this->generate('file', 'bla.xml');
}
$name = $this->do_some_magic_computations();
$this->transform('xslt', "layout-$name.xslt");
$this->serialize('html');
}
function do_some_magic_computations() {
// magic
}
}
3. I can create abstract pipelines:
class CenterIframePipeline extends COPipeline {
function execute($sourcePrefix, $page) {
if ($page == 'page' || $page == 'content') {
$source = "{$sourcePrefix}.xml";
} else {
$source = "{$sourcePrefix}-{$page}.xml";
}
$this->generate('file', $source, $this->parameters);
if ($page == 'page') {
$this->transform('xslt', 'center-iframe-page.xslt');
} else {
$this->transform('xslt', 'center-iframe-content.xslt');
}
$this->serialize('html');
}
}
class ReviewPipeline extends CenterIframePipeline {
function execute() {
parent::execute('review', $this->parameters->get('page'));
}
}
class WallsPipeline extends CenterIframePipeline {
function execute() {
parent::execute('walls', $this->parameters->get('page'));
}
}
I think it's very flexible to have pipelines defined as classes. I can
code in OO manner, use business classes (services) directly with no need
to code action classes. And i have one language (php) instead of two
(xml+flowscript).
Pipelines are mounted in sitemaps definitions, also implemented as php
classes, but this is not so usefull and I would prefer to have this in
xml file:
class MainSitemap extends COSitemap {
function components(&$container) {
$container->registerMatcher('string-uri',
'matching/StringUriMatcher.php');
$container->registerMatcher('uri',
'matching/WildcardUriMatcher.php');
$container->registerGenerator('file',
'generation/FileGenerator.php');
$container->registerTransformer('xslt',
'transformation/XsltTransformer.php');
$container->registerSerializer('xml',
'serialization/XmlSerializer.php');
$container->registerSerializer('html',
'serialization/HtmlSerializer.php');
}
function sitemaps(&$manager) {
$manager->mount('string-uri', '/building', 'building/Sitemap.php');
$manager->mount('string-uri', '/service', 'service/Sitemap.php');
}
function pipelines(&$manager) {
$manager->mount('uri',
'/dealers-list/{*:type}/{*:value}/{#:services}',
'DealersListPipeline');
$manager->mount('uri', '/messages-list', 'MessagesListPipeline');
$manager->mount('uri', '/message/{#:id}', 'MessageViewPipeline');
}
}
--
Pozdrawiam,
Wojciech Gdela.