Migrate to WellBehavedFX's InputMapTemplate & InputMap approach

[JordanMartinez]

No description provided.

[TomasMikula]

Cool, thanks!

[TomasMikula]

I updated the snapshot so that people can play with this.

[JordanMartinez]

I updated the snapshot so that people can play with this.

Cool.

We should also include some sort of guide to help them migrate their code as well. Otherwise, those unfamiliar with your library who come upon it now might screw up the behavior when they try to set a different EventHandler on the area's on[EventType]Property() and then start a new (or duplicate) issue...
However, should that be done in RTFX? Or demonstrated in WBFX with a link to that page in RTFX somewhere?

[TomasMikula]

The nice thing about this new experimental package is that it doesn't use the on[EventType]... properties, but only Node#addEventHandler(...). So by setting some on[EventType]Property they don't remove the handlers installed by StyledTextArea.

If, however, they try to override the default behavior by setting some on[EventType]Property, that will likely result in both handlers being invoked. This problem, however, exists independently of WellBehavedFX.

[TomasMikula]

Though I agree that overriding event handlers should be documented somewhere.

[JordanMartinez]

The nice thing about this new experimental package is that it doesn't use the on[EventType]... properties, but only Node#addEventHandler(...). So by setting some on[EventType]Property they don't remove the handlers installed by StyledTextArea.

That's actually kind of cool.

If, however, they try to override the default behavior by setting some on[EventType]Property, that will likely result in both handlers being invoked. This problem, however, exists independently of WellBehavedFX.

Though I agree that overriding event handlers should be documented somewhere.

So it seems we should document it in RTFX....

Perhaps we should take the following approach:

• Update the ReadMe, as we have discussed previously, to show that the three flavors all extend StyledTextArea (and thus many more readers will start there).
• Write the javadoc in StyledTextArea that shows how to override the handlers, warns the user about using the on[EventType] properties, and provides a link to the source code of StyledTextAreaBehavior to give a general example of how to use the new package. This link might save us the time and energy it would take to write a guide showing how to use the new experimental package (which I guess won't be experimental for long).
• Optionally, we could also write a small demo that shows some of this as well.

[TomasMikula]

All sound good. I prefer compiler-checked documentation (like demo app) whenever possible, since it is easy for other forms to get outdated without noticing.

[JordanMartinez]

All sound good. I prefer compiler-checked documentation (like demo app) whenever possible, since it is easy for other forms to get outdated without noticing.

True. How about you update the ReadMe? Besides the above, InlineStyledTextArea is deprecated, but most of what it says could still cross over to StyledTextArea and that section.
I can create an app that demonstrates the first two parts of the javadoc and has a link in it that opens up the user's web browser to StyledTextAreaBehavior's code.
This approach might be better overall than even writing the javadoc itself.

[TomasMikula]

Sounds good. Let's update the README once we are ready to release 0.7.