Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose internal IceChangeEditor instance in TinyMCE plugin #23

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

benesch
Copy link
Contributor

@benesch benesch commented Aug 3, 2012

Added a command to TinyMCE (via existing ice plugin) to expose the
internal IceChangeEditor to allow plugins and external code access to
the ice API.

Added a command to TinyMCE (via existing ice plugin) to expose the
internal IceChangeEditor to allow plugins and external code access to
the ice API.
@delambo
Copy link
Member

delambo commented Aug 16, 2012

Thanks, @primatology. I would like to keep the ice instance encapsulated in the editor plugin and then expose its api through tinymce's command interface.

Instead, can you put together a pull request adding any functions you need using the tinymce command interface?

@benesch benesch mentioned this pull request Nov 13, 2012
@benesch
Copy link
Contributor Author

benesch commented Nov 13, 2012

@delambo, fair enough. In my current implementation, I need access to pluginsManager.usePlugins(...). How do you feel about a new editor command, 'ice_useplugins', that simply wraps the method?

Or do you envision a different method of injecting methods into the TinyMCE ice instance? I haven't looked at the codebase in two months, so forgive me if there've been updates.

@delambo
Copy link
Member

delambo commented Nov 13, 2012

Ah, I see what you're trying to do now. I think a second option might be to allow a plugins configuration in the tinymce ice config that would take a set of plugins and would mix it in with the set of plugins that are initialized in the initializeice command.

Configuration might be a better approach so that you can avoid having to use callbacks; although, I can see both approaches as being practical since a user may want to add a plugin set sometime after init. Feel free to take on whatever suits your needs or both options. Thanks.

@johanneswilm
Copy link
Contributor

Hey @benesch : Is this still beign worked on or have you given up?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants