Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.0.0-alpha-1
    • Fix Version/s: 3.0.0-alpha-2
    • Component/s: cocoon-sax
    • Labels:
      None

      Description

      Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module
      1. StAX-classes.png
        27 kB
        Andreas Pieber
      2. cocoon-stax.patch
        41 kB
        Carsten Ziegeler
      3. cocoon-3.patch
        47 kB
        Carsten Ziegeler

        Activity

        Hide
        Carsten Ziegeler added a comment -
        Ah yes, it doesn't cover this as I don't have Java 6 on my machine :(
        But I can update the patch
        Show
        Carsten Ziegeler added a comment - Ah yes, it doesn't cover this as I don't have Java 6 on my machine :( But I can update the patch
        Hide
        Reinhard Poetz added a comment - - edited
        The patch doesn't cover the cocoon-stax module :-(

        BTW, there is it.bat (or it.sh of *nix) that runs all unit and integration tests and performs license header checks.
        Show
        Reinhard Poetz added a comment - - edited The patch doesn't cover the cocoon-stax module :-( BTW, there is it.bat (or it.sh of *nix) that runs all unit and integration tests and performs license header checks.
        Hide
        Carsten Ziegeler added a comment -
        Proposed patch
        Show
        Carsten Ziegeler added a comment - Proposed patch
        Hide
        Carsten Ziegeler added a comment -
        Ok, having worked with the xml consumer interface for years now, I came to the conclusion that things get much simpler if you just rely on content handler
        It makes using the sax stuff much easier and more convenient - I don't think that we need to keep the stax stuff and other impl in sync just for the sake of having them in sync.

        But please let's do this discussion in the mailing list - i've started an RT some days ago about this topic and so far got only positive response (from Sylvain)
        Show
        Carsten Ziegeler added a comment - Ok, having worked with the xml consumer interface for years now, I came to the conclusion that things get much simpler if you just rely on content handler It makes using the sax stuff much easier and more convenient - I don't think that we need to keep the stax stuff and other impl in sync just for the sake of having them in sync. But please let's do this discussion in the mailing list - i've started an RT some days ago about this topic and so far got only positive response (from Sylvain)
        Hide
        Jakob Spörk added a comment -
        I'm of the same opinion as Andreas. Only because removing the XConsumer and XProducer interfaces will work for SAX, I wouldn't do that because it would destroy the described similarities between different pipeline APIs.

        I also do not see the advantage in removing these interface because this wont affect the performance and when dealing with writing components, the developer will only need transformers (AbstractTransformer), generators (AbstractGenerator) and serializer (AbstractSerializter) and has not to touch any of the interfaces.

        I think one page of user manual will provider more clarity to new users than the removal of these interfaces.
        Show
        Jakob Spörk added a comment - I'm of the same opinion as Andreas. Only because removing the XConsumer and XProducer interfaces will work for SAX, I wouldn't do that because it would destroy the described similarities between different pipeline APIs. I also do not see the advantage in removing these interface because this wont affect the performance and when dealing with writing components, the developer will only need transformers (AbstractTransformer), generators (AbstractGenerator) and serializer (AbstractSerializter) and has not to touch any of the interfaces. I think one page of user manual will provider more clarity to new users than the removal of these interfaces.
        Hide
        Andreas Pieber added a comment -
        I'm not quite sure what I should think about this idea. On one hand it would eliminate not really required interfaces which is quite a good idea, but on the other hand it would (IMO) also create complexity on an other side. I attached a very simple class diagram of the cocoon-stax component. If you replace StAX (in the names) with Image you'll see the base architecture of the image-component proposed by Steven. Replacing StAX with SAX would produce the very basic architecture of the cocoon-sax module. And replacing StAX with any other name will (hopefully) produce the base architecture of any other future pipeline module.

        So, if you're familiar with one component (e.g. StAX) you can very easily transfer your knowledge to any other component, since the basic architecture (NAMEProducer, NAMEConsumer, ...) is the very same throughout all components. From that point of view it may be a better idea to rename XMLConsumer and XMLProducer to SAXConsumer and SAXProducer instead of removing them.

        Of course I'm not sure in how far this assumption will hold for all future components...

        WDYT about that?
        Show
        Andreas Pieber added a comment - I'm not quite sure what I should think about this idea. On one hand it would eliminate not really required interfaces which is quite a good idea, but on the other hand it would (IMO) also create complexity on an other side. I attached a very simple class diagram of the cocoon-stax component. If you replace StAX (in the names) with Image you'll see the base architecture of the image-component proposed by Steven. Replacing StAX with SAX would produce the very basic architecture of the cocoon-sax module. And replacing StAX with any other name will (hopefully) produce the base architecture of any other future pipeline module. So, if you're familiar with one component (e.g. StAX) you can very easily transfer your knowledge to any other component, since the basic architecture (NAMEProducer, NAMEConsumer, ...) is the very same throughout all components. From that point of view it may be a better idea to rename XMLConsumer and XMLProducer to SAXConsumer and SAXProducer instead of removing them. Of course I'm not sure in how far this assumption will hold for all future components... WDYT about that?

          People

          • Assignee:
            Unassigned
            Reporter:
            Carsten Ziegeler
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development