I just upgraded the inputHtml component to use Kupu 1.3rc3 (with some patches).
I did some tests with their multi-editors version, but unfortunately, this isn't what we need. The multi editor is really an editor with several iframes instead of the single iframe from the normal editor. So all the editors are at the same place, and they all share the same button bar, editable space, ...
So we need to improve the standard editor.
The Kupu code has improved in that respect since 1.2, but it still relies on some hard coded ids that we need to get ride of.
We have to help the Kupu team to do this, but I suspect the interest on their side isn't so high as they mainly use it in plone, lenya, ... all products that use only one editor full page.
And I won't have time in the next weeks (months?) to patch Kupu
I integrated some code in myFaces's version to prepare this job, but it's far from finished.
Best regards,
Sylvain.
On Wed, 2005-08-03 at 18:03 +0200, Christian Egli wrote:
Hi Sylvain Thanks for your answer. Sylvain Vieujot <[EMAIL PROTECTED]> writes: > On Tue, 2005-08-02 at 17:09 +0200, Christian Egli wrote: > > > I would like to have a series of <x:inputHtml/> on one single > > page. Now the docu for x:inputHtml says that "right now the support is > > limited to one editor per page". > > > > What is the reason that there is only support for one editor > This is a limitation of the kupu code. > If you want to help lift this limitation, you should look at kupu itself > ( http://kupu.oscom.org/ ), and once it works with kupu, it souldn't be > very hard to adjust myFaces. I talked to the guys on irc and they claim that kupu can handle more than one instance just fine. Apparently plone is making use of this facility. From what I gather the problem lies in the initialization code. Apparently kupu/plone/kupu_plone_layer/kupuploneinit.js does it right. MyFaces apparently is using kupu/common/kupuinit.js. You would probably know better.
