Re: [xml-dev] Re: SAX IoC Errors (Was: SAXException, checked, buy why?)

[Alan Gutierrez <alan-xml-dev@engrm.com>]

* Peter Hunsberger <peter.hunsberger@gmail.com> [2005-01-07 11:39]:
> On Thu, 6 Jan 2005 12:08:10 -0500, Alan Gutierrez
> <alan-xml-dev@engrm.com> wrote:
> 
> Hi Alan, not much time, I'll be out until next Wed.  Please excuse the
> random un-annotated snips.
> 
> <snip/> 

> > > Hmm, maybe you should just treat the exceptions like any other
> > > Strategy?  Don't even distinguish between them except for someway to
> > > "test" them?  That seems more-or-less what you're doing but you seem
> > > to have two interfaces where I'd have one...
> > 
> >    I have two, because the first interface cares about the error,
> >    it's type, it's contents, the second only cares that an error
> >    occured. The first is error handling, the second is cleanup.

> That's the issue, you're still treating the Error itself as a special
> case.  As you note latter, I'm thinking maybe it's just a case of a
> Strategy (or maybe something else).

    It's definately something else...    

> > > Yes, but why add the extra interface?  Why not just re-use the same
> > > interfaces you already have and implement them in the error objects?
> > > If no error happens you get back the normal objects and they produce
> > > they normal SAX stream, otherwise you get back an error object and it
> > > produces the error SAX stream unless you care to "test" it in which
> > > case it bubbles up the problems to to whom ever the "tester"
> > > (Responder?) is?
> > 
> >    Are you thinking that I ought to use the Strategy interface? Or
> >    are you talking about my idea to have two error interfaces?
> 
> The former, StrategyError extends Strategy.  It add's methods for
> testing and moving things around that need retrying or whatever you
> want to do, but in general you can just pop it up and down your stack
> like anything else.

    Just a reminder of the context of the discussion...

> > > Perhaps, I tend to end up with Interfaces wrapping Interfaces for
> > > cases where I want to extend generic code with really special case
> > > code.  That sometimes leads to "instanceof" type if/else blocks but
> > > mostly polymorphism handles the whole thing cleanly and I don't have
> > > to distinguish between "retry", "pass", etc. except for the
> > > polymorphic versions of the methods.  In particular, a polymorphic
> > > constructor or initializer on your Responder (I think) might handle
> > > Strategy vs. ErrorStrategy in such cases?
> > 
> >    Oh, you seem to think that Strategy and ErrorStrategy ought to
> >    be the same thing. Right?
> > 
> >    Here's Strategy as it stands:
> > 
> >    public interface Strategy {
> >        void launched(Campaign campaign, Event event);
> >        void startElement(Campaign campaign, Event event);
> >        void characters(Campaign campaign, Event event);
> >        void processingInstruction(Campaign campaign, Event event);
> >        void skippedEntity(Campaign campaign, Event event);
> >        void comment(Campaign campaign, Event event);
> >        void endElement(Campaign campaign, Event event, Campaign concluded);
> >        void concluding(Campaign campaign, Event event);
> >    }
> > 
> >    What you've suggested, in a number of ways, is the idea that
> >    errors flow forward to the next SAX handler. I'm not there yet.
> > 
> >    I'm still trying to figure out how a SAX handler, composed of
> >    Strategies, handles it's own errors. How do errors flow back to
> >    the head of the SAX chain?
> > 
> >    In this discussion, I saw my Strategy stack as an event conduit
> >    in itself.

> It appears that wrapping this would do what I think you want to do. 
> StrategyError  adds the special case handling to Strategy as needed. 
> The portions of the code that care about errors can check for
> instanceof  (or better use polymorphic methods) on the handling of
> Strategy.

    I'm not using instanceof anywhere in the SAX Strategy library.
    If it were introduced, it would indicate an error in design to me.
    I'm that way about instanceof. :^{

    A Strategy for error handling wouldn't make much sense unless it
    existed as a Strategy for a SAX handler that is up stream.
    
    There three concepts in the model
    
        1) The stream of events, moving from one Straegy composition
            to the next. Within a SAX handler Stratregies can
            respond to events, but they cannot filter events from
            other Strategies in the same SAX handler.

            The strategy composition intercepts, injects, or filters
            events. Chaining is the means by which SAX Strategy
            alters data for its own consumption.

            EventStack -> Strategies -> EventStack
                                            -> Strategies -> EventStack
    
            A Strategy can inspect the event stack before it and
            beyond it, and feeds events to the stack before it.

            But you can't fiddle with the stack. You can only change
            it's shape by emitting well-formed XML.

        2) The stacks of events do exist. There is an Event object
            that acts as a stack node. There is a separate Lexeme
            interface heirarchy that models the data (events,
            characters, processingInstructions, etc.).
            
            The Lexemes are separated since they can be recorded as
            a stream and replayed. The stack for each lexeme would
            be derived when the lexemes are replayed.

            The stack helps to generate locator information. It
            helps in creating filter logic, dispatching.
            
            I'd like to port STXPath for use with pattern matching
            in strategy compositions. It could make use of this stack.
            I'm looking at STXPath and Jaxen, and I think latter
            will work if you only use certian axis.

            I have some simple matching classes that I use currently.

            The Event objects also have cubbyholes where a program
            can put state. This is rarely used in leiu of...

        3) The Campaign stack.
        
            At any point you can launch a new Strategy. The context
            for a Strategy is a Campaign.

            As of today, the Campaign stack is also a message
            conduit.
            
            So, there are now two separate models for messages. SAX
            Events, as in Strategy class above. And this here:

            public interface Receptionist {
                void message(Campaign campaign, Event event, Message message) {
                }
            }

            public interface Message {
                CampaignKey key();
                Object data();
                void intercept();
            }

            public interface Campaign {
                /* Send messages up stack. */
                void hook(CampaignKey key, Receptionist receptionist);
                void unhook(CampaignKey key);
                void post(CampaignKey key, Object data);

                /* Preserve state for down stack. */
                Object put(CampaignKey key, Object data);
                Object get(CampaignKey key);
                Object seek(CampaignKey key);
            }

            The campaign stack is different from the event stack,
            yet it is still tied to the stream of events. Once a
            Strategy is launched, it's Campaign is not popped off
            the Campaign stack until the endElement event during
            which it occured (did I say that right?).

    This Campaign stack is acting as a funnel for SAX Events. It is
    amazing how much easier it is to progam SAX filters with the
    concept is place. I've refactored all my code, to use the
    Campaign event conduit.
    
    It is much easier to divide the tasks between gathering data
    from the XML stream, and processing that data. Receptionists end
    up containing the bulk of the application logic. While
    Strategies are assembled from a stable of stock Strategy
    implementations.

    With this condiut, it becomes much easier for me to envision
    multiplexing strategies. The campaign stacks can fork and
    messages can filter to a common root.

    Errors are a flavor of Message, and not Strategy, then...

    In any case, this last post isn't so much about Errors, as it is
    about using SAX to drive Java in ala IoC.
    
    Cheers.

--
Alan Gutierrez - alan@engrm.com