RE: will commit unless I hear objections...

Ok, on further reflection, I think I'm ok with XMLCStdDOMFactory. This is
never really seen outside of Barracuda anyway, right?

Claiming one to be a "default" really makes a value judgement about which
one should be used.

Actually, default isn't being used in this sense. It just means "basic
implementation of an abstract class or interface". That's the intent within
Barracuda (ie. all the places you see DefaultXXX in the regular packages).

Would we also want to add the registerLocalEventInterests() and
registerLocalEventAliases() to the interface as well?  I forgot to mention
those before.

Yeah, probably.

So does that answer all your questions?

Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

  -----Original Message-----
  From: [email protected]
[mailto:[email protected]]On Behalf Of Jacob Kjome
  Sent: Friday, May 30, 2003 2:16 PM
  To: [email protected]
  Subject: RE: [Barracuda] will commit unless I hear objections...


  Hi Christian,

  At 01:15 PM 5/30/2003 -0600, you wrote:

    Hi Jake,

    Well, not to be argumentative, but... ;-)


  heh :-)


    > I plan to change the name of DefaultDOMFactory.java to
    > XMLCStdDOMFactory.java.

    I'm happy with the current naming, but it you really want to do this,
then I
    think it should be changed to DefaultXMLCDOMFactory. The reason for this
is
    that everywhere we have a "default" implementation of an interface, it
    always follows the naming convention of Default<interface name>, and if
this
    is going to be the default implementation for the XMLC DOM factory, then
I
    think it makes sense to use the name I suggested above.


  Hmm.... I guess I can see your point about being consistent with using the
"Default"... naming scheme.  However, naming it DefaultXMLCDOMFactory
doesn't tell you what it really is.  The underlying implementation that it
backs is, quite specifically, the XMLCStdFactory.  There are a couple of
other factories out there (some that have been removed from XMLC as well),
one being the XMLCDeferredParsingFactory which, IMHO, should be used as a
"default" over the less capable XMLCStdFactory.  In fact, I have heard
Richard Kunze mention removing the XMLCStdFactory from XMLC entirely since
XMLCDeferredParsingFactory does everything that the latter does, only better
and with much more functionality.  Claiming one to be a "default" really
makes a value judgement about which one should be used.

  There is one way that I can think of which might mitigate our differences
of opinion here;  if we prefix all the Barracuda implementations with
"Default".  Hence, we would have DefaultXMLCStdDOMFatory and
DefaultXMLCDeferredParsingDOMFactory.  This meets both our needs.  However,
it would require me to rename the XMLCDeferredParsingDOMFactory which might
cause confusion since that is now being used in all the application assembly
files in Barracuda proper, BarracudaDiscRack, and both contrib projects (as
well as the test cases I just modified to work with the new behavior of the
DefaultDOMLoader).  I am ok with doing that if everyone else is.  Are you ok
with this?  Otherwise, I'd rather stick to my original proposal of
XMLCStdDOMFactory especially since I think the DOMFactory implementations
are kind of a special case as they are so implementation specific unlike, as
I've mentioned, implementations of the DOMLoader.  There is, generally, only
one way to do dom loading for a specific implementation.  However, there may
be many different DOMFactories that back a general implementation which a
single dom loader might support.  See more below



    > I am also tempted to do the same thing for the DefaultDOMWriter
    > since it is XMLC specific.  The proposed name would be XMLCDOMWriter.

    Once again, I'd prefer DefaultXMLCDOMWriter, for the same reason as
given
    above.


  This makes perfect sense since there aren't, in general, multiple ways to
do dom writing with XMLC like there are multiple xmlc dom factories.
However, the question still remains about how many apps this name change
might break since people probably reference DefaultDOMWriter in their code.
I can live with that if others can, but I wouldn't do this without a lot
more people than you and me thinking it is ok.


    > Having a "default' doesn't really make must sense here because it
    > isn't generic like, for instance, the DefaultDOMLoader is.

    One other thing to mention is that even though there may not be multiple
    XMLC factories/writers at this point, the whole point of interface is

  See above.  There *are* multiple xmlc dom factories by necessity.
Necessity only forces a single xmlc dom writer, though.


    allowing other implementations, so its always possible other ones might
come
    along. In which case, I think "Default" is still entirely appropriate.


  Other implementations duplicating/extending the defaults or other
implementations providing functionality for a completely separate DOM
implementation than XMLC?  If you mean the former, then I agree with you and
something like the name DefaultXMLCStdDOMFactory makes sense since someone
might want to extend that as MyXMLCStdDOMFactory and provide their new and
improved implementation backing the XMLCStdFactory, but if you mean the
latter, "Default" doesn't add any useful semantics here.  For instance, we
could separate implementations with names such as XMLCStdDOMFactory,
XMLCDeferredParsingDOMFactory, Xerces2DOMFactory, etc...  People could still
create MyXMLCStdDOMFactory and extend XMLCStdDOMFactory.  "Default" is
implicit and would really be redundant since by proving a single
implementation of the XMLCStdDOMFactory in the Barracuda source it is
already, quite obviously, the "default" implementation.  So, actually have a
fundamental problem with the whole "Default" naming issue in the first
place, but I'll accept that it is a naming convention used by much of
Barracuda and we have a tacit requirement to stick with it.  Given that (and
moving back to the original question), I hope you are arguing the former and
not the latter, otherwise, IMHO, your argument not logically valid.


    > I propose adding the various specifyLocalEventInterests() and
    > specifyLocalEventAliases() that DefaultEventGateway provides to
    > the EventGateway interface.  That way, we wouldn't have to do the
    > kludgy check for a specify implementation of EventGateway in
    > DefaultApplicationAssembler.  Comments?

    I'm not opposed to this.


  Would we also want to add the registerLocalEventInterests() and
registerLocalEventAliases() to the interface as well?  I forgot to mention
those before.

  Jake


    Christian
    ----------------------------------------------
    Christian Cryder [[email protected]]
    Internet Architect, ATMReports.com
    Barracuda - http://barracudamvc.org
    ----------------------------------------------
    "Coffee? I could quit anytime, just not today"

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Jacob Kjome
    > Sent: Friday, May 30, 2003 12:30 PM
    > To: BarracudaMVC Users List
    > Subject: [Barracuda] will commit unless I hear objections...
    >
    >
    >
    > I plan to change the name of DefaultDOMFactory.java to
    > XMLCStdDOMFactory.java.  I don't think this should cause any
    > problems since
    > nothing in Barracuda references DefaultDOMFactory, nor do I believe
that
    > anyone likely has referenced it themselves since, in the past, the
    > DefaultDOMLoader used it by default and I doubt anyone changed
    > that default.
    >
    > The reason for the change is that the implementations of
    > DOMFactories are,
    > well..., implementation-specific and it makes it much more clear
    > as to what
    > implementation is being used if the name of the class makes this
    > obvious.  Having a "default' doesn't really make must sense here
    > because it
    > isn't generic like, for instance, the DefaultDOMLoader is.
    >
    >
    > I am also tempted to do the same thing for the DefaultDOMWriter
    > since it is
    > XMLC specific.  The proposed name would be XMLCDOMWriter.  However,
this
    > change would be more problematic since there are lots of cases in
    > Barracuda
    > where DefaultDOMWriter is directly referenced and I imagine this
    > is true of
    > applications created by those in the Barracuda community.  So, I
wouldn't
    > make this particular change without the explicit "ok" of the
community.
    >
    >
    > One other thing.  Currently the DefaultApplicationAssembler does
    > a check of
    > whether a particular event gateway is an instance of
DefaultEventGateway
    > when evaluating the <event-interest> and <even-alias>
    > configuration options
    > in the assembly descriptor.  If it isn't, then it throws an
    > exception.  This means that anyone who creates their own application
    > assembler and supports specifying event interests and event alias'
just
    > like DefaultEventGateway, but doesn't extend DefaultEventGateway,
    > will find
    > that these configuration options are unavailable to them.  I
    > propose adding
    > the various specifyLocalEventInterests() and
specifyLocalEventAliases()
    > that DefaultEventGateway provides to the EventGateway interface.
    > That way,
    > we wouldn't have to do the kludgy check for a specify implementation
of
    > EventGateway in DefaultApplicationAssembler.  Comments?  Again, I
    > wouldn't
    > make this particular change without an explicit "ok" from the
community.
    >
    > Jake
    >
    > _______________________________________________
    > Barracuda mailing list
    > [email protected]
    > http://barracudamvc.org/lists/listinfo/barracuda

    _______________________________________________
    Barracuda mailing list
    [email protected]
    http://barracudamvc.org/lists/listinfo/barracuda