Bug 207960 - Hint for @MIMEResolver.Registration
Hint for @MIMEResolver.Registration
Status: STARTED
Product: apisupport
Classification: Unclassified
Component: Refactoring
7.2
All All
: P2 (vote)
: 7.3
Assigned To: Martin Kozeny
issues@apisupport
: PATCH_AVAILABLE
Depends on: 207959
Blocks: 191777 208394
  Show dependency treegraph
 
Reported: 2012-01-31 16:33 UTC by Jesse Glick
Modified: 2013-02-14 13:17 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
MIMEResolver Hinter (96.32 KB, patch)
2012-03-28 21:54 UTC, skygo
Details | Diff
MIMEResolver Hinter with correct diff (68.63 KB, patch)
2012-09-17 15:40 UTC, skygo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2012-01-31 16:33:19 UTC
See bug #191777 comment #13 JG02.
Comment 1 Jesse Glick 2012-02-24 19:35:52 UTC
Related to bug #208394.
Comment 2 skygo 2012-03-05 21:02:39 UTC
Hello, I can handle this but I not sure of what this hinter should do.

Do this hinter only handle the MIMEResolver.Registration or should it be able to infer usage of the more precise one 
(i.e. ExtensionRegistration,NamespaceRegistration )
Comment 3 Jaroslav Tulach 2012-03-09 13:27:19 UTC
It would be good, if you could detect simple cases and register with Namespace or Extension registration.
Comment 4 skygo 2012-03-14 18:18:29 UTC
Hi, I am currently trying to have a workflow for the hinter.

EB01 

My point is to propose refactoring to be done in DataObject. (with trying to match mimetype). 

It's an arbitrary choice (because MIMEResolver.Registration is not bound to a particular type) but I'am not aware on how to convert otherwise.


EB02

My second point is about a potential strategy. I am not fluent in filesystem so I may not see all drawbacks. 

Mime-resolver xml are set of <file> with a mandatory child: resolver or exit.

Now that registration is available: it possible to deal with each <file> entry separatly [1]?

For example if I take resolver from CND Source 
http://hg.netbeans.org/main-silver/file/aabf4ca943fd/cnd.source/src/org/netbeans/modules/cnd/source/resources/mime-resolver-ext-based.xml

may Hinter propose an annotation:

@MIMEResolver.ExtensionRegistration(
mimeType="text/x-h",
extension={"h", "H","hpp",....}
) 

to be written in HDataObject (according to mimetype).

Same for the 3 other mimeType.

[1]
-Of course if a <exit> element is present it's a bit more tricky.
-not handling mask or pattern elements
Comment 5 Jesse Glick 2012-03-21 19:28:06 UTC
No patch yet (assuming skygo still wants to work on this), so cannot definitely plan for 7.2.


(In reply to comment #4)
> It's an arbitrary choice (because MIMEResolver.Registration is not bound to a
> particular type) but I'am not aware on how to convert otherwise.

Yes, because of bug #207959 it is arbitrary. For now the convention is to try to place it on a relevant DataObject.


> For example if I take [...]/cnd/source/resources/mime-resolver-ext-based.xml
> 
> may Hinter propose an annotation:
> 
> @MIMEResolver.ExtensionRegistration(
> mimeType="text/x-h",
> extension={"h", "H","hpp",....}
> ) 
> 
> to be written in HDataObject (according to mimetype).

That would certainly be cool if it can be reliably detected. Not necessary for the hint, I think.
Comment 6 skygo 2012-03-23 20:45:25 UTC
my current patch is not functional, I'm trying to get the complicated case done. I cannot do progress until end of next week.
If urgent I can give my current work so you may complete to fit with schedule. 

But if it's possible for me to have some delay I will finish. 

the advanced mimeregistration hinter I am working on share lot of code with issue #208394
 
 what is the better solution ?
    1- refactor code from #208394 in this issue
    2- let this issue with duplicate + open later another issue for refactor duplicate code.
Comment 7 Jesse Glick 2012-03-27 21:17:43 UTC
(In reply to comment #6)
> But if it's possible for me to have some delay I will finish. 

Whenever you like. Probably not for 7.2.

>  what is the better solution ?
>     1- refactor code from #208394 in this issue
>     2- let this issue with duplicate + open later another issue for refactor
> duplicate code.

#1 please.
Comment 8 skygo 2012-03-28 21:54:34 UTC
Created attachment 117438 [details]
MIMEResolver Hinter

First attemp for the hinter.

Add a "strategy manager" to infer to best Registration
// may be a bit too optimistic for now. Need a carefull review. I had some test to help but coverage is limited.
// if something go wrong fallback to normal Registration

Add a method in Context to allow several modification at once.

Try to share with DataObjectHinter

was only able to test with "j2ee.websphere6 module" as Jaroslav refactor almost everything during implementation of the annotation.
Comment 9 Jesse Glick 2012-05-07 21:42:29 UTC
(In reply to comment #8)
> Created attachment 117438 [details]
> MIMEResolver Hinter

Why the rewrite of project.xml?
Comment 10 skygo 2012-05-09 09:28:43 UTC
It was to be able to use nbtestcase. 
I don't understand why the diff in project.xml show so many line of changes.
Comment 11 skygo 2012-09-17 15:40:06 UTC
Created attachment 124463 [details]
MIMEResolver Hinter with correct diff

Sorry for the long delay.
My mercurial settings was silently failing on eol :( (on windows of course).

I try the patch on current codebase and its still working.

Best Regards

Eric -Skygo


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo