You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Jacob Kjome <ho...@visi.com> on 2006/08/30 04:02:22 UTC
request CoreDocumentImpl.callUserDataHandlers() methods to be
made protected
I'd like CoreDocumentImpl.callUserDataHandlers() methods to be
protected instead of package private. The reason I'd like is that I
have a custom DOM implementation that extends DocumentImpl. I need
to override cloneNode(boolean) to make sure an instance of my own
Document implementation gets created instead of the parent
implementation. But then I can't access the callUserDataHandlers()
methods such as is being done in CoreDocumentImpl....
public Node cloneNode(boolean deep) {
CoreDocumentImpl newdoc = new CoreDocumentImpl();
callUserDataHandlers(this, newdoc, UserDataHandler.NODE_CLONED);
cloneNode(newdoc, deep);
return newdoc;
}
...or in DocumentImpl....
public Node cloneNode(boolean deep) {
DocumentImpl newdoc = new DocumentImpl();
callUserDataHandlers(this, newdoc, UserDataHandler.NODE_CLONED);
cloneNode(newdoc, deep);
// experimental
newdoc.mutationEvents = mutationEvents;
return newdoc;
}
If this is not objectionable, could this be done before the next release?
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: request CoreDocumentImpl.callUserDataHandlers() methods to be made
protected
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Jake,
Jacob Kjome <ho...@visi.com> wrote on 08/30/2006 12:15:36 AM:
<snip/>
> >> If this is not objectionable, could this be done before the next
> >release?
> >
> >The HTML DOM [1] should probably be calling that method too and would
need
> >this change in order to call it. I'll put it on my TODO list. Just
> >remember, you're taking a risk by extending or referencing Xerces'
> >internals. Any class or interface marked with @xerces.internal could
go
> >away or have methods on them change in the future.
> >
>
> Yep, no problem. If Xerces goes some other direction that I can't
> follow, then I'll roll it up into my own namespace. Actually, that
> is what I'm doing now. I'll have the chance to quit wrapping it in
> my own namespace as soon as the next version of Xerces is released
> (along with a new version of xmlcommons-resolver).
There's been no movement on a new resolver release. I don't think there
are any technical issues blocking one. Just nobody has stepped up to make
it happen yet. If you're interested in seeing one get into the next Xerces
release (I've been thinking of proposing one for September) you should try
stirring up a conversation on the xml-commons list (and probably pinging
Norm).
> Thanks!
>
> Jake
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: request CoreDocumentImpl.callUserDataHandlers() methods to
be made protected
Posted by Jacob Kjome <ho...@visi.com>.
At 09:47 PM 8/29/2006, you wrote:
>Hi Jake,
>
>Jacob Kjome <ho...@visi.com> wrote on 08/29/2006 10:02:22 PM:
>
>> I'd like CoreDocumentImpl.callUserDataHandlers() methods to be
>> protected instead of package private. The reason I'd like is that I
>> have a custom DOM implementation that extends DocumentImpl. I need
>> to override cloneNode(boolean) to make sure an instance of my own
>> Document implementation gets created instead of the parent
>> implementation. But then I can't access the callUserDataHandlers()
>> methods such as is being done in CoreDocumentImpl....
>>
>> public Node cloneNode(boolean deep) {
>> CoreDocumentImpl newdoc = new CoreDocumentImpl();
>> callUserDataHandlers(this, newdoc,
>UserDataHandler.NODE_CLONED);
>> cloneNode(newdoc, deep);
>>
>> return newdoc;
>> }
>>
>>
>> ...or in DocumentImpl....
>>
>> public Node cloneNode(boolean deep) {
>> DocumentImpl newdoc = new DocumentImpl();
>> callUserDataHandlers(this, newdoc,
>UserDataHandler.NODE_CLONED);
>> cloneNode(newdoc, deep);
>>
>> // experimental
>> newdoc.mutationEvents = mutationEvents;
>>
>> return newdoc;
>> }
>>
>>
>> If this is not objectionable, could this be done before the next
>release?
>
>The HTML DOM [1] should probably be calling that method too and would need
>this change in order to call it. I'll put it on my TODO list. Just
>remember, you're taking a risk by extending or referencing Xerces'
>internals. Any class or interface marked with @xerces.internal could go
>away or have methods on them change in the future.
>
Yep, no problem. If Xerces goes some other direction that I can't
follow, then I'll roll it up into my own namespace. Actually, that
is what I'm doing now. I'll have the chance to quit wrapping it in
my own namespace as soon as the next version of Xerces is released
(along with a new version of xmlcommons-resolver).
Thanks!
Jake
>> Jake
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-users-help@xerces.apache.org
>
>Thanks.
>
>[1] http://marc.theaimsgroup.com/?l=xerces-cvs&m=115169734127877&w=2
>
>Michael Glavassevich
>XML Parser Development
>IBM Toronto Lab
>E-mail: mrglavas@ca.ibm.com
>E-mail: mrglavas@apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: request CoreDocumentImpl.callUserDataHandlers() methods to be made protected
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Michael Glavassevich <mr...@ca.ibm.com>:
> Michael Glavassevich/Toronto/IBM@IBMCA wrote on 08/29/2006 10:47:40 PM:
>
> <snip/>
>
> > The HTML DOM [1] should probably be calling that method too and would
> need
> > this change in order to call it. I'll put it on my TODO list.
>
> Done. See
> http://marc.theaimsgroup.com/?l=xerces-cvs&m=115708594609734&w=2.
>
Excellent! Thanks :-)
Jake
> > Just remember, you're taking a risk by extending or referencing Xerces'
> > internals. Any class or interface marked with @xerces.internal could go
> > away or have methods on them change in the future.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: request CoreDocumentImpl.callUserDataHandlers() methods to be made
protected
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Michael Glavassevich/Toronto/IBM@IBMCA wrote on 08/29/2006 10:47:40 PM:
<snip/>
> The HTML DOM [1] should probably be calling that method too and would
need
> this change in order to call it. I'll put it on my TODO list.
Done. See
http://marc.theaimsgroup.com/?l=xerces-cvs&m=115708594609734&w=2.
> Just remember, you're taking a risk by extending or referencing Xerces'
> internals. Any class or interface marked with @xerces.internal could go
> away or have methods on them change in the future.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: request CoreDocumentImpl.callUserDataHandlers() methods to be made
protected
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jake,
Jacob Kjome <ho...@visi.com> wrote on 08/29/2006 10:02:22 PM:
> I'd like CoreDocumentImpl.callUserDataHandlers() methods to be
> protected instead of package private. The reason I'd like is that I
> have a custom DOM implementation that extends DocumentImpl. I need
> to override cloneNode(boolean) to make sure an instance of my own
> Document implementation gets created instead of the parent
> implementation. But then I can't access the callUserDataHandlers()
> methods such as is being done in CoreDocumentImpl....
>
> public Node cloneNode(boolean deep) {
> CoreDocumentImpl newdoc = new CoreDocumentImpl();
> callUserDataHandlers(this, newdoc,
UserDataHandler.NODE_CLONED);
> cloneNode(newdoc, deep);
>
> return newdoc;
> }
>
>
> ...or in DocumentImpl....
>
> public Node cloneNode(boolean deep) {
> DocumentImpl newdoc = new DocumentImpl();
> callUserDataHandlers(this, newdoc,
UserDataHandler.NODE_CLONED);
> cloneNode(newdoc, deep);
>
> // experimental
> newdoc.mutationEvents = mutationEvents;
>
> return newdoc;
> }
>
>
> If this is not objectionable, could this be done before the next
release?
The HTML DOM [1] should probably be calling that method too and would need
this change in order to call it. I'll put it on my TODO list. Just
remember, you're taking a risk by extending or referencing Xerces'
internals. Any class or interface marked with @xerces.internal could go
away or have methods on them change in the future.
> Jake
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
Thanks.
[1] http://marc.theaimsgroup.com/?l=xerces-cvs&m=115169734127877&w=2
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org