Well - in case anybody is interested - things can be setup by catching
any ongoing Trinidad PPR request by using addStateChangeListener and
then killing all existing Timymce editors.
The tricky point is that any returning page part might not involve
existing editors at all (for example, expanding a tr:tree node) - thus
surviving editors must be recreated at PPR completion (same listener).
This strategy seems working well for all cases when PPR returns with
same/more/less editor areas than page had before.
The only drawback is about some heavy flickering due to turning off/on
editors of surviving areas. I tried to kill lost editors during PPR
response processing, but this raises Tinymce exceptions - likely because
Dom changed. I will try to post some how-to on the Tinymce list.
-- Renzo
Renzo Tomaselli wrote:
Hi, I wonder if anybody succeeded in doing this. In general, for full
page refreshing it works fine.
But it does not with Trinidad PPR when rendered region contains (or
misses) involved Tinymce textareas. There are two main effects:
- PPR does not complete (FF appears waiting from something more from
the server), but rendering seems to complete.
- js exceptions thrown while processing onsubmit.
The former occurs even the very first time, when PPR renders a region
containing a Tinymce textarea which was not there before PPR.
The latter occurs even when the involved textarea is not anymore on
the page. It appears that Tinymce cannot detect that its area has been
kicked off across a PPR cycle, thus any following submit goes through
some inconsistent processing since caught. No more submit succeeds.
Glad to hear any story about this - it's really a pity that such a
nice stuff cannot work together with Trinidad, being a pure js machinery.
-- Renzo
