Hi Andreas, yesterday you wrote:
> Am 17.10.10 19:04, schrieb Rainer Schöpf: > > At the moment, only BXE and OneForm appear in the Edit Menu (by > > default). This is configured in, e.g. > > > > src/modules/xhtml/config/menu.xml > > > > I'd like to see all installed editors included here. > > the major difficulty I see here is that each editor is only capable of > editing documents of particular resource types. So we end up with a matrix > (editor x resource type => true|false). True, but a) there is only a small number of editors supported out of the box, and b) this is the configuration for the xhtml resource type, so it's reasonable to add, e.g. TinyMCE and, eventually Firedocs. > > > > A number of possibilities: > > > > 1. Detect installed editors at runtime and construct menu accordingly. > > > > Plus: easiest way for users > > Minus: might not be easy to implement > > > > 2. Detect installed editors at build time and construct menu accordingly. > > > > Plus: relatively easy to implement > > I'm afraid it is not trivial to implement this (see above). > > It is probably more likely that the user adds custom resource types than > custom editors, so I think it makes the most sense to put the edit menu items > in the resource type menus to provide a maximum of flexibility. > > WDYT? I'm not entirely sure whether I understand you correctly. Are you saying we should add edit menu items for all/most supported editors? In that case, I'd like to have the items disabled if the editors cannot be used. I believe that this is relatively easy to implement in the usecase's doCheckPreconditions() method. I've just checked in a change for the TinyMCE usecase that disables the menu item when uploads are disabled. I'd like to add a check for the existence of the Tiny JavaScript files. Similarly, other edit menu items would be enabled only if the Browser supports them. In this way, the list of editors for a certain resource type is independent of whether the editor can be used at all or not. Does this sound reasonable? Rainer
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lenya.apache.org For additional commands, e-mail: dev-h...@lenya.apache.org
