Hei Kevin, thanks for you thoughts. Sounds all pretty reasonable to me - the only issue is "developer time" ;)
In general we have at SourceForge the Bug Tracker and Feature-Request Tracker. So that would be the place to add your 3 wishes: http://sourceforge.net/projects/jump-pilot/support We actually had also a TODO.txt file in the trunk, but it is not used. thanks again, and its actually nice to know that Refractions-Folks besides Martin is still interested in OJ development :) cheers from Calgary to Victoria stefan Kevin Neufeld wrote: > Stefan mentioned that there isn't a road map for OJ, but is there a > place to jot down improvement ideas? > > Here are a couple on my wishlist: > > 1) The ability to specify which columns are editable in an layer's > attribute table. Right now, the FID and geometry column are hard-coded > as being the only columns that are not editable. I would like to see > this driven off the layer's FeatureSchema. Perhaps there could be a > "isAttributeReadOnly(int attributeIndex)" method added to the > FeatureSchema that could be used in LayerTableModel.isCellEditable(int > rowIndex, int columnIndex). > > Primary key attributes that belong to a DynamicFeatureCollection driven > off a database is one example of a non-editable column. > > > 2) The ability to customize the tooltips for previously installed > plugins on a layer's right click context menu. For example, I could > have a custom implementation of a Layer that is backed by a custom > FeatureCollection. If I mark the layer as readonly, the "Editable" menu > item is correctly greyed-out. The tooltip says something like "This > layer cannot be made editable." The menu item is greyed-out ... > obviously it's not editable. I would like to change the tooltip to > explain *why* the menu item is greyed-out ... which is particular to my > custom FeatureCollection. > > IE. > "No Primary Key found on the underlying database table" > "Adhoc queries cannot be made editable" > "SQL Server DataStores cannot currently be made editable" > > > 3) A new UpdatablePlugIn interface with methods like getPluginVersion(), > getPluginURL(). All implementations of the interface could be listed in > the extensions tag in the About window. A user could choose to update a > selected plugin where a new plugin jar and all the jar's dependencies > would automatically download, available upon application restart. I > know, I know. This would require a huge framework and lots of developer > time, but it sure would be nice to have. > > > Cheers, > -- Kevin > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
