Closed bfintal closed 9 years ago
I think a ContentEdit.Div
might be too generic as you don't know what a <div>
will contain or what the behaviour of the contents should be, in the case you've presented above I think I'd resort to multiple regions, along the lines of:
<div class"main">
<div data-editable="main-upper">
<p>....</p>
</div>
<div data-editable="main-lower">
<p>...</p>
</div>
</div>
Elements can be dragged between multiple regions and you can move the cursor between them.
If you did want to create an editable element specifically for the case in point I think it would be better to require that a data-ce-tag="new-element-type"
was used to point to a new element type rather than capture the behaviour of all <div>
tags.
Having said all of that I'm not 100% confident I understand the problem you're trying to solve, so if I've misunderstood apologies in advance, if you can provide another use case I'll happily review.
Here's a bit of background: in a nutshell I'm trying to integrate it with WordPress in such a way that ContentTools will be the content editor while in the frontend of a site. The two major hurdles are 1) you don't really know what content will be there.. any content should be editable and any content can be inserted into the editor. The next hurdle is 2) parts of the content are rendered HTML or shortcodes, and these should not be editable - you also don't know what will be contained in these. I've got second hurdle pinned down by filtering these out and using your new movable static attribute.
Right now I'm testing various scenarios for the first hurdle, like having divs inside the content which should be editable. I'm using a single editor to make things simpler, since if each div would be turned into an editor, letting users add divs in then initializing those too can make things complicated.
For example, if I have this:
What's the best way to enable editing the contents of the div without resorting to multiple editors? Multiple editors would (might) prevent drag and dropping from different editors and would complicate things with multiple inits, etc.
Related: #13
Currently, divs are automatically made static, and so the contents aren't editable anymore. Is there any limitation on why they're automatically made static?Digging through the code, I noticed that divs are not included in
_tagName
so they're automatically made static. And since their behavior is different from normal text (e.g. hitting enter shouldn't create another div/element), adding divs to the existingContentEdit.Text
handlers won't work. I tried it and it somewhat works except for the example I just mentioned.I think the best approach might be to extend ContentEdit.Text to create ContentEdit.Div for handling divs.