[Why doesn't your reply show up on the embedding newsgroup?]
Adam Lock wrote:
>
> Simon Fraser wrote:
>
> > [Also posted on the embedding newsgroup. Follows there, please.]
> >
> > The way I have implemented this so far (and I have it working to
> > the extent that I can edit, and apply styles to documents in a
> > frameset, and in iframes) is to subclass webShell:
> >
> > nsDocShell
> > ^
> > |
> > nsWebShell
> > ^
> > |
> > nsEditorDocShell -- adds nsCOMPtr<nsIEditor> member
> > ^
> > |
> > nsEditingShell -- adds nsCOMPtr<nsIEditingSession> member
> >
>
> My concern with doing it this way is that it means someone who has a
> webbrowser instance in front of them cannot flip a switch and have it
> turn into an editor session and vice versa. It would be very cool to able
> do in-place editing like this rather than explicitly create either a web
> browser or editor up front and not be able to switch between them without
> great difficulty.
That's a good point; I didn't think of that. This inheritance approach
would still work if you always instantiated nsEditorDocShell/nsEditingShells
for any docShell that *might* become editable, but I'd then need some
runtime flags to say whether to call nsWebShell methods that I
want to override or not. However, then more docShells incur the editor
overhead, which we'd like to avoid.
> As an alternative to subclassing would it be possible for the editor
> session to dynamically register a listener with the docshell at session
> startup and have the docshell call out to to it?
I guess I'll have to look at this approach. This does not, however,
address the problem of having to override some of the webshell
url loading behaviour (like keyword expansion), so I'll have
to implement additional loading/notificaions mechanisms to
control this.
Simon
