svn commit: r388911 - TEXT_COMPOUND_DELIMITER

Hi all,

   I am curious to hear how/if people are using
TEXT_COMPOUND_DELIMITER.

   The solution I committed is maximally backwards
compatible but has some 
uglyness
to it.  My proffered solution would be to remove
TEXT_COMPOUND_DELIMITER
completely and instead use TEXT_COMPOUND_ID as a soft
reference to the 
Element. 

   This would clean up the code a bit and make the behavior
a little less 
modal than
it currently is.  Would this be a significant problem for
anyone?

deweeseapache.org wrote on 03/26/2006 09:40:51 AM:

> 2) In most places TEXT_COMPOUND_DELIMITER has
effectively been
>    replaced by TEXT_COMPOUND_ID.  TEXT_COMPOUND_ID has
a unique
>    value for each element in the DOM but retains no
reference to
>    the element.
> 
>    In dynamic documents TEXT_COMPOUND_DELIMITER is
still bound on
>    elements, with a hard reference to the DOM element.


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Hi,

On Sun, 2006-03-26 at 10:11 -0500, thomas.deweesekodak.com
wrote:
> Hi all,
> 
>    I am curious to hear how/if people are using
TEXT_COMPOUND_DELIMITER.

I am heavy usage on TEXT_COMPOUND_DELIMITER. It is used in
our inline
editing Text Editor Component.
>    The solution I committed is maximally backwards
compatible but has some 
> uglyness
> to it.  My proffered solution would be to remove
TEXT_COMPOUND_DELIMITER
> completely and instead use TEXT_COMPOUND_ID as a soft
reference to the 
> Element. 

I will look at how the new TEXT_COMPOUND_ID as a replacement
for
TEXT_COMPOUND_DELIMITER.

Regards
Tonny Kohar
-- 
Sketsa 
SVG Graphics Editor
http://www.kiyut.com


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Hi Tonny,

Tonny Kohar <tonnykiyut.com> wrote on 03/26/2006 09:29:12
PM:

> On Sun, 2006-03-26 at 10:11 -0500, thomas.deweesekodak.com
wrote:
> > Hi all,
> > 
> >    I am curious to hear how/if people are using 
TEXT_COMPOUND_DELIMITER.
> 
> I am heavy usage on TEXT_COMPOUND_DELIMITER. It is used
in our inline
> editing Text Editor Component.

   I figured there were users out there.

> >    The solution I committed is maximally backwards
compatible but has 
some 
> > ugliness to it.  My preferred solution would be to
remove 
TEXT_COMPOUND_DELIMITER
> > completely and instead use TEXT_COMPOUND_ID as a
soft reference to the 

> > Element. 
> 
> I will look at how the new TEXT_COMPOUND_ID as a
replacement for
> TEXT_COMPOUND_DELIMITER.

   Just to be clear TEXT_COMPOUND_ID is currently just a
'new Object()'. 
So this would be a small additional change to make
TEXT_COMPOUND_ID a 
soft reference. As long as you currently always build your
documents 
as dynamic the change should be as simple as:

        Element e;
        e =
(Element)aci.getAttribute(TEXT_COMPOUND_DELIMITER);

With:
        e = 
(Element)((SoftReference)aci.getAttribute(TEXT_COMPOUND_ID))
.get();

   As the soft reference should never go to GC since the DOM
will be held 
by
the Canvas (and a million other references) in the Dynamic
case.

   The advantage of the current code is that it allows the
document to
go to GC for static documents w/o any impact on users code. 
The proposed 
change
is a minimally impactful change, but a change none the less.


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Hi,

On Sun, 2006-03-26 at 22:14 -0500, thomas.deweesekodak.com
wrote:
> > >    The solution I committed is maximally
backwards compatible but has 
> some 
> > > ugliness to it.  My preferred solution would
be to remove 
> TEXT_COMPOUND_DELIMITER
> > > completely and instead use TEXT_COMPOUND_ID
as a soft reference to the 
> > Element. 
> > 

It is no problem if you completely remove
TEXT_COMPOUND_DELIMITER and
use another methods either backward or not backward
compatible. We will
adjust our code accordingly, we just hope that the new
methods allow
similar capability and if possible more flexible 

Regards
Tonny Kohar
-- 
Sketsa 
SVG Graphics Editor
http://www.kiyut.com


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org