add and remove mooRTE instances

[frozeman]

hi,

how can i add or remove an instance in moorte?
i would like to disable and enable the frontend editing in feindura
cms, so i have to remove the moorte editing and add it again, if
possible...

fabian

[SamGoody]

The way it's supposed to work is:

The element's moorte method accepts an optional parameter [hide/remove/
destroy]

Usage:

var el = $('myElement');

el.moorte() - adds the Rich Text Editor if not already present. Shows
it if hidden. Restores it if removed.

el.moorte('hide') - Hides the Rich Text Editor. Does not remove it.

el.moorte('remove') - removes the Rich Text Editor, but stores a
reference to it in memory.

el.moorte('destroys') - removes and garbage collects the Rich Text
Editor.


However, things seem to have broken some point recently. Will try to
get this pushed by today (half an hour till second period begins and
I've gotta teach!!)

[SamGoody]

Actually, things are working mostly.

While there is a bug or two, most of the tests seem to return OK.
Would you mind testing (ideally with the latest version from the
develop branch)?

Tell me if it works, or what about it has issues, and I'll call the
Orkin man.

Sam

[frozeman]

i will give it a try when i find time,right now university is keeping
me from doing anything on feindura.

so basicly i forst run
MooRTE('.fenduraEdit',{options:value});

and later i can do

$$('.feinduraEdit').each(function(feindurEdit){
feinduraEdit.moorte('hide');
});


is that right?
fabian

[frozeman]

ok i tried it, but it only removes the moorte bar, but i need to
deactivate the edit function at all and then to activate it again.

how do i do that?

fabian

[SamGoody]

The request you make is valid, and I would like some input from the
community to find out what is desired.

Up till now I assumed that if you wanted to remove the RTE entirely,
even temporarily, you would destroy it and recreate it when needed.
To that end, there is a element.moorte('destroy') method.

The moorte('remove') method was only for removing the element
superficially. This was useful for the XSS cleaning.
We would remove the RTE, clean the input, and restore the RTE, without
ever messing with the editability of the element.

On the request of this thread I've changed it so that when the RTE is
removed - even if it stays in memory, the element loses all of it's
editibiliy.
Is there anyone else who disagrees with Fabian on this?

Which brings up the handling of events.
MooRTE adds a number of events to the editable element. Ctrl+B will
make selected text bold, etc.
A LOT of attention was given to limit the number of events the
browsers must deal with. All key checks are combined, etc.

Nonetheless, there are still a few events that were required.
If these events are kept on the element, it will remain editable -
which is undesired.
Currently (in develop) it just copies the events to another element,
and removes all events.
But that can leave a possibility where someone has added their own
events to an element, which will be beaned when running
moorte('remove')

So we can leave the events, but have them not fire if the event is non-
editable. This will add imperceptible overhead, but should be fine
otherwise.
Or we can try to cycle through the events that the RTE has added.

Or we can leave the code as is, because who really will ever run into
an issue from this.

Thinking out loud here, but always open to input from the fine coders
I am honored to have as readers of the forum.

[Fabian]

"who really will ever run into

an issue from this."

Sadly i do :-(

When I call moorte("destroy") he also removes all my events. It would be good if destroy and remove only removes the moorte events and bring them back when restored or newly created.

At least that would be the behavior I would expect. If you only deactivate them, it's create maybe an unnecessary overload in events in the browser. 

Another problem

I discovered, is that when I destroy moorte and add a new one to the same field. He adds me line breaks or the element eg a <h1> again so that I get a newline everytime I destroy and add a new moorte instance to the same element. 

Greetz

Fabian

Von meinem iPhone gesendet

[SamGoody]

Point accepted.

Planning on redoing the logic of groups, then working on this.

[frozeman]

because of the text he add to the fields, which had moorte and get
newly add with MooRTE('...',{....});
(and before i removed it with moorte('destroy');)

it adds these lines on the end:

<p>
&nbsp;</p>
<p id="rteMozFix">
&nbsp;</p>

always when i destroy and create it again, which is kind of
annoying :-)
could you check this..

does remove and create work now proberly, and he only remove the
events from moorte, not all?

greetz
fabian

[SamGoody]

Status update.

Have reworked the way that events are handled, things are now cleaner.
And events can be safely added and removed without affecting other
events that have been added.

Have also reworked the way that it replaces non-rte fiedls, such as
inputs and textareas.
It now replaces the actual element and stores a reference.
While this could technically be called a "leak" its no more intensive
then the last method of hiding the element - as long as when it is
restored it maintains the same link. Which it does.

Now for the next design decision.
Imagine that you've set up one toolbar to handle several elements,
including $('myEditableElement').
Now you run $('myEditableElement').moorte('remove') - which removes
the rte from that element.

Should it:
a. Leave the RTE Toolbar, leave other elements editable, but make $
('myEditableElement') uneditable.
b. Remove the RTE, and make all connected elements uneditable as well.

For now, I use the latter approach, but I'm not sure that it is
correct.
What do you all suggest?

Also, regarding your complaint about the extra <p><br></p> in Firefox
- this is added because of a number of bugs in Firefox.
I will look at stripping it out upon removal.

Any other thoughts?

[Fabian]

Super Tanks a Lot! Are the changes already online?

I would suggest "a"
Cause you only remove one element. Means you need still the toolbar. And the other elements should still be editable.

Lg
Fabian

Von meinem iPhone gesendet

[frozeman]

hi,

i tried today the new develop branch version. and activating still
isnt working.. means when i remove it he removes the rte but he didnt
bring it back on 'create'.
with the events that works now, moorte doesnt remove the events
anymore, which is better now! :-)

