[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [platform-ui-dev] Content sensitive object contributions
|
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
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
