cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Date Sat, 06 Apr 2002 02:31:26 GMT

Without taking any side in this argument, simply because I don't have enough
real world experience with pipe-aware selectors, I would like to share an
RT.

If xpath selector is chosen to make it in Cocoon,  it can be implemented
very efficiently.
Those who have followed the discussion remember Konstantin and I proposing
an XPath subset which
can cover majority of the use cases.

Indeed there is a readily available library of good quality which can be
utilized.
It is the Digester tool from Apache Jakarta Commons.
http://jakarta.apache.org/commons/digester.html

If I am not mistaken, for a sitemap like the following, Digester can be
initialized with all the selector when tests.
Then it can cash the sax stream until any of the tests is satisfied, at
which point, the cached sax stream can be unleashed to the next SAX
consumer.


<map:match pattern="userDataInsert.xml">
  <map:generate type="stream"/>
  <map:transform src="userData.xsd" type="validator"/>
  <map:select type="xpath">
    <map:when test="/*/@fatal-error">
      <map:transform src="structureErrors.xsl"/>
    </map:when>
    <map:when test="/*/@field-error">
      <map:transform src="userDataForm.xsl"/>
    </map:when>
    <map:otherwise>
      <map:transform type="file-writer" dest="userData.xml"/>
      <map:select type="xpath">
        <map:when test="/result/file-writen='true'">
          <map:transform src="reportInsertResult.xsl"/>
        </map:when>
        <map:otherwise>
          <map:transform src="reportInsertError.xsl"/>
        </map:otherwise>
      </map:select>
    </map:otherwise>
  </map:select>
  <map:serialize/>
</map:match>


Here is a snipped of code from Struts' ActionServlet which demonstrates how
Digester is initialized:



    /**
     * Construct and return a digester that uses the new configuration
     * file format.
     */
    protected Digester initDigester(int detail) {

// Initialize a new Digester instance
Digester digester = new Digester();
digester.push(this);
digester.setDebug(detail);
digester.setValidating(validating);

// Register our local copy of the DTDs that we can find
        for (int i = 0; i < registrations.length; i += 2) {
            URL url = this.getClass().getResource(registrations[i+1]);
            if (url != null)
                digester.register(registrations[i], url.toString());
        }

// Configure the processing rules

        digester.addObjectCreate("struts-config/data-sources/data-source",
                                 "org.apache.struts.util.GenericDataSource",
                                 "type");
        digester.addSetProperties("struts-config/data-sources/data-source");
        digester.addRule("struts-config/data-sources/data-source",
                         new AddDataSourceRule(digester));
        digester.addSetProperty
            ("struts-config/data-sources/data-source/set-property",
             "property", "value");

        digester.addObjectCreate("struts-config/action-mappings/action",
                                 mappingClass, "className");
        digester.addSetProperties("struts-config/action-mappings/action");
        digester.addSetNext("struts-config/action-mappings/action",
                            "addMapping",
                            "org.apache.struts.action.ActionMapping");

        digester.addSetProperty
            ("struts-config/action-mappings/action/set-property",
             "property", "value");

        digester.addObjectCreate
            ("struts-config/action-mappings/action/forward",
             forwardClass, "className");
        digester.addSetProperties
            ("struts-config/action-mappings/action/forward");
        digester.addSetNext("struts-config/action-mappings/action/forward",
                            "addForward",
                            "org.apache.struts.action.ActionForward");

        digester.addSetProperty
            ("struts-config/action-mappings/action/forward/set-property",
             "property", "value");

        digester.addObjectCreate("struts-config/form-beans/form-bean",
                                 formBeanClass, "className");
        digester.addSetProperties("struts-config/form-beans/form-bean");
        digester.addSetNext("struts-config/form-beans/form-bean",
                            "addFormBean",
                            "org.apache.struts.action.ActionFormBean");

        digester.addSetProperty
            ("struts-config/form-beans/form-bean/set-property",
             "property", "value");

        digester.addObjectCreate("struts-config/global-forwards/forward",
                                 forwardClass, "className");
        digester.addSetProperties("struts-config/global-forwards/forward");
        digester.addSetNext("struts-config/global-forwards/forward",
                            "addForward",
                            "org.apache.struts.action.ActionForward");

        digester.addSetProperty
            ("struts-config/global-forwards/forward/set-property",
             "property", "value");

return (digester);

    }






----- Original Message -----
From: "Daniel Fagerström" <danielf@nada.kth.se>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, April 05, 2002 9:11 AM
Subject: Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)


Stefano Mazzocchi wrote:

> Daniel Fagerström wrote:

<snip/>

> We all want this. But I *DO*NOT* want to start tweaking the sitemap
> elegance before the flowmaps are implemented.
>
> My personal perception is that we are using the 'hammer antipattern'
> here: the sitemap is the hammer, and everything looks like a nail.

Or maybe Occam's razor: "one should not increase, beyond what is
necessary, the number of entities required to explain anything" ;)

<snip/>

> For sure we need more symmetry and more functionality in the pipelines.
> If multiplexing and pipe-aware selection are the way to implement them
> is yet to be understood.

Agreed, it is definitly my, (and all the other raving "pipe-aware
selection" fans out there ;) ) resposibility to provide examples on how
elegantly you can construct webapps with the help of just a few extra
sitemap components. I hope to be able to provide some example code and
an RT quite soon. Until then some sceptisism seem like a sound strategy.


>>I know that there have been a lot of concern about that a DOM-based
>>pipe-aware selection mechanism would be a performance bottleneck, but:
<snip/>
> Agreed. My concerns are *not* implementation-wise, I'm *never* concerned
> by implementations because a community can always make it better.

Good, I know that you have said so before, but it is anyway a relief to
hear you saying that in this particular context.


> I'm concerned by architecture design because I don't think that it's
> equivally easy to progressively refine an architecture, expecially when
> you need to provide back compatibility from each incremental step.

> It's easy to add stuff, much easier than *not* to add stuff.
Yes, these are _very_ important concerns, there might be a quite thin line

between entropy death from due to added features and stagnation death due

to fear of adding anything at all.

I can asure you that architectural and conceptual elegance is extremely
important for me. I have struggled with how to handle webapps with a
minimal number, efficient, and easy to understand concepts for months.
That of course doesn't necesarily means that the results of my thinking
is the best possible way of solving this issues, but at least I take
these things seriously.


Anyway I'l try to finish some examples and I'l also repackage the pipe-aware

selector code to a scratchpad contribution and put my hope on that some

kind commiter will add it :) In that case I need a small, small addition

to one of the support classes in the interpreted sitemap - please, please

consider adding it ;)


/Daniel Fagerstrom




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message