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.
From a discussion with Jesse on nbdev: Rochelle Raccah wrote: > > Jesse Glick wrote: > > You can set specific orderings using normal file order attributes. There may > > be a reason to use other relative constraints than alphabetical however, so > > maybe forcing an alphabetical sort is not appropriate. (Anyway alphabetical > > sort by display name is not implemented in FolderOrder, it would probably > > require a change in the Open APIs to support it.) > > I'm talking about a default ordering, not an imposed ordering. If a > specific ordering is set using the normal attributes, that should be > used. Is that possible or is it required that all ordering is specified > or arbitrary? I think it would be possible, provided that FolderOrder were changed to support it as an additional option. (There is already Sort by Name but this uses DataObject name, not nodeDelegate name.) It would make FolderOrder dependent on the Nodes API which might be undesirable however, and also there might be threading issues involved with a datasystems-only function calling into the nodes mutex. In principle it should be possible.
I think this belong to loaders package.
A further discussion with Jesse on nbdev: > > Which is a good argument for not making such a sort mode - it > > would vary by locale, possibly causing additional constraints > > used with it to fail only in certain locales, a nightmare to test. > > And I thought laziness was the only reason not to implement it! > > :-) > > Well, no, that's not what I meant. If I *do* explicitly specify > ordering in my layer in a way that causes the result to be > alphabetical, then in another locale it won't be alphabetical > anymore. This is an argument *for* the default ordering to be > alphabetical where the default locale is known =). Point taken. You can of course provide localized versions of your layer with different orderings, but this is really clumsy. Maybe the best solution is to have the ability to set an attribute on a folder assignable to Comparator<DataObject> which would provide the sorting mechanism for the folder. Then the APIs would not have to maintain specific implementations (and any bugs associated with them!) but modules could define sorting however they felt appropriate, if they were the providers of the folder. FolderOrder (in the APIs) would only know to call the comparator (and again if the list of files changes). One open question is how to have the comparator listen for other changes in the folder (display names of contained nodeDelegate's, miscellaneous file attributes, ...) and fire changes itself. This might require a special Java-level API, e.g. FolderComparator implements Comparator<DataObject> but has protected addNotify(DataFolder), removeNotify(DataFolder), and fireOrderChange(DataFolder). A possible enhancement for 3.4 if it seems popular. [P.S. thanks for asking the hard questions :-).]
(1) I believe that this issue depends on issue 19076 or that issue 19076 could help to solve problems here - you would not need to call into node mutex (which is really dangerous). (2) the SortMode attribute returns a character right now, small enhancement could be made - if it returns a Comparator, then it is expected that this comparator will be used to sort folder's DataObjects. (3) the SystemFileSystem could be modified to return a special instance of comparator that would use display name by default if no other ordering provided. Last comment is that by doing the (2) and (3) we do not need (1) cause there will be just small change in FolderOrder and rest of enhancements will stay in SFS.
In the absence of #19076, I think the safest thing is to (1) not make this mode the default (it will probably not be as efficient as other modes anyway), (2) if requested then it will have to ask for DataNode's, (3) if there is anything dangerous about asking for the DataNode synch, it will be necessary to ask for display names asynch and then change the folder ordering later. Or for #2 and #3, sort by DataObject.name first - if and when all data objects in the folder have their node delegate created (e.g. user expands that folder in the Explorer), then collect their display names and resort.
*** Issue 12229 has been marked as a duplicate of this issue. ***
Set target milestone to TBD
Changed owner David S. -> David K.
Changing TM to FUTURE for several DataSystem enhancements. The DS are planned for rewrite and so it does not make sense to invest time into these enhancements. If you think the issue is important and should be fixed for 4.0 then feel free to let me know. I'm open to change the plan.
Well, I think a corresponding facility should be implemented in the Registry.
If I understood this issue well what Rochelle needs is this: be able to declare that items in a folder in a module layer should be ordered alphabetically according to locale in which the NB runs. So for example <folder name="a"> <file name="chaos.111"/> <file name="crack.111"/> </folder> folder "a" in English locale is already ordered, but in Czech locale the order would be "crack.111" and then "chaos.111", because in Czech there is character 'ch' which is after 'c'. Is something more that this needed: <folder name="a"> <attr name="SortAplhabetically" booleanvalue="true"/> <file name="chaos.111"/> <file name="crack.111"/> </folder> where registry would check for presence of "SortAplhabetically" attribute and reorder items if necessary. The presence of this attribute would override partial ordering attributes. User could still customize the order in NB which would then override "SortAplhabetically" attribute. The Comporator proposal is of course much more powerful, but also pretty complicated and at the moment I'm not sure it is needed.
<attr name="sortAlphabetically" booleanvalue="true"/> sounds OK as a simple solution. I would say that relative ordering constraints should take precedence over this rather than vice-versa, though; consider the Help menu: Users' Guide ---------------- Aardvark Support Module Mudpiper Support Module Zebra Support Module ---------------- Ant 1.5.3 Reference Manual Xalan 2.4.1 Reference Manual you would like to have the following attrs on the folder: - UG before sep-1 - * Support Module after sep-1, before sep-2 - * Reference Manual after sep-2 - otherwise alphabetical Of course this is just one way to arrange things, but something is needed.
OK, make sense. Are there some usecases which this simple solution does not solve?
Use cases I know of: Help -> Help Sets submenu: needs to be split into sections, alpha ordering within each section Actions subfolders: simple alpha ordering in each Templates: a couple of top-level items (e.g. Folder) need to be at the top (could be after an invisible marker file), followed by the rest in alpha order; order within each subfolder is simple alpha.
Except that I asked for this to be the default, not need to be specified explicitly. Also, I'd like to see specified how the layer would be merged if files and folders come from different layers. Which sorting (or lack of sorting) is used?
"Except that I asked for this to be the default, not need to be specified explicitly." - I have to disagree. The great majority of folders do not need any sorting, or do not want alphabetical sorting, and adding it introduces definite overhead - not so much the sort itself which is probably cheap, but the finding of the display names. It is simple enough to specify the sort mode with one attribute, and most modules would not be doing this anyway - only if you are providing the entire folder. Perhaps if it can be demonstrated that default alpha sorting imposes no perceptible overhead in case there are no defined display names (i.e. display name == file name in layer) this would be reasonable. "Also, I'd like to see specified how the layer would be merged if files and folders come from different layers. Which sorting (or lack of sorting) is used?" - should not make any difference which layer a file comes from. The layers are first merged all together, then the folder is sorted. BTW another interesting "anti-use case" I forgot: the Tips of the Day folder in usersguide. This needs to be sorted in a fixed order, but it is not alphabetical in any way (unless you artifically name every file e.g. "aa_welcome.html" through "zz_goodbye.html"). There is another open RFE somewhere for making it easier to specify a fixed ordering for a longish list of files in a folder, e.g. having it default to the order in the XML layer if you request that. These use cases should be considered too, since the Registry's folder ordering mechanisms ought to handle the common cases with a simple syntax.
I'm not sure I understand. Let's say the java module defines a folder in the Templates folder called Java Classes and doesn't define sorting. Then, in my module, I add a template to that folder and turn sorting on. Are you saying the whole Java Classes folder will be sorted because my module requested it? I think that's confusing!
"Let's say the java module defines a folder in the Templates folder called Java Classes and doesn't define sorting. Then, in my module, I add a template to that folder and turn sorting on. Are you saying the whole Java Classes folder will be sorted because my module requested it?" - yes. "I think that's confusing!" - well the java module would be at fault for not turning on sorting to begin with, under the assumption that all template folders generally are displayed to people and should be sorted; and your module would be at fault for adding sorting to a folder it did not define, as well as for failing to report the problem to the owner of the java module.
But why design something into the system which could cause this confusion? I think we should search for a solution which would only allow the owner of the folder to specify sorting.
If not absolutely critical - wontfix. One of the new reasons is issue 46900 where we need to do the sorting based on FileObject and be fast and we cannot create node for it and sort then.
Before deciding not to implement, I would like to solicit comments from HIE/I18N/L10N folks on how this impacts the different locales.
This issue had *1 votes* before move to platform component