[
https://issues.apache.org/jira/browse/CLK-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871081#action_12871081
]
Bob Schellink commented on CLK-658:
-----------------------------------
> Yes, it's using jQuery, but I think Click should use jQuery instead of
> Prototype where possible.
Click should do no such thing. For the good of the framework Click should be JS
agnostic. The moment you pick sides on JS technologies you simply dig an early
grave since JS technologies are not compatible with each other and market share
is quite volatile. The rate at which these libraries (or plugins) are created
and abandoned is amazing.
I'm repeating myself as I've said this many times before but the moment we ship
a new control we have to support it. Potentially forever. If someone deploys
Click into Websphere over HTTPS and it fails because of some jQuery plugin we
ship, its our responsibility to provide a solution.
For the majority of JS centric controls I think they should be pushed into
third party projects hosted elsewhere.
> WYSIWYM (not WYSIWYG) Editor in click-extras or at least click-examples.
> ------------------------------------------------------------------------
>
> Key: CLK-658
> URL: https://issues.apache.org/jira/browse/CLK-658
> Project: Click
> Issue Type: New Feature
> Components: examples, extras
> Reporter: George Stan
>
> Add a WYSIWYM (not WYSIWYG) editor control to Click Extras (or at least
> Click-examples):
> http://en.wikipedia.org/wiki/WYSIWYM
> For many usage scenarios, it holds much better results than a WYSIWYG (this
> was my experience too), so in many cases when
> a TextArea is used, a Click WYSIWYM Editor would have much better results.
> http://www.wymeditor.org/ would be one possible solution (and it has MIT
> license too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
