Kevin,

This is probably a dumb question, but is there a way to tell OpenJUMP
that a feature attribute is not editable for a layer through the user
interface?

I was trying to see how I could do this in the dialog that lets you
edit a layer schema in a build from SVN, but couldn't see it. Is this
functionality only accessible programatically right now?

Thanks,

The Sunburned Surveyor

On Wed, Sep 1, 2010 at 8:37 PM, Kevin Neufeld <kneuf...@refractions.net> wrote:
> That is the thing with opensource development, eh? :)  Development
> resources are always tight.
>
> I just added a patch for review to the feature tracker for my primary issue.
> http://sourceforge.net/tracker/index.php?func=detail&aid=3057748&group_id=118054&atid=679909
>
> The patch
> - adds a readonly attribute to a FeatureSchema attribute
> - uses the attribute in the LayerTableModel to set if a cell is editable
> - shades cells in the AttributeTablePanel that are non-editable to light
> gray.
>
> I don't know what OJ uses for a testing harness, but preliminary testing
> looks good.
> I programmatically added a layer and set one of the schema attributes as
> read-only.
>
> The other issues I mentioned are not a big concern for me at all (just a
> wishlist) and I no plans to address them any time soon.
>
> -- Kevin
>
>
> On 9/1/2010 1:34 PM, Michaël Michaud wrote:
>>    Hi Kevin
>>
>> All your propositions seem reasonnable and valuable for OpenJUMP.
>>
>> As Stefan said, the main problem is development resources.
>> I cannot evaluate precisely the work to do without a deeper look, but it
>> concerns core classes and will need caution and tests.
>> Are you volonteer to develop these features ?
>>
>> Michaël
>>
>>
>>
>> Le 01/09/2010 20:15, Kevin Neufeld a écrit :
>>
>>>     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
>>
>
> ------------------------------------------------------------------------------
> 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

Reply via email to