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

[Peter Hunsberger <peter.hunsberger@gmail.com>]

On Sun, 9 Jan 2005 03:09:45 -0500, Alan Gutierrez
<alan-xml-dev@engrm.com> wrote:

I'm back, still no time...

> 
> > > > 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...

In an IOC pattern the idea is that instead of using procedural code
directly you're doing configuration on the framework so that it can do
the work.  If you have configuration information that needs to move
between portions of the framework then that information has to move
with whatever the primary framework transport is, so you've got to
configure that.  I'll leave it up to you to determine if that's a
"Strategy", reading ahead it sounds like an Event, but that's not 100%
clear.

<snip/>

>    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. :^{

I understand where you are coming from, but I'm not quite that
dogmatic.  In particular, I consider it more of a Java design flaw
that you can't down cast automatically.  In particular, since you're
doing a framework it makes sense that the users of the framework will
want to exploit polymorphism on some basic underlying interfaces (or
that you want to hide the underlying details via polymorphism).  The
users of the framework should thus never see an "instanceof" in their
code, but the framework itself might not be so lucky; the framework
looks for special case interface extensions as a way of understanding
context but when everything is upcast to the simplest version of the
interface you're stuck with instanceof or try/catch on casts or
introspection - all ugly.  The alternative is to use setter/getter
configuration but that can result in one giant Class doing everything
which is also an anti-pattern...

> 
>    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...

Ok, maybe the Event object is what you need to extend.  Extend the
cubbyholes or test them or whatever to determine error "states"?

> 
>        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?).

Ok, now you've got "Message:, what happened to "Event" ?  Perhaps
these overlapping concepts?

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

Sounds like it.

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

The whole idea of how to use IOC for how to handle Errors in a
framework seems a little murky; from this discussion it almost seems
like you need some meta-IOC pattern: IOC is driven through
configuration, configuration itself can result in errors, thus Error
handling is forced to become a primitive concept, but in your case you
also want it to be a high level concept.  You need a try/catch
framework around your framework.  As such, having testable components
that case the exterior framework to be invoked in the same way as
otherwise unhandable primitive exceptions seems the way to go:

BlowUpNowException for low level errors that indicate the whole
framework is out of wack.

ErrorMessage (ErrorEvent?) throws BlowUpNow (and variations) for some
configurable instance of a test for transport of Errors that may or
may not be handled by some specific tester.  (Allows orthogonal error
mangement: degrees of error handled across degrees of error
tolerance).

-- 
Peter Hunsberger