Community
Participate
Working Groups
The current XML catalog preference page supports a small subset of the OASIS XML Catalog support. If and when the patch in bug 112284 is applied, the UI should also reflect entry types for the following types (each could be handled uniformly, like it is for the current entry type which corresponds to uri, publicId and systemId entry types): - rewriteSystem - rewriteURI - systemSuffix - uriSuffix - systemIdSuffix - uriSuffix - delegatePublic - delegateSystem - delegateUri
Since I'm now a committer on source editing, I'm assigning myself to work on this in the next iteration.
Jesper, keep in mind that since you're working on preexisting code, you should have your proposed changes in this area reviewed by Valentin or Gabriel. I'm all for fleshing out our catalog support (or any other areas that are lacking, for that matter), but wading in and just committing your changes isn't the most courteous way to work. In any case, I have no problem assigning a bug to someone whether they're a committer or not. If they're not a committer, it actually makes it easier to find their history of contribution if/when they become nominated for it. I'm more interested in the Assignee reflecting who's doing the actual work. Even I wouldn't dive into PsychoPath and start making changes without having them reviewed by Mukul or Dave, though, so please check the commit history of the files you're touching and run them by the committer, at least in these early stages.
Hi Jesper, looking forward to you contribution and working with you to enhance the XML catalog UI to match the work you've done in the core. I've tagged this enhancement with the plan keyword to make it show in the WTP 3.2 Source Editing plans. Gabriel and I are ccd and we'll watch for patches.
Thank you Nitin and Valentin -- I was primarily stating an intention to tackle this feature which I found natural since I was also the one to contribute the XML Catalog support in core for WTP 3.1. I will submit a patch and request review during M3. Since the new catalog features being supported are rather "advanced" in a way, I would like to make the UI for it relatively low-key. Any comments or ideas are welcome!
Moving this to M4, I've been too busy on the XPath2 stuff.
(In reply to comment #5) > Moving this to M4, I've been too busy on the XPath2 stuff. Jesper looking forward to this contribution, as it's going to potentionally block full support of bug 287499 until we get the UI aspect and general support of the rewriteSystem and rewriteURI items in the user interface. Right now the DocBook XSL project provides a catalog but the default user the rewrite mechanism. http://docbook.sourceforge.net/release/xsl/current/catalog.xml Also, I opened a separate bug that might should be addressed at the same time as this one in which Workspace files are limited to DTD, XSD, JSP Taglibs, and ENT files types. We need to allow the support of all file types, as XML Catalog resolution could also happen with xincludes or any XML technology that makes use of URIs.
I'm getting close to completing the code for this one, but the icons are an issue: -I need nice icons (50 and 16 pixels) to represent rewrite entried, suffix entries and catalog delegates. Are there anyone out there who can contribute some artwork in this area? The current entries look like this (links to the GIFs): Catalog entry: http://dev.eclipse.org/viewcvs/index.cgi/sourceediting/plugins/org.eclipse.wst.xml.ui/src-catalog/org/eclipse/wst/xml/ui/internal/catalog/icons/etool50/catalogEntry.gif?root=WebTools_Project&revision=1.1 Next Catalog: http://dev.eclipse.org/viewcvs/index.cgi/sourceediting/plugins/org.eclipse.wst.xml.ui/src-catalog/org/eclipse/wst/xml/ui/internal/catalog/icons/etool50/nextCatalog.gif?root=WebTools_Project&revision=1.1 Hint to the artist (informal): Here's what the icons do: "Rewrite entries" substitute a part of the URL, i.e. changing [http://example.com/]blah.xml into [file:///tmp/cache/from-example-com/]blah.xml One idea for showing this like the icon for catalog entry with an arrow pointing to "duplicate" (like a dashed box "on top" of the entry) "Suffix entries" work pretty much the same as rewrites, but always point to a specific URL - if an input URL ends with the specified suffix, the URL, i.e. changing http://blah.com/[example.xsd] into [file:///tmp/cache/example-downloaded.xsd] This could also look like the icon for the catalog entry, but with an entry pointing to another entry. "Delegate Catalogs" point to the address of a different catalog, but is only used if the input URL points starts with a specified string. The icon could look like the "Next Catalog" but with a label together with the arrow. Can anyone help?
I'm copying Holger Voorman on this, as he did some of the icons we use in wst.xsl component, and has done several other icons used through out eclipse. Maybe he can help with the Icons.
(In reply to comment #7 and comment #8) Are we talking about the dialog which appears after hitting "Add..." in Window > Preferences > XML > XML Catalog? The look&feel of this dialog is a little bit strange compared to other Eclipse "Add..." dialogs (e.g. Window > Java > Installed JREs). I would expect to have a standard Eclipse wizard dialog with either two pages (the first page to select the type of the catalog entry) or with one page (different sections with radio buttons). If we do so we only need a 65 x 77 pixel icon for the wizard dialog header. By the way: "Key Type" should be renamed to "Key type" (lower-case 't') "Specifiy alternative web address" should be shortened to "Alternative web address" and the input field below should be indented. On the preference page in "XML Catalog Entries" and "Details" a ':' is missing. I would prefer not to have a border around these sections.
(In reply to comment #9) > The look&feel of this dialog is a little bit strange compared to other Eclipse > "Add..." dialogs (e.g. Window > Java > Installed JREs). Thanks for the analysis. I fully agree that the UI is kindda odd. The UI is reused for editing, too. However: I'm not sure if there's interest in revamping all of the UI at this point, since I'm not realy the "owner" of this part of WTP, I just have the proverbial itch to scratch in the general area of XML catalogs... Valentin, what's your opinion on this?
I'm including the text changes in my patch. I've thought some more about the dialog vs. wizard issue, and my conclusion is that I don't really like turning the "Add..." dialog into a wizard - it will add extra clicks to a process which should be straightforward. Some of the element types in XML catalogs are pretty odd, and having the different options are great for users exploring and comparing the different catalog element types. Alternatively: Could we use tabs instead of the icons on the left side? Valentin, Gabriel, Nitin: Thoughts anyone?
(In reply to comment #11) > ...I don't really like turning the "Add..." dialog into a wizard - it will > add extra clicks... > It doesn't require extra clicks. In any case one click is needed to choose the type of the item to add. Depending on the type there are a couple of options to specify. A wizard is the perfect match: pages make the depends-on behaviour (set of options depends on the item type) more explicit; there is a standard place to display description text and a well-known mechanism to display errors if needed. In contrast, tabs are normally used to split huge amount of information.
(In reply to comment #12) > (In reply to comment #11) > > ...I don't really like turning the "Add..." dialog into a wizard - it will > > add extra clicks... > > > It doesn't require extra clicks. In any case one click is needed to choose the > type of the item to add. Depending on the type there are a couple of options to > specify. > A wizard is the perfect match: pages make the depends-on behaviour (set of > options depends on the item type) more explicit; there is a standard place to > display description text and a well-known mechanism to display errors if > needed. > In contrast, tabs are normally used to split huge amount of information. I have to agree with the wizard approach if we can get it in place. For one thing, we can then make it available as one of the New Wizard options. So under XML we can have XML Catalog. You could then use the same code in the preference page as well. I helped with the migration a couple of years ago if the Import and Export XML Catalog and moved that from a Dialog in the preferences to a Wizard based solution, which is overall a cleaner approach.
Jesper, Holger, Dave, thank you for your comments and suggestions on the XML Catalog UI. Please remember that revamping the entire catalog UI is not in plan for WTP 3.2. My suggestion is to focus on implementing what this enhancement originally set out to do - providing UI for the new type of entries from the 1.1 spec - and to open a separate enhancement to deal with revamping the Catalog UI. In my experience, radically changing the UI is "expensive": documentation needs to be updated, tutorials, users will be confused, etc. I would rather have all that work done separately, perhaps in the next WTP release. Contributions are welcome and appreciated.
Valentin, agreed, a bit much to do with only 2 milestones left before API lock down.
Then we're back to the original question of icons... I've made some but they aren't as nice as the existing ones.
(In reply to comment #14) > ... I would rather have all that work done separately... > Filled bug 299998 for that. (In reply to comment #16) > I've made some but they aren't as nice as the existing ones. > Could you please attache these icons to this bug?
Created attachment 156458 [details] List icon for the rewrite entry
Created attachment 156460 [details] List entry for a delegate catalog
Created attachment 156461 [details] Toolbar image for rewrite entries This one I like the least
Created attachment 156462 [details] Toolbar image for delegate catalogs Only subtly different from the nextCatalog image
Wow you narrowly missed bug 300000...
Created attachment 156465 [details] Preliminary patch which doesn't cover all entry types Here's a test for the early adopters among you. Note that the code also fixes the catalog writing (for the new element types) It requires the icons in the right places (tool16 and tool50 folders) All in all, it's getting there, but there are a few rough edges to sort out, such as the horrible uasbility of the toolbar on the left of the "Add..." dialog.
Created attachment 157157 [details] Icon for delegate catalog
Created attachment 157158 [details] Icon for rewrite entry
Created attachment 157159 [details] Icon for suffix entry
Created attachment 157162 [details] Complete patch for review I did away with the big icons, since they just wouldn't fit in. So I opted for radio buttons instead. There is now editing for all five types of catalog elements (catalog entries, rewrite entries, suffix entries, delegate catalogs and next catalogs) This patch improves the catalog writing functionality This patch also fixes the problem with not being able to select XML catalog files (essentially bug 288919) The patch also has icons, label provider and detail formatter for all the different entry types. Please review - I know it's late for M5, but I really think we are getting "somewhere" with improving the XML Catalog functionality with this.
Created attachment 157169 [details] 16x16 icons: "Rewrite entries", "Suffix entries" - DRAFT Which icons do we exactly need? Do we need each of them as 16x16 pixel and as big icon? Do we need a "Rewrite entries" _and_ a "Suffix entries" icon? Is "Delegate Catalog" and "Next Catalog" the same?
Valentin can you review Jesper's patch? Or can Gabriel do it? I think we are running out of time for M5, but would be great to get this in early for M6. I'm running into several situations with wst.xsl that can benefit greatly from full XML Catalog 1.1 support and ui.
Sure Dave, I've replied to Jesper's note on wtp-dev. This is the right way to signal a fix is ready for review. Yes, it is too late for M5 as we are in the milestone testing/shutdown phase. We'll look at these fixes for early in M6.
Nice icons, Holger! As for the icons we need: I did away with the big 50x50 icons since the UI just didn't scale, so now the requirement is only for the resouce icon to show in the XML Catalog tree view in the preference page, so the icons must be appropriate for that use. The icons we need to distinguish are the following: 1) Catalog entries (where a full identifier maps directly to resource). The icon used (today, and in my patch) is the icon associated to the resource's content type. 2) Rewrite entries (where an identifier is partially matched by prefix and rewritten into a new identifier, like http://myserver.com/xxx is rewritten into file:///tmp/myserver-cache/xxx 3) Suffix entries where an identifier is partially matched and mapped to a specific resource, like (xxx/docbook.dtd maps to file:///home/jesper/docbook-4.2.dtd) 4) Delegate catalogs where all identifiers partially match a prefix is handled by a specific catalog file. 5) Next catalog (which is a fancy name for an import statement, i.e. a daisy-chained catalog reference) These are all different, and icons for cases 1 and 5 are handled by the current solution, and case 2-4 need an icon.
Created attachment 157195 [details] 16x16 icon set - DRAFT (In reply to comment #31)
Created attachment 157295 [details] All 5 icons, each as 16x16 and as 50x50 Proposal to discuss
(In reply to comment #33) > Created an attachment (id=157295) [details] > All 5 icons, each as 16x16 and as 50x50 +1 on the 16x16 icons - but I don't think we're going to need the 50x50 pixels, since I've switched to a radio buttons with text, since the toolbar grew to 5 x 50 pixels plus space between.
Created attachment 157473 [details] All 16x16 icons in GIF format
Jesper, Holger, Gabriel is reviewing the patch early in M6 and will provide feedback. From me just a bit of high level guidance: keeping in line with the M6 theme of accessibility, please ensure that all new UI bits are properly coded to be accessible (tab order, mnemonics, etc). This article should help clarify the goals http://www.eclipse.org/articles/article.php?file=Article-Accessibility351/index.html. Thanks for your work and looking forward to seeing this contribution committed in M6.
Created attachment 159262 [details] Patch jesper, I reviewed the patch, it looks really good. I found a minor problem when editing suffix entries. The dialog box prompts entries already exist. I could see this was caused by an object comparison that didn't take into account the old/new entry object approach used in the catalog editing logic. I made changes in the code to address this. I also noticed there is no duplicate detection implemented for the other new entries, was this done for a specific reason? With regards of the UI, I agree with Holger, a wizard would probably be the best approach for this scenario. However, due to the scope of such changes it would probably be better to handle these in a separate enhancement. In the meantime, I changed the design from radio buttons back to its original layout using the left hand side vertical toolbar with icons. Jesper, let's continue reviewing the patch together, let me know what you think about the changes and if there are any others that you would like to include.
Created attachment 159263 [details] Icons for patch (including 50x50s)
In the attached patch I also included a number of changes in the catalog entry text descriptions (shown in the text area below the tree structure in the preferences page). I noticed that a number of strings would need to be changed in order to correctly support globalization. I'll open a separate bug for this, and within this enhancement, the text area could be replaced by a different control such as a table to better accommodate the information to be displayed.
Jesper, Just a couple of more questions: there are two test cases that seem to fail (testReadComplexCatalog and testReadAndWriteComplexCatalog). I also noticed there is an XML Schema file included in the test (xmlcatalog11.xsd), how was this file developed/written?
(In reply to comment #41) > Jesper, > Just a couple of more questions: there are two test cases that seem to fail > (testReadComplexCatalog and testReadAndWriteComplexCatalog). I also noticed > there is an XML Schema file included in the test (xmlcatalog11.xsd), how was > this file developed/written? the xmlcatalog11.xsd comes from OASIS and has gone through IP review. See CQ 3641 for more information.
(In reply to comment #42) > (In reply to comment #41) > > Jesper, > > Just a couple of more questions: there are two test cases that seem to fail > > (testReadComplexCatalog and testReadAndWriteComplexCatalog). I also noticed > > there is an XML Schema file included in the test (xmlcatalog11.xsd), how was > > this file developed/written? > > the xmlcatalog11.xsd comes from OASIS and has gone through IP review. See CQ > 3641 for more information.
(In reply to comment #41) > Jesper, > Just a couple of more questions: there are two test cases that seem to fail > (testReadComplexCatalog and testReadAndWriteComplexCatalog). Did you apply the core.xml part of the patch also? It is required to save XML catalog correctly.
(In reply to comment #37) > I reviewed the patch, it looks really good. I found a minor problem when > editing suffix entries. The dialog box prompts entries already exist. I could > see this was caused by an object comparison that didn't take into account the > old/new entry object approach used in the catalog editing logic. I made changes > in the code to address this. Ok, that was an oversight. > I also noticed there is no duplicate detection > implemented for the other new entries, was this done for a specific reason? I'm not sure delegate catalogs need dup checking, I'll check. > With regards of the UI, I agree with Holger, a wizard would probably be the > best approach for this scenario. However, due to the scope of such changes it > would probably be better to handle these in a separate enhancement. In the > meantime, I changed the design from radio buttons back to its original layout > using the left hand side vertical toolbar with icons. You must add a scrollbar to the toolbar, then.
(In reply to comment #42) > the xmlcatalog11.xsd comes from OASIS and has gone through IP review. See CQ > 3641 for more information. Excellent Dave, thanks for the confirmation.
(In reply to comment #44) > Did you apply the core.xml part of the patch also? It is required to save XML > catalog correctly. Yes, I applied the patch to all affected plug-ins including core.xml.
Jesper and Gabriel: I added a patch to bug 203261 that will add the approved XML Catalog to org.eclipse.wst.standard.schemas. You might want to take a look at that and make sure that it is lining up with what you expect. I've added both Jesper and Nitin for review.
Yes, I can reproduce the wrong test, I'll fix this Tuesday.
Created attachment 160016 [details] Improved patch This patch builds on Gabriel's latest patch but fixes the following: - Catalog loading continues even if a single element is skipped (this is what caused the test failures) - Rewrite entries and suffix entries are now checked for duplicates on saving BTW, I think the UI is much nicer now with Gabriel's layout and Holgers icons. Also, I do hope we will also get to commit the patches in bug 300619 and bug 288919 in M6.
Did this slip 3.2 M6 meaning it slipped Helios altogether?
We're still hoping to put this in. I'm pretty sure we can negociate an exception. Nitin, David, thoughts?
(In reply to comment #52) > We're still hoping to put this in. I'm pretty sure we can negociate an > exception. Nitin, David, thoughts? I'd go with the latest changes and patches. And fix remaining bugs during M7. It's important from an XML Tool perspective that the complete implementation be there. It's an interoperability issue on catalogs if we only support a small subset of the specification. So my vote +1 for getting it in, and then tweaking during M7.
I know Gabriel has reviewed the latest patch yesterday and he's getting ready to add a few comments.
(In reply to comment #54) > I know Gabriel has reviewed the latest patch yesterday and he's getting ready > to add a few comments. I'll be monitoring over the next hours, then...
Created attachment 161160 [details] New patch New patch iteration, built on Jesper's improved patch, adds: - Addressed NPE that occurs when trying to add delegate catalog entries - Added missing parameter verifications - Added status refresh when switching between entry types - Addressed colliding mnemonics I've seen items not yet implemented that have been marked with TODOs i.e. error markers for invalid entries. A new bug should be opened to address them. In addition to this, a number of strings are handled in such way it could impact globalization requirements. A separate bug should be opened to handle this as well.
Jesper, are you comfortable committing/releasing the code? Then if Nitin is fine with this, after the weekly driver is declared, feel free to put this in.
I'm reviewing the code and TODOs now.
Committed and released as v201003082046 (xml.core, xml.tests and xml.ui), as per Valentins comment. Shouldn't we add this to the new and noteworthy page, as well?
(In reply to comment #59) > Committed and released as v201003082046 (xml.core, xml.tests and xml.ui), as > per Valentins comment. > Shouldn't we add this to the new and noteworthy page, as well? I've added the noteworthy tag. Keep an eye on wtp-dev for when Nitin makes the announcement for creating the 3.2M6 noteworthy items, and add them to the appropriate page.
Closing.
