Re: AW: [platform-ui-dev] Content sensitive object contributions

[David M Williams <david_williams@xxxxxxxxxx>]

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