This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 19357 - Ordering of results in ProxyLook/CompositeLook
Summary: Ordering of results in ProxyLook/CompositeLook
Alias: None
Product: contrib
Classification: Unclassified
Component: Looks (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Petr Hrebejk
Depends on:
Blocks: 18177
  Show dependency tree
Reported: 2002-01-11 15:50 UTC by _ rkubacki
Modified: 2008-11-18 11:34 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2002-01-11 15:50:41 UTC
I would be usefull to have a way how to specify order of elements returned from
some methods like getPropertySet() in CompositeLook.
Comment 1 Marek Grummich 2002-07-22 11:21:19 UTC
Set target milestone to TBD
Comment 2 Petr Hrebejk 2003-05-06 09:45:01 UTC
Hmm I don't think this should be fixed in the ProxyLook. There are
some workarounds for this. You may for example create a filter look
which will take all elements from the delegate and sort them in some
way. Other workaround is to provide a look which creates something
like PropertySetBase which would be analogous to ActionBase in default
look and would allowe for sorting PropertySets using filesystem
Comment 3 Petr Jiricka 2003-05-06 09:58:51 UTC
I am not sure I understand the solution/workaround you are 
proposing. I believe the basic scenario for this situation 
is the following:

1. The IDE is visualizing an object using a composite 
look. This look may not even be provided by end-level 
modules, but by infrastructure of some kind (IDE code, 
Projects etc.)
2. Modules are plugging sub-looks to this composite look. 
So the Java module may add a sub-look which has 
the "compile" action, and the VCS module may add a sub-
look which has the "check in" action. These modules may or 
may not depend on each other.
3. Now _someone_ needs to specify that e.g. "compile" 
should be in the popup menu before "check in".

I believe this bug is about allowing to specify such 
ordering information at some level. This should be simpler 
than by creating a bridge Java-VCS module with its own 
filtering look implementation, which puts the actions in 
the correct order. Can we invent some *simple* way to 
cater for the scenario above ?

Comment 4 Petr Hrebejk 2003-05-06 15:00:25 UTC
The problem I see here is who is the _someone_ who will decide
how the elements should be ordered. This can hardly be Looks SPI.

Registering a Look in layer and allowing other modules to plug in
own looks represents some kind of API of the module which owns the
CompositeLook, LookSelector or what ever. In case that it is not 
necessary to allow other modules to plug in the module developer
should create all the Looks and Selecors in java. In this case he is
responsible for all the ordering. In case that there is a need for 
other modules to plug in. The module developer can still publish a 
CompositeLook and throw an Filter over it in Java. This of course 
means that he needs to know how to sort the things. Yes sure, he 
usualy does not. Then in case that the actions, properties or other
elements should be sorted somehow. The module which exposes the 
Look as API has to expose other folder or other kind of API where
modules will explicitely state out how to sort things. 
I know that it sounds strange but this is a tax for modularity. It's
the same problem as sorting Loadres, ToolsActions etc. I have no 
magic solution for this problem right now. Maybe we could add some
generic SortByFolder Look, but I don't want to do it until I see 
that it would really help and until I can imagine how to do it