Bug 206129 - Easy and standard way to specify default-absolute resource attributes
Easy and standard way to specify default-absolute resource attributes
Status: NEW
Product: platform
Classification: Unclassified
Component: Filesystems
7.2
All All
: P4 (vote)
: 7.3
Assigned To: Jaroslav Havlin
issues@platform
: API
Depends on: 238107
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-08 09:54 UTC by Jaroslav Tulach
Modified: 2013-11-07 16:10 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2011-12-08 09:54:36 UTC
As discovered in bug 204174 current way to deal with relative/absolute icons is too complicated. If we let every author of a processor to handle it on its own, it will be a mess. There should be simple to use, flexible, standard way to specify references to resources.

Requirements:
1. compatible with current approach to treat the value as full path without initial slash
2. if compiles on JDK7 (where the icon can be validated), it has to compile on JDK6
3. support for relative path
4. support for full path
5. nice to have: code completion for free

If the signature of the main utility method could be:

public LayerBuilder.File LayerBuilder.File.resourceValue(
  String path, boolean preferRelative
);

it would be a huge win from my point of view.
Comment 1 Jesse Glick 2011-12-08 13:55:31 UTC
(In reply to comment #0)
> 4. support for full path

Probably implied by #1. Note that due to requirement #1 it is not safe to switch existing absolute-only attributes to default-relative; they can only be switched to default-absolute. Otherwise as noted in bug #204174 there are potential ambiguities even assuming a compliant 269 environment, and in buggy JDK 6 javac (with searchClasspath=true) as far as I know it would be impossible to even guess which style is wanted.

> 5. nice to have: code completion for free

Interesting thought. I _think_ this would be straightforward. (Could not be completely for free - processor would need to enable it for a particular attribute - but the bulk of the implementation could be shared.)

> If the signature of the main utility method could be:
> 
> public LayerBuilder.File LayerBuilder.File.resourceValue(
>   String path, boolean preferRelative
> );

I guess I do not follow what such a method would do.

We already have validateResource and absolutizeResource which suffice for default-relative and absolute-only attributes. One more (Element,String)->String method would suffice to handle also default-absolute attributes in an analogous manner.

Note that it is important for validateResource to remain independent of the construction of the absolute path, since some processors just want to open the FileObject for its contents (or get its URI perhaps), whereas others will subsequently work with the String absolute resource path and merely want to ensure that it exists.
Comment 2 Jaroslav Tulach 2011-12-08 18:06:00 UTC
> > 5. nice to have: code completion for free
> 
> Interesting thought. I _think_ this would be straightforward. (Could not be
> completely for free - processor would need to enable it for a particular
> attribute - but the bulk of the implementation could be shared.)

More comfortable it would be to have @ResourceOnClassPath (meta)annotation and annotate the annotation's value with it. That is almost for free.

> > public LayerBuilder.File LayerBuilder.File.resourceValue(
> >   String path, boolean preferRelative
> > );
> 
> I guess I do not follow what such a method would do.

Because I mispelled its parameters. Another try:

public LayerBuilder.File LayerBuilder.File.resourcevalue(
  String attrName, String path, boolean preferRelative
)

would generate <attr name="${attrName}" stringvalue="${(full)path}"/>. This does not need to cover 100% of usecases, but it should be good enough for 90%. Yes, all existing annotations would have to say 'false' to preferRelative. New annotations might choose 'true' inspite it would only work reliably on JDK7.
Comment 3 Jesse Glick 2011-12-08 18:28:47 UTC
(In reply to comment #2)
> @ResourceOnClassPath (meta)annotation

Too magical, and would interact poorly with processors wishing to implement getCompletions on other attributes. Better to provide something like

enum Mode {ABSOLUTE_ONLY, DEFAULT_ABSOLUTE, DEFAULT_RELATIVE}
Iterable<? extends Completion> resourceValueCompletions(Element element, Mode mode, boolean searchClasspath, String userText, String... fileExtensions);

that could be used if desired, possibly in combination with other things.

> public LayerBuilder.File LayerBuilder.File.resourcevalue(
>   String attrName, String path, boolean preferRelative
> )
> 
> would generate <attr name="${attrName}" stringvalue="${(full)path}"/>.

This tries to do too much and would be unusable for certain purposes. Existing methods (plus the new proposed (Element,String)->String method) accomplish the same thing in obvious combination but retain flexibility.

> all existing annotations would have to say 'false' to preferRelative. New
> annotations might choose 'true' [though] it would only work reliably on JDK7.

It is fine to _introduce_ an annotation attribute in default-relative mode, even when supporting JDK 6 (in fact several attributes in @TemplateRegistration do just that) - the presence or absence of initial slash unambiguously distinguishes relative from absolute paths. What is not compatible is _changing_ an attribute which is currently absolute-only to default-relative.

Retrospectively, perhaps all resource attributes should have been defined as default-relative to begin with, but it is too late for that now. An alternate solution to the issue would be to mark existing iconBase attributes (or any other absolute-only resource attributes) as @Deprecated and introduce new default-relative attributes ("icon"?) in their place. This would be somewhat disruptive though the change could be ameliorated with editor hints.
Comment 4 Jesse Glick 2012-03-15 02:43:49 UTC
Sorry, did not get to this in time to file a review prior to 7.2 feature freeze. If this is, or is blocking, a DEFECT then let me know.


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