click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <>
Subject [jira] Commented: (CLK-658) WYSIWYM (not WYSIWYG) Editor in click-extras or at least click-examples.
Date Tue, 25 May 2010 10:14:24 GMT


Bob Schellink commented on CLK-658:

> Yes, it's using jQuery, but I think Click should use jQuery instead of Prototype where

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:
>             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):
> 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.
> 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.

View raw message