looks a heck of a lot like
http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsICommandHandler.idl
which adam lock threw together.
Simon Fraser wrote:
> Are we expecting embedders to talk directly to nsIControllers?
depends :-/. we haven't defined a strict rule yet. we're handling it on
a case-by-case basis.
> The reason I ask is that we're trying to nail down the emebedding
> APIs that the editor will use. We'd like to avoid duplicating
> functionality in different interfaces, and, in addition, protecting
> the emebedder from the low-level editor APIs.
perfect!
> One way to do this would be to put a lot of functionality into
> commands, which can be gotten at and executed using nsIControllers.
Right, see my previous posting titled "nsIClipboardCommands" for
discussion regarding the "lines".
> The embedder would have to then do something equivalent to
>
> var controller =
> top.document.commandDispatcher.getControllerForCommand(command);
>
> if ( controller && controller.isCommandEnabled(command))
> controller.doCommand(command);
>
> to execute a command. Getting command state would be similar.
>
> The alternative would be for editor to provide a 'spoon-feeding'
> interface that gives the embedder an easy-to-use way of doing
> common editor operations. The command implememtations could
> then call this, or lower-level APIs.
Right now we're using the spoon feeding approach.
> A related question is what happens with commands that need to
> throw up UI, like Save and Open? Are we expecting the emebedder
> to implement the file picker APIs to get their own UI?
IMO, an embeddor should be able to say something->Save(); if they pass
in an arg, it's the file location to save to, if they don't then we
throw UI (if we're packaged w/ the UI). same w/ something->Open().
> And who should have the task of throwing these dialogs -- the embedder,
> or composer?
How's this for an answer; both :-). We'd like to beable to provide a
UIless experience, as well as one where the embeddor could rely on us
for UI.
Jud
