Gunnar, David and Bob,
The support for filtering object contribution actions by XML file type was
just our first stab at solving the scalability problem.
We fully intend to extend this to selection of editors, and to generalize
the mechanism beyond the XML case (and beyond workspace resources as
well).
Thank you for your suggestions. There are some really interesting ideas
here.
Could you please append your comments to the scalability plan item PR (as
Gunnar has already done), either by posting directly to the PR or creating
a new one and linking to it.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37929
While we do not have the resources to address this for M6, we will be
picking up on this early in the new year.
Thanks,
Nick
Bob Foster <bob@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
12/15/2003 09:52 AM
Please respond to
platform-ui-dev
To
platform-ui-dev@xxxxxxxxxxx
cc
Subject
Re: AW: [platform-ui-dev] Content sensitive object contributions
I strongly support this direction. David Williams' proposed contribution
sounds like a good starting point.
It is not just that multiple application-specific content types can hide
under a single extension, like '.xml' or '.mod', but also that a single,
generic content type can underly multiple extensions, like '.xsd',
'.xsl', '.rng', which if nothing more specific is available, are all XML
files, and if no XML editor is available, are all text files. Some
specific points:
1. Categorization levels can handle both cases, but the scheme will work
only if developers have clear guidelines how to assign the levels so
they correspond to the user's expectation that "higher" levels mean more
specificity. Another set of levels, ordered from most to least generic,
might be:
NEVER - Cannot handle this kind of file at all.
BYTES - Binary content, e.g., used by hex editors
CHARS - Character content, e.g., used by text editors
FORMAT- File format, e.g., XML, Java, JPEG
HORIZ - Generic application, e.g., XSD, XSL, Wizard page
APPL - Specific application, e.g., XSD for Music Inventory
Or there could be an unambiguous mapping from these use cases to the
proposed set.
2. There should be a set of predefined content types for the well-known
use cases, so that, e.g., two different generic XML editors can use the
same content type. Content types should have an internal and localizable
external format, the latter for use in the UI. E.g., "java.source" and
"Java". There should be recommended conventions for internal naming,
e.g., that the internal type of a programming language source file - a
common use case - is the common name of the language in lower-case
letters followed by ".source", e.g., "ruby.source", "perl.source",
"php.source". While not strictly necessary, such conventions would
reduce aliasing.
2. Any content type assignment (or the effect of it) must be
overrideable by the user. The current extension-based GUI for editor
assignment has the merit of being fairly easy to understand. The
proposed mechanism puts a level of indirection, the resource type,
between the extension and the plug-in to apply to the resource. If the
user is not let in on the secret, then a user's blanket assignment of,
say, all .xml files to one editor, will (or should) effectively disable
assignment by content type for that extension. This would not be good.
Therefore, perhaps this should become a "three-pane browser". The user
selects an extension or file name, and in the second pane a list of
possible content types is displayed (with the current setting selected).
Based on the selection in the second pane, the third pane would show all
available editors for that content type.
Anyway, it's a suggestion. ;-}
Bob Foster
David M Williams wrote:
I agree -- both that its a good idea, and that we could do much better.
And, in fact, I have a framework I'd like to propose as a contribution
that is capable of handling this use-case (and others). And, if
accepted, it will make most sense if available from a "platform level".
It will take me a day or two to have somewhere for download, but I could
send in the mail if anyone is very anxious to take a look.
It differs from what's been discuss so far in that 1) it really is just
a ContentTypeIdentifier object. It doesn't do much else. But, its
powerful enough to do its job well :)
Using APIs/statements like
AppropriatenessLevel appLevel =
contentTypeIdentifier.appopriatenessFor(IFile);
[ or (filename, inputstream), or (URL),]
then the implementer can use what ever logic, devices, or OS functions
they wanted to determine how appropriate that identifier is for that
resource. I currently have defined AppropriatenessLevels in 5
categories;
NEVER, COULD, CAN, SHOULD, MUST. I give examples in docs, but the idea
is that each implementers "votes" for itself or not, and hopefully, only
one "wins". The purpose of this little twist is that in some contexts a
file can easily match more than one ... any 'ol <%xml file would qualify
for "could" for org.eclipse.contenttypeidentifer.xml ( but an ant build
file would return a 'SHOULD", hence, the
org.eclipse.contenttypeidentifier.antbuild.id would win out.
For some clients of this framework, they may want to always take highest
matching (e.g. which to use for encoding rules, or deciding default
editor), but in other cases, such as what goes on the context menu, you
might want to "pick up" all Actions that match with any associated
contentTypeIdentifier. We've been using this framework for a few years
and its worked well .. of course, our use of it has been limited since
not in base.
The Sax part of your implementation would be just as it is, but cause a
response of "should' if found, and 'never' if not found to quality.
I do not, as yet, have any persistence in my framework, and I like the
way you did it. I wonder though it there too, there might be reason to
develop a little further, to make a little more general purpose. I think
we are quickly getting to the point where will be many types of
"FileCharacteristics" that will want to be re-discovered and cached
(e.g. in addition to its contentTypeIdentifier, its encoding, its
inferred DOCTYPE, etc. And, frankly, I think the persistence part could
be worked out later. Maybe there's use cases I'm not aware of, but I
would think, for example, that deciding the contenttype after context
menu request would not take a noticable amount of time ... guess it
depends on how many implementers there are.
Thanks for your consideration.
*"Gunnar Wagenknecht"
<G.Wagenknecht@xxxxxxxxxxxxxxxxxxxxx>*
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
12/15/2003 02:31 AM
Please respond to platform-ui-dev
To: <platform-ui-dev@xxxxxxxxxxx>
cc:
Subject: AW: [platform-ui-dev] Content sensitive object
contributions
Hi!
I appreciate the work on content sensitive object contributions but I'd
like to recommend a more generics solutions because there are more
problems related to this. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=21652 for an example. IMHO
it would be nice to have a extensible solution for 3.0.
In general the problem is that a resource type can not be identified by
its same. Instead it is often necessary to look at its content
(sometimes file header is enough). XML files are _the_ reference for
this problem.
IMHO this porblem is related to the IDE part of the RCP and should be
separated if possible. In my eyes we need some kind of
IResourceClassifier that can be registered to resources. This can be a
simple interface with only one method "boolean
isQualifiedResource(IResource resource);" and registered to IResource
objects with a specified type (file/folder) and name (regular expression
match).
Example:
<extension
point="org.eclipse.core.resources.resourceClassifier">
<classifier
resource_type="org.eclipse.core.resources.IFile"
name_match=".*\.xml"
class="my.sax.based.xml.content.classifiers.AntBuildFileClassifier">
</classifier>
</extension>
<extension point = "org.eclipse.ui.popupMenus">
<objectContribution ....
...
<visibility>
<or>
<objectState name="resourceClassifier"
value="my.sax.based.xml.content.classifiers.AntBuildFileClassifier"/>
</or>
</visibility>
....
</objectContribution>
</extension>
The AntBuildFileClassifier can be inherited from a generic abstract
"SAXbasedXMLFileClassifier" that defines some abstract methods like
"String needsFirstTag()" or "String needsDTD()".
Cu, Gunnar
-----Ursprüngliche Nachricht-----
Von: Bob Foster [mailto:bob@xxxxxxxxxx]
Gesendet: Mi 10.12.2003 23:53
An: platform-ui-dev@xxxxxxxxxxx
Cc:
Betreff: Re: [platform-ui-dev] Content sensitive object contributions
There is no such link on that page. It is at:
http://www.eclipse.org/platform/index.html > UI > Development Resources
> Content Sensistive Object Contributions.
or the easy-to-type full address
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/object-aware-contributions/objCont.htm
Bob
Debbie Wilson wrote:
>
> Have you ever been fussed by the fact that 'Run Ant...' is one of the
> actions available in the context menu of a plugin.xml file? This no
> longer needs to be the case. There is new functionality in the UI
which
> will allow object contributions to be sensitive to the contents of an
> xml file (currently only the root level tag and the dtd, if
specified).
> If this intrigues you, check out the following link:
>
> http://www.eclipse.org/platform/index.html -> Content Sensitive
Object
> Contributions
>
> Deb
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
#### winmail.dat has been removed from this note on December 15, 2003 by
David M Williams
