davidosullivan

I think its deliberate looking at the notes in blockmanager.js… I’ll be digging into the block plugin alot over the next couple of days

So yeah I think what you have done with the editor buttons in 2.3 works a treat 🙂

Going back to the original subject of the thread though since there are still some more things I need to do to the form once it is loaded, is it possible to have an ‘edit_ready’ trigger to bind to?

I can bind to “edit_start”:-
jQuery(document).bind(“edit_start”, function(){
//do whatever
})
It would be really great if I could bind to something that triggered when the content has been retrieved from ajax and added into the form:-
jQuery(document).bind(“edit_ready”, function(){
//do whatever
})
Any chance of that?

I have tracked it down to being something to do with the block plugin in the new aloha build actually- at lib/aloha-editor/plugins/common/block- if I use the block plugin from fee 2.2 jQ UI draggable works again… Will look into it more, but its off topic now…

Also am having issues with jQuery UI draggable in this new version with the save/cancel buttons- I am not sure if this is down to those changes or the new version of Aloha…

What I am doing is making images editable in various ways when the editor is in editing mode. One of the things I do is initialise draggable on click on the image which enables the image to be able to be dragged around inside its own container.

This was working in FEE 2.2 but in this new version the drag is not working. If I bind an alert to the dragstart event on the image that shows up- but the actual jQuery ui ‘drag’ event seems to be being blocked.

Any idea why that may be?

Hmm, had a look at CoffeeScript. I think it would be a good idea for me to learn it but just don’t think I can right now… I take it that you’d like me to have a go at writing the changes in Coffee script so you can compile them into the output your end is that right?

I think it should be a pretty straight forward change though actually- couldn’t we just include the buttons in the markup and hide them- then show them on start_editing (maybe with a little timeout unless we can make them show when the fee-form is loaded) and bind a click function that triggers a click on the aloha buttons?

Basically its because I think that the user may well expect to see save/cancel buttons in the same place as they saw the ‘edit’ button- specifically if you have for example inserted an image and the save cancel buttons are not visible in that ‘insert’ tab. Also if you have large images at the top of your post quite often the editor goes off screen untill you click on text below- in which case you cant see what to do to get out of the mode. If there were save/cancel buttons following you down the post this would all be obvious to the user.

The way I was planning on doing it to avoid the problem you mention is to clone the buttons from the editor (which should also carry over their functionality) and insert them into the edit button itself and give that button a different class at the same time which would make them show correctly.

Thats why I need to bind to the stage ready event or something so that I know when the editor and its buttons and the fee-form are all ready to go…

Really hope this is something you have some ideas about as I really think it will have big usability benefits…