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.
| Summary: | Ordering of results in ProxyLook/CompositeLook | ||
|---|---|---|---|
| Product: | contrib | Reporter: | _ rkubacki <rkubacki> |
| Component: | Looks | Assignee: | Petr Hrebejk <phrebejk> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | blocker | CC: | pjiricka |
| Priority: | P3 | ||
| Version: | 3.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | TASK | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 18177 | ||
|
Description
_ rkubacki
2002-01-11 15:50:41 UTC
Set target milestone to TBD 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 attributes. 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 ? 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 right. |