the only way i could make it work for now is when i destroy it an
create it completely new.

the only bug which exists the is that he add this

<p id="rteMozFix">
&nbsp;</p>

always when i create a new moorte instance on the field.
maybe its a css error, cause when i save he doesnt show me the
linebreak anymore and the

<p id="rteMozFix">
&nbsp;</p>

is gone, but when i create again new then its back again.


summary
- events work fine so far :-)
- create isnt working
- he adds the "rteMozFix"

lg
fabian

On 16 Feb., 17:15, Fabian <fab...@frozeman.de> wrote:
> Super Tanks a Lot! Are the changes already online?
>
> I would suggest "a"
> Cause you only remove one element. Means you need still the toolbar. And the other elements should still be editable.
>
> Lg
> Fabian
>
> Von meinem iPhone gesendet
>

[frozeman]

i remove now the
<p id="rteMozFix"><br>


</p>

automaticaly, but it still destroys my layout when the mooRTEFix is in
the divs i wanted to be editable...

is there a way that you can work without adding this <p> tag to the
editing area?


fabian

[SamGoody]

Time for an update, I see.

1.
Design decision: What should 'remove' do?
We've created a new option - 'detach', which detaches the element from
the RTE, but leaves the RTE in place for any other connected elements.

So here's the rundown:

Methods that modify the RTE:
el.moorte('destroy') - Destroys the RTE, makes all connected elements
non-editable.
A new RTE can be created afterwards, but that one is gooooone!
el.moorte('remove') - Removes the RTE, makes all connected elements
non-editable.
The RTE can be restored, and all elements reeditabled, by using
el.moorte();
el.moorte('hide') - hides the RTE. All elements remain editable, RTE
remains on the page with display:none;
The RTE can be made visible, by using el.moorte();

Methods that modify the element(s):
el.moorte('detach') - Detaches the element from the RTE. Makes element
non-editable, but leaves other elements editable.
The element can be reattached and made editable by using
el.moorte();

For all of these, no other arguments need be passed in, and the
moorte() function can be called on the element, on a collection of
elements.
In all but the last case the method can be called on the RTE itself.

In all cases, if a RTE is passed in, the element will be moved to the
passed in RTE.
In all cases, one can add whatever aliases will please them, as non-
recognised terms are ignored
moorte('restore'), moorte('show'), moorte('attach'),
moorte('antidisestablishmentarianism'), moorte("I'm a OpenBSD fanboi")
- These are all the same as moorte();

2.
Demo page:
Has been added to the demos section, called Removal.htm.
Check it out.
We are still debugging, but let us know if things do not work.

3.
I have not had the issues you've described above with the RTEFix
element.
Will debug some more, and see if I can catch it in the wild.

[SamGoody]

If someone would like to help write docs, it is sorely needed.

Thanks

[SamGoody]

A little on the MozRTEFix element.
Because, I do NOT understand your issue, Fabian.

Firefox is rife with lots and lots of contenteditable related bugs.
Many of them are so bad, they are show stoppers.

An example of a showstoppper is this:
If an element has no content, and is selected...Firefox throws an
error, and refuses to run any more scripts on the page.

An example of a major annoyance is that:
If a person presses blockqoute or list, the entire element moves,
instead of the cursor.

Now, up until Firefox version 3.6 we solved the above, and many
similar annoyances, by not using contenteditable for the above
commands.
Instead, when the element was selected or blockquote pressed, we would
move the ENTIRE PAGE into design mode, perform the action, and turn
design mode off.
This created a repaint which was not only slow, it was ugly, as all
links would lose all styling for an instant.
So we worked on minimizng the issues, and I really think we dig a good
job of hiding them.
Don't believe me? Go back and check the source.

In Firefox 3.6 the bugs became WORSE, and even putting the whole page
into design mode didn't help!!
Fortunately, someone else had worked out a solution. Add <p><br></p>
to the end of the element, and Firefox will work fine.

Which in turn created a new mess, as Firefox insists on putting the
cursor into that element.
Fixed by using the Selection and Range API's; a real headache.
Fortunately, there's a GREAT write up on those two API's over here:
http://blog.siteroller.net/understanding-javascript-selection-and-range
and http://blog.siteroller.net/understanding-the-js-range-object-part-2-home

Done, and now everything works.
That element is only added in Firefox, and when you remove the RTE, it
should remove that extra element.

So..... is the issue that the above element is not being removed, or
is there something else gone awry?
Any comments?

Sam

[Fabian [frozeman.de]]

what is the difference between "remove" and "detach"
when both are called on a specific element?

concerning the rtFix, the first problem is that is have an id, which is a problem when you have multiple editable areas, because you can set an specific id only ones. so you should call it class dont you?
second i adds a linebreak to all elements on the end, and when i call my selfmade save function (onBlur and save button press) i will have the content with the <p id="rteMozfix"><br></p>...

you could make the "rteMozfix"  with css alost invisible, but in my case its quite visible, i add some images to see.

lg

fabian

[frozeman]

hi

your latest commits fixed my errors, but i still wonder about the
id="rteMozFix", should it not be class="rteMozFix"?

because you can only have one id per page, and i have multiple
editable fields per page!

fabian

>  rteMozfix.png
> 1696KAnzeigenHerunterladen