Community
Participate
Working Groups
The XML editor in Eclipse has been compared to other XML editors and found to be rather basic (see [1] for an example). FEEP funding should be used to provide a decent XML editing support in Eclipse (in all packages). [1] https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00834.html
The comparison was made between the XML editor (from WTP) and the PDE editors which can only edit specific PDE files. They cannot really be compared. There is no XML editor or XML framework in the platform since we already have an XML editor along with the Structured Source Editing framework in WTP that can be separately installed. > FEEP funding should be used to provide a decent XML editing support in Eclipse > (in all packages). We don't need to use money for that. This can be easily added to all packages (assuming approval from the corresponding package maintainer). This process has already been started by Konstantin: https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00849.html
(In reply to Dani Megert from comment #1) > The comparison was made between the XML editor (from WTP) and the PDE > editors which can only edit specific PDE files. I wasn't clear enough. It's not _only_ about having 'some' xml editor. I linked to the discussion about decent "refactoring" support e.g. for closing tags etc.
(In reply to Marcel Bruch from comment #2) > (In reply to Dani Megert from comment #1) > > The comparison was made between the XML editor (from WTP) and the PDE > > editors which can only edit specific PDE files. > > I wasn't clear enough. It's not _only_ about having 'some' xml editor. > I linked to the discussion about decent "refactoring" support e.g. for > closing tags etc. OK, so we are talking about improving current XML editor from WTP.
This is too vague for me.
(In reply to Pascal Rapicault from comment #4) > This is too vague for me. I agree that this is vague, but don't consider this a problem. There are an impressive number of bugs open against the XML editor [1]; a proposed solution could address any number of them. In fact, IMHO the first phase of a valid proposal would include the work of triaging these bugs to select some subset to address in the second phase. I'd expect, however, that any proposal be at least somewhat concrete and suggest at least a theme for the second phase of work (i.e. improve robustness, or focus on a specific feature). Triage is, IMHO, valuable work. [1] https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&classification=WebTools&component=wst.xml&list_id=13713532&product=WTP%20Source%20Editing&query_format=advanced
XML validation in Eclipse IDE is good enough IMO, however what frustrates me the most is that it can easily report error, but I almost never see a useful quickfix available for the reported error. So IMO, a first iteration would be to start working on quickfixes. Then when there are quickfixes available and some pretty obvious cases when those should be applied in all cases, we can imagine running them without asking user to ease edition.
If we want people to use Eclipse as preferred editor for XML, we need to provide: 1. A fast editor, with good highlighting, intuitive search and mark occurrencies in the file. As Example: Notepad++ is fast to open; fast to scroll from top to bottom of big files; the search/replace is quick; the automatic mark occurrencies is intuitive and fast. 2. Suggestions to add/complete tags: a. - if XSD is defined, suggest based on this b. - if no XSD is defined (majority of cases), check the current namespace (empty or not) and provide a list of possible suggestions c. - use an IA/inference engine, like coderecommenders to suggest the user the "best options". 3. Transformations/actions on one or more of XML files. As an example: XSLT generation to generate an HTML, or PDF generation from Docbook. As perfect use case, could consider writing an XSL-T, using a big XML as input, to generate HTML as output. With this test, we'll test some of the limits: - Speed on big files - and completion support for input XML based on XSD - completion support for the XSL-T directives - support of generation/transformation. Sorry for being not too much specific and little bit chaotic in exposing. Note: I kept these opinions since a long time. Some of the points might be already solved. In the past 10 years I compared Eclipse against XMLSpy, oXygen xml, Notepad++ (general notepads).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
FEEP is terminated, and this issue is too vague to be actionable. Let's close. Interespted parties who want to contribute to WTP can do it by opening specific bug reports and enhancement request and some code to go with their wish-list.
