W3C Range specification implemented in GWT

[mflorea]

Hi there,

Do you plan extending the current Selection support? I'm interested in
a full implementation of the W3C Range specification. Wrapping the
Mozilla Range from JavaScript in GWT is easy. The difficult part is to
implement the specification using InternetExplorer's own TextRange
API. Do you work or plan to work on this in the near future?

Thanks,
Marius

[mflorea]

[mP]

IE selection should work - all the code is there.. try the demo.

[mflorea]

First of all, thanks for taking the time to reply to my post.

I did looked over your code before posting here. As I said, I'm
interested in a full implementation of the W3C Range specification, or
something as flexible. I think your current selection support is
limited. For instance, in the following method:

//
rocket.selection.client.support.SelectionSupport#getStart(Selection)
public SelectionEndPoint getStart(final Selection selection) {

final SelectionEndPoint start = new SelectionEndPoint();

start.setTextNode((Text) JavaScript.getObject(selection,
Constants.ANCHOR_NODE).cast());

start.setOffset(JavaScript.getInteger(selection,
Constants.ANCHOR_OFFSET));

return start;

}

you expect the anchor node to be a text node, but AFAIK this is not
always the case (in Firefox at least). That's why I asked if you plan
on extending the current selection support. To do this for Firefox is
easy. The hard part is doing it for IE. Maybe that's why you kept the
API simple; IE seems to support only text ranges, hmmm..

Regards,
Marius

[Miroslav Pokorny]

On Wed, Oct 8, 2008 at 7:14 AM, mflorea <zmeu...@gmail.com> wrote:

First of all, thanks for taking the time to reply to my post.

I did looked over your code before posting here. As I said, I'm
interested in a full implementation of the W3C Range specification, or
something as flexible. I think your current selection support is
limited. For instance, in the following method:

Most of the w3c range stuff isnt exactly needed - what stuff do you need that is missing ? Like you mention below IE doesnt even attempt to use w3c iinterfaces but has its own nasty ambomination.
 

//
rocket.selection.client.support.SelectionSupport#getStart(Selection)
public SelectionEndPoint getStart(final Selection selection) {

 final SelectionEndPoint start = new SelectionEndPoint();

 start.setTextNode((Text) JavaScript.getObject(selection,
Constants.ANCHOR_NODE).cast());

 start.setOffset(JavaScript.getInteger(selection,
Constants.ANCHOR_OFFSET));

 return start;

}

you expect the anchor node to be a text node, but AFAIK this is not
always the case (in Firefox at least). That's why I asked if you plan
on extending the current selection support. To do this for Firefox is
easy. The hard part is doing it for IE. Maybe that's why you kept the
API simple; IE seems to support only text ranges, hmmm..

This is true, the api had to be simplified to make sense for the lowest common denominator, there are some concepts that dont translate to all browsers.

Afaik textnodes are always the end point for selections even in FF.
 

Regards,
Marius

On Oct 7, 12:42 pm, mP <miroslav.poko...@gmail.com> wrote:
> IE selection should work - all the code is there.. try the demo.
>
> On 7 Oct, 18:43, mflorea <zmeuld...@gmail.com> wrote:
>
> > Hi there,
>
> > Do you plan extending the current Selection support? I'm interested in
> > a full implementation of the W3C Range specification. Wrapping the
> > Mozilla Range from JavaScript in GWT is easy. The difficult part is to
> > implement the specification using InternetExplorer's own TextRange
> > API. Do you work or plan to work on this in the near future?
>
> > Thanks,
> > Marius

--
mP

[mflorea]

On Oct 8, 12:21 am, "Miroslav Pokorny" <miroslav.poko...@gmail.com>
wrote:

