git-j / hallo Goto Github PK

the default implementation of replaceSelection is insufficent for enhancing the content with complex html:

hallo [selected] world
should get
hallo

a second implementation of replaceSelection has to be provided

In certain situations the hallojs editor component gets unusable over time. over time means with multiple invocations on the same dom-tree.
the situation for my application is

a list, that the user can select from
a editor div that contains the data displayed/modified to the user

when a list-item is clicked, the editor-div is filled with the data associated to the list and the editor has to be configured to be minimal (undo/redo only) or full (with more plugins)

essentially hallo() is called multiple times on the same dom-node:

for (i=0;i<100;i++)
  $('#editordiv').hallo(myconfiguration);

after this, the editor component is painfully slow, it takes multiple seconds for a single typed character to appear

the current work-arround is to remove the node that hallo uses before reassigning the new configuration

for (i=0;i<100;i++){
  var parent = $('#editordiv').parent();
  $('#editordiv').remove();
  parent.append('<div id="editordiv"></div>');
  $('#editordiv').hallo(myconfiguration);
}

please review
https://github.com/git-j/hallo/blob/master/examples/test_multiuse.html

The use of coffeescript is unintuitive and makes no sense with a js-centered development stack (eg node.js - express - backbone - jquery) introducing the coffeescript dependency makes the code hard to maintain without a correct build environment. The only advantage of coffee as the source-language is that it enforces a javascript-style that can be considered consistent.

this would require the following steps:

• cake build the latest source
• copy all documentation from coffee into the output javascript
• split up the output javascript into multiple files
• implement unit tests
• implement code style enforcement
• use requirejs or amd for loading the multiple files
• use uglify/minify/concat grunt rules to build a 'production.js'

optimistic ETA: 32hrs, pessimistic ETA*3

the approach using fontawesome is nice. when integrating hallojs into other tools it might be desireable to change the icons for the plugins on a global level. currently its hacking every plugin

with the usecase that say 100+ contentEditable widgets are on a page, a lot of resources are used for 100+ identical toolbars:

for(i=0;i<1000;i++) html+='<div class="ce">' + i + '</div>';
$('body').html(html);
$('.ce').hallo(default_config);
debug.log('toolbar-count:'$('.hallotoolbar').length);
// > 1000

and for the widgets:

var dialog_count = 0;
$('div').each(function(index,item){
  if ( $(item).attr('id').indexOf('-dialog')>0 )
   dialog_count++;
});
debug.log('dialog-widgets:' + dialog_count);
// depends on config, eg image+link: 2000

this can be 'solved' with
$('.ce').bind('mouseenter',function(ev){$(ev.target).hallo(config);}
... of course more complex

when creating menu-dropdowns it may be necessary to generate them based on the current edited content. therefore there has to be the possibility to update the items in the drop-list

when plugins insert / update the html of the contentEditable the hallomodified event has to be triggered

in a editor component configured with a placeholder that disappears when entering the editable, the caret does not always appear in the editable. this requires the user to click a second time.
this issue does not occur in recent chrome implementations but in the webkit version for qt 4.8

research pointed out this related issue:
http://stackoverflow.com/questions/4063144/setting-the-caret-position-to-an-empty-node-inside-a-contenteditable-element

and this proposed solution:
http://stackoverflow.com/questions/3805852/select-all-text-in-contenteditable-div-when-it-focus-click

requires the deactivate & turnOn implementations to handle the issue

enable a 'store_callback' that is called each time the content has changed and the focus is lost (hallodeactivated)

This fork of Hallo seems to have a lot more features than the master (as well as being more actively maintained), however there is no clear prebuilt JS file and no dependency information - i.e the cite plugin seems to fail (because ICiteProc is not defined).

when making small items contenteditable, the toolbar behaves strangely and displays its buttons vertical rather than horizontal

the toolbar width somehow inherits the width of the editable. this shouldn't be default, when the toolbar is fixed

content
$('span').hallo(many_plugins)

expect
[toolbar in horizontal]
[span]

get
[tool
bar
in h
oriz
onta
l]
[span]