Re: [OT]Re: [RT] How scripting made me hate java

[Stefano Mazzocchi]

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.