> On Wed, Oct 8, 2008 at 7:14 AM, mflorea <zmeuld...@gmail.com> wrote:
>
> > First of all, thanks for taking the time to reply to my post.
>
> > I did looked over your code before posting here. As I said, I'm
> > interested in a full implementation of the W3C Range specification, or
> > something as flexible. I think your current selection support is
> > limited. For instance, in the following method:
>
> Most of the w3c range stuff isnt exactly needed - what stuff do you need
> that is missing ? Like you mention below IE doesnt even attempt to use w3c
> iinterfaces but has its own nasty ambomination.

I need the selection to write (yet another) WYSIWYG editor on top of
GWT. It will replace eventually the current WYSIWYG editor in XWiki,
namely TinyMCE.

>
>
>
>
>
> > //
> > rocket.selection.client.support.SelectionSupport#getStart(Selection)
> > public SelectionEndPoint getStart(final Selection selection) {
>
> >  final SelectionEndPoint start = new SelectionEndPoint();
>
> >  start.setTextNode((Text) JavaScript.getObject(selection,
> > Constants.ANCHOR_NODE).cast());
>
> >  start.setOffset(JavaScript.getInteger(selection,
> > Constants.ANCHOR_OFFSET));
>
> >  return start;
>
> > }
>
> > you expect the anchor node to be a text node, but AFAIK this is not
> > always the case (in Firefox at least). That's why I asked if you plan
> > on extending the current selection support. To do this for Firefox is
> > easy. The hard part is doing it for IE. Maybe that's why you kept the
> > API simple; IE seems to support only text ranges, hmmm..
>
> This is true, the api had to be simplified to make sense for the lowest
> common denominator, there are some concepts that dont translate to all
> browsers.
>
> Afaik textnodes are always the end point for selections even in FF.

When using designMode / contentEditable the selection becomes more
complex. I've made a small demo to see the selection in different
situations: http://students.info.uaic.ro/~mflorea/zzz/selection.html .
The code is here http://rafb.net/p/yLk66916.html in case the server is
down. As you can see, in Firefox the selection anchor can be a DOM
element, while in IE there is the control range in case you select an
'object' like an image (with two successive clicks..).

[Miroslav Pokorny]

I had a quick look at your demo, im not really sure what its trying to show / perform...

On Wed, Oct 8, 2008 at 11:48 PM, mflorea <zmeu...@gmail.com> wrote:

On Oct 8, 12:21 am, "Miroslav Pokorny" <miroslav.poko...@gmail.com>
wrote:

> On Wed, Oct 8, 2008 at 7:14 AM, mflorea <zmeuld...@gmail.com> wrote:
>
> > First of all, thanks for taking the time to reply to my post.
>
> > I did looked over your code before posting here. As I said, I'm
> > interested in a full implementation of the W3C Range specification, or
> > something as flexible. I think your current selection support is
> > limited. For instance, in the following method:
>
> Most of the w3c range stuff isnt exactly needed - what stuff do you need
> that is missing ? Like you mention below IE doesnt even attempt to use w3c
> iinterfaces but has its own nasty ambomination.

I need the selection to write (yet another) WYSIWYG editor on top of
GWT. It will replace eventually the current WYSIWYG editor in XWiki,
namely TinyMCE.

 Which functionality do you need - thats missing ? Can you list the w3c object/method and perhaps give an example...

--
mP

[mflorea]

On Oct 8, 11:38 pm, "Miroslav Pokorny" <miroslav.poko...@gmail.com>
wrote:

> I had a quick look at your demo, im not really sure what its trying to show
> / perform...

This small demo is supposed to show selection properties in different
situations. After each click or key typed in the 'text area' (an
inline frame actually, whose content document has been made editable)
selection properties are updated below (considering the cursor a
collapsed selection, marking a position inside the document). Below
the selection properties, separated by an horizontal rule, you can see
the properties of the first range in the selection (normally, unless
you use Ctrl key on Firefox, the selection contains just one range).
This demo simulates the usage of RichTextArea from GWT, which is based
on the same mechanism: making the content document of an inline frame
editable.

I'd like to point out three use cases:

A) Open the page in Firefox. Click on the first, empty, line. As a
consequence the cursor will be positioned inside a paragraph with no
text child nodes. The anchor node of the selection will be the
paragraph element. What will be the selection retrieved with your API?

