RE: will commit unless I hear objections...

At 02:59 PM 5/30/2003 -0600, you wrote:
>Ok, on further reflection, I think I'm ok with XMLCStdDOMFactory. This is 
>never really seen outside of Barracuda anyway, right?

Yep, well, except that one has to set a specific DOMFactory one way or 
another; either the application assembler config or programatically since 
there is no default provided in DefaultDOMLoader (which is a good thing).

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

This makes sense, again, when there is only one general way of doing 
something such as is the case with the DefaultDOMLoader.  One might like to 
create their own version of that, but there is nothing that requires 
it.  With the DOMFactory classes, different implementations are 
required.  When you run into this situation and you still want to call 
something "Default", then the semantics change to a value judgement whether 
you want them to or not.  However, since you've accepted a non-"Default" 
naming system for the DOMFactory implementations, we can safely avoid this 
conundrum :-)

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

Yep.... and I assume that there is no problem with adding these methods to 
the ApplicationGateway, since it implements EventGateway, right?  If so, 
I've already done that in local tree and will commit it.

I'll send out another email for more comment on whether a change from 
DefaultDOMWriter to XMLCDOMWriter or DefaultXMLCDOMWriter would be 
acceptable.  The latter name is consistent with the "Default" naming logic 
since there is only one general xmlc dom writer implementation that is 
necessary, but I would be plenty happy with the former naming scheme.

Jake

>
>Christian
>
>----------------------------------------------
>Christian Cryder [[email protected]]
>Internet Architect, ATMReports.com
>Barracuda - <http://barracudamvc.org/>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