Bugzilla – Full Text Bug Listing
| Summary: | Need a way to extend schema-derived content assist | ||
|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Richard Rodseth <rrodseth> |
| Component: | wst.xml | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | aberent, itewksbu, nsand.dev, pavery, thatnitind |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Thanks this is helpful to know what extensible features are desired. Can you detail some, though, in case we have to prioritize possibilities. Are you requesting new tags? attributes? (in which case I'd ask why they are not in the schema ... after all, content assist is to assist create a document which is valid). ... or ... are you looking for other options, like whole collections of tags? CDATA? some new sort of content? Thanks again. In my case I have an element <include ref="X"/> with X being a path to a file in the workspace. eg "/Shared/ Ontology/test.scp". So I would need a way to define the possible paths and names of diretories in this ref="" attribute. Another use for me is that we have an element like <e>X</e>. With X being some kind of linguistic expression. The keyword is here a "~" that references something that is used before in files. In Short: a way to make code completion within ref="...". And a code completion triggered by a "~" within the <e>...</e> elements. Would be great to add this "custom" code completion easily to the existing schema based code completion of the StructuredTextEditorXML. I'm close to what Raphael's use case. I just need to enhance the content assist for stuff specific to my framework but not lose the existing proposals. i.e. The documents I work with are not defined by a schema but rather by a DTD. Some elements contain OGNL expressions so by necessity the DTD element declaration is ANY. One of the puposes of my plugin is to enable content assist on this "ANY" element and provide proposals that fit in the context of the project the document resides in. What would be really cool would be a way to contribute a content assist handler to a chain of handlers. Sorta like servlet filters, each handler in the chain could examine the proposals generated by the parent handler and add, remove, modify proposals as needed. Geoff Raphael's example of a path value attribute is one I was going to suggest. For elements, an example might be the Ant editor, where you would want contributed tasks to show up as tag proposals, while the built-in tasks would be covered by the schema. The chain-of-processors idea is interesting if performance doesn't suffer. I suppose you could have an extension point that referred to a base processor. In the short term, I think I would be content with a nicely-factored base processor class to derive from (it doesn't look too bad right now) and a way for an editor to replace the processor that's configured by default. I favour composition over inheritance when possible so my vote would be for a chain. Yes, there is always the question of performance but I don't think the hit of a chain would be any greater. Most of the hit would be up front constructing the chain, any performance hit after that would be implementation specific (not in the framework that is) and would manifest itself regardless of whether a chain approach were implemented or not. In the larger picture, it appears to me that the xml editor contains all the bits there already and wouldn't it be nice to "define" a custom xml editor in terms of extensions only. Define a contentType and then, though a series of extensions, customize the default behaviours of the xml editor. A smart xml editor could, at instantiation, examine the contentType and configure itself accordingly based on the extensions related to that type. All without sublcsassing the editor class. This could go way beyond contentAssist (ie. a pie in the sky dream would be to tweak stuff like syntax coloring and outline views via extension). In the past we've utilized some rather ugly tricks to extend the schema driven guided editing. I've recently done some work to clean up our ModelQuery extension mechanism https://bugs.eclipse.org/bugs/show_bug.cgi?id=95336). The design is probably skewed to our specific requirements for WSDL and XML Schema editing … but it may be interest to those who are seeking to augment the guided editing provided by a ‘static’ XML Schema or DTD grammar. It’s worth pointing out that by tapping into the ModelQuery, various parts of the XML Editor UI will be aware of these additional constraints (not just the content assist in the source view). So for example, menus on the Outline or Design view (as well as content assist in the source view) will respect the extensions filters. The cell editors in the Design view and the properties views will respect the attribute value constraints (and will provide an appropriate ‘combo box’ cell editor to edit where applicable). I doubt this extension point will address all of the community requirements but you may find this a useful starting point. I’m sure some requirements will need to be addressed at an editor or ‘content assist specific’ level. This should be tracked as an 'enhancement'. This is still an interestingidea, but we don't have people to work on this just now. We would accept high quality patches, though. There are two ways to get more results into content assist for XML. Either threw the new extension points added by Bug 258999 or by ModelQueryExtension. As mentioned, we have various ways to accomplish contributions now. Hopefully these will be suitable. |
I need a way to add additional content assist proposals to those generated from the schema in an XML file. On the newsgroup, Nitin wrote: >> For .xml files, we haven't yet defined a way to contribute proposals to our existing Content Assist. and the behavior with conflicting org.eclipse.wst.sse.ui.extendedconfiguration extensions is undefined. <<