B) Open the page in Firefox. Click inside the non-empty line. Type any
character. Select all text, with Ctrl+A, and delete. As a consequence
the cursor will be positioned inside the body element, which has only
one child, a br element. What will be the selection retrieved with
your API?

C) Open the page in Firefox or IE. Click on the image icon (in IE
click twice, successively). The image has been selected (the cursor
has disappeared). Same question, what will be the selection retrieved
with you API?

>
>
>
> On Wed, Oct 8, 2008 at 11:48 PM, mflorea <zmeuld...@gmail.com> wrote:
>
> > On Oct 8, 12:21 am, "Miroslav Pokorny" <miroslav.poko...@gmail.com>
> > wrote:
> > > On Wed, Oct 8, 2008 at 7:14 AM, mflorea <zmeuld...@gmail.com> wrote:
>
> > > > First of all, thanks for taking the time to reply to my post.
>
> > > > I did looked over your code before posting here. As I said, I'm
> > > > interested in a full implementation of the W3C Range specification, or
> > > > something as flexible. I think your current selection support is
> > > > limited. For instance, in the following method:
>
> > > Most of the w3c range stuff isnt exactly needed - what stuff do you need
> > > that is missing ? Like you mention below IE doesnt even attempt to use
> > w3c
> > > iinterfaces but has its own nasty ambomination.
>
> > I need the selection to write (yet another) WYSIWYG editor on top of
> > GWT. It will replace eventually the current WYSIWYG editor in XWiki,
> > namely TinyMCE.
>
> Which functionality do you need - thats missing ? Can you list the w3c
> object/method and perhaps give an example...

What I'm missing is the support for non-text selection. In the w3c
specification the boundary points of the selection can be element
nodes as well. My question is: can you convert any type of selection
to a text selection? In all of the three use cases described above you
don't have a text selection.

Thanks again for your time!

>
>
>
>
>
> > > > //
> > > > rocket.selection.client.support.SelectionSupport#getStart(Selection)
> > > > public SelectionEndPoint getStart(final Selection selection) {
>
> > > > final SelectionEndPoint start = new SelectionEndPoint();
>
> > > > start.setTextNode((Text) JavaScript.getObject(selection,
> > > > Constants.ANCHOR_NODE).cast());
>
> > > > start.setOffset(JavaScript.getInteger(selection,
> > > > Constants.ANCHOR_OFFSET));
>
> > > > return start;
>
> > > > }
>
> > > > you expect the anchor node to be a text node, but AFAIK this is not
> > > > always the case (in Firefox at least). That's why I asked if you plan
> > > > on extending the current selection support. To do this for Firefox is
> > > > easy. The hard part is doing it for IE. Maybe that's why you kept the
> > > > API simple; IE seems to support only text ranges, hmmm..
>
> > > This is true, the api had to be simplified to make sense for the lowest
> > > common denominator, there are some concepts that dont translate to all
> > > browsers.
>
> > > Afaik textnodes are always the end point for selections even in FF.
>
> > When using designMode / contentEditable the selection becomes more
> > complex. I've made a small demo to see the selection in different

> > situations:http://students.info.uaic.ro/~mflorea/zzz/selection.html<http://students.info.uaic.ro/%7Emflorea/zzz/selection.html>.
> > The code is herehttp://rafb.net/p/yLk66916.htmlin case the server is

[Miroslav Pokorny]

I am not exavtly sure and cant give a definitive answer. The best way
to answer your questions is to alter the demo to match your scenarios
and try it out. it should not take more them a few mins to do the java.

Sent from my iPhone

[Miroslav Pokorny]

Re: I am guessing even though the signature might have the wrong
return type. In the case of the selected item being an element the
returned type shouldl be an element and not a textnode.

Sent from my iPhone

On 10/10/2008, at 1:17 AM, mflorea <zmeu...@gmail.com> wrote: