Re: [JPP-Devel] wishlist
Hi, Is the insert fired automatically when a new feature is ready? Just wondering what happens if saving is manual and user has been panning around so that the new feature is outside the current viewport. What about if new feature is originally created outside the current bounding box by inserting WKT into the Add new features box or by copying selected features from other layers? In theory if one feature at a time is inserted it could save whole lot of computing to query just IDs from the bounding box and not at all the geometries. The ID that does not exist on the OpenJUMP side must be the one that was given for the new feature by the database. But I fear it is not reliable because who knows if all the old features from that bounding box were originally on the OpenJUMP layer. When doing inserts through WFS the service is sending back the result (success or not) and the fid of the newly inserted feature but I do not suppose that PostGIS database has any native mechanism for doing this. -Jukka Rahkonen- Kevin Neufeld wrote: I'm programmatically invoking a refresh on the layer - any data currently in the bounding box of the viewport is reloaded from the datastore ... which includes the newly inserted feature. I suppose I could be smarter about this and reload all features whose bounding boxes match the bounding box of the feature just inserted. Then I'd filter all features already in the client's cache, thereby adding one new feature to the FeatureCollection ... but a complete layer refresh is far easier. :) -- Kevin On 9/6/2010 6:31 AM, Rahkonen Jukka wrote: Hi, One further question: How are you going to get the ID of the newly inserted feature back to OpenJUMP side? -Jukka- -- 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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
I was just curious. Exposing this functionality to the user through the GUI might create problems I haven't thought of. Thanks for the clarification Kevin. The Sunburned Surveyor On Wed, Sep 8, 2010 at 4:44 PM, Stefan Steiniger sst...@geo.uzh.ch wrote: Kevin Neufeld wrote: No, the ability to specify readonly is currently only available programatically. My use case was that I wanted to prevent a user to making certain changes to a feature collection. I hadn't considered that a user may want to add this restriction themselves through a user interface. Do you think there is a need? don't know if the user should be able to set it. Lets start with this easy case, as the main idea is to have this functions for databases. However, it is good to expose the info via the GUI that an attribute is not editable - this way people may be aware that attributes can be editable or not and I assume that at some point people would ask for that feature/option if they need it (and pay it ;). my 2 cents -- 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 -- Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
Kevin Neufeld wrote: No, the ability to specify readonly is currently only available programatically. My use case was that I wanted to prevent a user to making certain changes to a feature collection. I hadn't considered that a user may want to add this restriction themselves through a user interface. Do you think there is a need? don't know if the user should be able to set it. Lets start with this easy case, as the main idea is to have this functions for databases. However, it is good to expose the info via the GUI that an attribute is not editable - this way people may be aware that attributes can be editable or not and I assume that at some point people would ask for that feature/option if they need it (and pay it ;). my 2 cents -- 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
Re: [JPP-Devel] wishlist
Hi Jukka, Yes, inserts are more tricky than other modification types. However, IMHO, a properly modeled database will include sequence generators, rules, or triggers on database tables enforcing the primary key attribute. My first iteration through this will be to simply target the most common use case, that is, during an insert operation, specify all attributes except the primary key (whether single or multi-column key) and let the database populate the field(s) automatically. If the attempt fails, then there are options: 1) Do nothing, rollback the transaction and notify the user they are missing sequences on their primary key columns 2) Again, warn the user their database modeling needs work and try the commonly used max(ID) approach to guess the primary key entry (maybe in a confirmation dialog). However, this is definitely not recommended. What if the column is alphanumeric? What's the max(ID) then? What if it's, as you point out, a multiple-key column? Obviously we can't guess that. What if it was intentional that a sequence was not provided? Maybe the table is considered read-only. No, this approach makes assumptions about the datamodel that a viewing/editing tool really should not be making. I think for now, I'm going to stick with simply relying on the the fields to be auto-generated. Cheers, Kevin On 9/4/2010 1:41 AM, Rahkonen Jukka wrote: Hi, How are you going to deal with inserts? And have you considered supporting also other databases than PostGIS (Oracle, Spatialite)? I have been dealing with WFS-T against Oracle and I know that inserts are the most tricky part, especially with Oracle. But it may be tricky even with PostGIS if table has a combined primary key. Perhaps the not-so-recommended Geoserver way could be used? Geoserver selects max(ID) in the beginning of insert, and feeds in ID=(max(ID)+1). It is not recommended because it is not reliable at all if there are many users doing inserts at the same time. The better way is to use triggers but it goes more complicated. -Jukka Rahkonen- -- 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
Re: [JPP-Devel] wishlist
Hi, One further question: How are you going to get the ID of the newly inserted feature back to OpenJUMP side? -Jukka- -Original Message- From: Kevin Neufeld [mailto:kneuf...@refractions.net] Sent: Mon 6.9.2010 9:35 To: OpenJump develop and use Subject: Re: [JPP-Devel] wishlist Hi Jukka, Yes, inserts are more tricky than other modification types. However, IMHO, a properly modeled database will include sequence generators, rules, or triggers on database tables enforcing the primary key attribute. My first iteration through this will be to simply target the most common use case, that is, during an insert operation, specify all attributes except the primary key (whether single or multi-column key) and let the database populate the field(s) automatically. If the attempt fails, then there are options: 1) Do nothing, rollback the transaction and notify the user they are missing sequences on their primary key columns 2) Again, warn the user their database modeling needs work and try the commonly used max(ID) approach to guess the primary key entry (maybe in a confirmation dialog). However, this is definitely not recommended. What if the column is alphanumeric? What's the max(ID) then? What if it's, as you point out, a multiple-key column? Obviously we can't guess that. What if it was intentional that a sequence was not provided? Maybe the table is considered read-only. No, this approach makes assumptions about the datamodel that a viewing/editing tool really should not be making. I think for now, I'm going to stick with simply relying on the the fields to be auto-generated. Cheers, Kevin On 9/4/2010 1:41 AM, Rahkonen Jukka wrote: Hi, How are you going to deal with inserts? And have you considered supporting also other databases than PostGIS (Oracle, Spatialite)? I have been dealing with WFS-T against Oracle and I know that inserts are the most tricky part, especially with Oracle. But it may be tricky even with PostGIS if table has a combined primary key. Perhaps the not-so-recommended Geoserver way could be used? Geoserver selects max(ID) in the beginning of insert, and feeds in ID=(max(ID)+1). It is not recommended because it is not reliable at all if there are many users doing inserts at the same time. The better way is to use triggers but it goes more complicated. -Jukka Rahkonen- -- 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
Re: [JPP-Devel] wishlist
I'm programmatically invoking a refresh on the layer - any data currently in the bounding box of the viewport is reloaded from the datastore ... which includes the newly inserted feature. I suppose I could be smarter about this and reload all features whose bounding boxes match the bounding box of the feature just inserted. Then I'd filter all features already in the client's cache, thereby adding one new feature to the FeatureCollection ... but a complete layer refresh is far easier. :) -- Kevin On 9/6/2010 6:31 AM, Rahkonen Jukka wrote: Hi, One further question: How are you going to get the ID of the newly inserted feature back to OpenJUMP side? -Jukka- -- 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
Re: [JPP-Devel] wishlist
Hi Kevin, Yes, I'm in process of implementing some datastore plugins that will permit the dynamic reading and writing to a database. I wrote a quick hacky plugin many years ago that does this for PostGIS. I want to release this to the community because it seems quite useful, but I'm first tackling a complete code rewrite with a nice UI. I'm currently using a Primary or Unique key to synchronize a database table and OJ's FeatureCollection. If a feature gets modified, I use the key to update the appropriate record in the database. Obviously, mayhem ensues if a user were to modify a feature and it's primary key attribute ... they'd be modifying the wrong record in the database. I see more clearly your intention now. Great addition ! And thanks to plan to release this work to the community. I'm not sure I understand your last comment, can you please elaborate? If the readonly attribute is not cloned, then a deep copy of a FeatureSchema object wouldn't have the same constraints as the original, no? Not sure it makes sense. My first thought was that readonly attribute was readonly in the context of a datastore (identifier or key), but may loose this property in the context of a new local layer created by cloning the schema. But this is probably not a big issue. I now think readOnly property can be cloned as any other. There is probably no major drawback. Michaël -- Kevin On 9/3/2010 2:25 PM, Michaël Michaud wrote: Hi, I just had a look at your patch which seems good to me. I have some questions about it : 1 - Do you plan to improve database connection plugins to prevent modifications on some kinds of database attributes ? 2 - Do you just want to prevent attribute writing throught the LayerTable ? Because if you want a stronger protection (preventing attribute writing from attribute edition plugins, new plugins, scripts) , I think some methods have to be added in the feature implementation (AbstractBasicFeature.setAttribute ? BasicFeature.setAttribute ?) to check if setting a new attribute value is authorized by the feature schema. I'm not sure about setAttributes which is a low level method. What do you think ? Checking before each setAttribute may slowdown the whole process. And if we go this way, I wonder if cloning attributeReadOnly property with the FeatureSchema is necessary. What do you think ? Michaël Le 02/09/2010 17:59, Kevin Neufeld a écrit : Patch has been committed at r2034, no problems. Let me know if anyone has issues with the addition. Thanx all, -- Kevin On 9/2/2010 8:29 AM, Sunburned Surveyor wrote: Kevin, You've been added to the Jump Pilot Project on Sourceforge and now have write access to the SVN. You can commit your patch so we get the changes in our nightly build. If you have trouble with the commit, please let me know. The Sunburned Surveyor -- 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
Re: [JPP-Devel] wishlist
Hi, How are you going to deal with inserts? And have you considered supporting also other databases than PostGIS (Oracle, Spatialite)? I have been dealing with WFS-T against Oracle and I know that inserts are the most tricky part, especially with Oracle. But it may be tricky even with PostGIS if table has a combined primary key. Perhaps the not-so-recommended Geoserver way could be used? Geoserver selects max(ID) in the beginning of insert, and feeds in ID=(max(ID)+1). It is not recommended because it is not reliable at all if there are many users doing inserts at the same time. The better way is to use triggers but it goes more complicated. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Kevin Neufeld [mailto:kneuf...@refractions.net] Lähetetty: la 4.9.2010 6:22 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] wishlist Hi Michael, good thoughts. Yes, I'm in process of implementing some datastore plugins that will permit the dynamic reading and writing to a database. I wrote a quick hacky plugin many years ago that does this for PostGIS. I want to release this to the community because it seems quite useful, but I'm first tackling a complete code rewrite with a nice UI. I'm currently using a Primary or Unique key to synchronize a database table and OJ's FeatureCollection. If a feature gets modified, I use the key to update the appropriate record in the database. Obviously, mayhem ensues if a user were to modify a feature and it's primary key attribute ... they'd be modifying the wrong record in the database. So, yes, I'm trying to prevent the modification of certain attributes. Preventing attribute writing through the LayerTable seemed like the easiest approach, but I'm definitely open to ideas on how we can make this rock solid. I hadn't considered adding a check to BasicFeature.setAttribute, but it does sound prudent. I'm not sure I understand your last comment, can you please elaborate? If the readonly attribute is not cloned, then a deep copy of a FeatureSchema object wouldn't have the same constraints as the original, no? -- Kevin On 9/3/2010 2:25 PM, Michaël Michaud wrote: Hi, I just had a look at your patch which seems good to me. I have some questions about it : 1 - Do you plan to improve database connection plugins to prevent modifications on some kinds of database attributes ? 2 - Do you just want to prevent attribute writing throught the LayerTable ? Because if you want a stronger protection (preventing attribute writing from attribute edition plugins, new plugins, scripts) , I think some methods have to be added in the feature implementation (AbstractBasicFeature.setAttribute ? BasicFeature.setAttribute ?) to check if setting a new attribute value is authorized by the feature schema. I'm not sure about setAttributes which is a low level method. What do you think ? Checking before each setAttribute may slowdown the whole process. And if we go this way, I wonder if cloning attributeReadOnly property with the FeatureSchema is necessary. What do you think ? Michaël Le 02/09/2010 17:59, Kevin Neufeld a écrit : Patch has been committed at r2034, no problems. Let me know if anyone has issues with the addition. Thanx all, -- Kevin On 9/2/2010 8:29 AM, Sunburned Surveyor wrote: Kevin, You've been added to the Jump Pilot Project on Sourceforge and now have write access to the SVN. You can commit your patch so we get the changes in our nightly build. If you have trouble with the commit, please let me know. The Sunburned Surveyor -- 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
Re: [JPP-Devel] wishlist
Hi Michael, good thoughts. Yes, I'm in process of implementing some datastore plugins that will permit the dynamic reading and writing to a database. I wrote a quick hacky plugin many years ago that does this for PostGIS. I want to release this to the community because it seems quite useful, but I'm first tackling a complete code rewrite with a nice UI. I'm currently using a Primary or Unique key to synchronize a database table and OJ's FeatureCollection. If a feature gets modified, I use the key to update the appropriate record in the database. Obviously, mayhem ensues if a user were to modify a feature and it's primary key attribute ... they'd be modifying the wrong record in the database. So, yes, I'm trying to prevent the modification of certain attributes. Preventing attribute writing through the LayerTable seemed like the easiest approach, but I'm definitely open to ideas on how we can make this rock solid. I hadn't considered adding a check to BasicFeature.setAttribute, but it does sound prudent. I'm not sure I understand your last comment, can you please elaborate? If the readonly attribute is not cloned, then a deep copy of a FeatureSchema object wouldn't have the same constraints as the original, no? -- Kevin On 9/3/2010 2:25 PM, Michaël Michaud wrote: Hi, I just had a look at your patch which seems good to me. I have some questions about it : 1 - Do you plan to improve database connection plugins to prevent modifications on some kinds of database attributes ? 2 - Do you just want to prevent attribute writing throught the LayerTable ? Because if you want a stronger protection (preventing attribute writing from attribute edition plugins, new plugins, scripts) , I think some methods have to be added in the feature implementation (AbstractBasicFeature.setAttribute ? BasicFeature.setAttribute ?) to check if setting a new attribute value is authorized by the feature schema. I'm not sure about setAttributes which is a low level method. What do you think ? Checking before each setAttribute may slowdown the whole process. And if we go this way, I wonder if cloning attributeReadOnly property with the FeatureSchema is necessary. What do you think ? Michaël Le 02/09/2010 17:59, Kevin Neufeld a écrit : Patch has been committed at r2034, no problems. Let me know if anyone has issues with the addition. Thanx all, -- Kevin On 9/2/2010 8:29 AM, Sunburned Surveyor wrote: Kevin, You've been added to the Jump Pilot Project on Sourceforge and now have write access to the SVN. You can commit your patch so we get the changes in our nightly build. If you have trouble with the commit, please let me know. The Sunburned Surveyor -- 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
Re: [JPP-Devel] wishlist
Hi Kevin, I had a look at your patch. It looks pretty good to me. Nice addition! regards, Larry On Thu, Sep 2, 2010 at 12:31 AM, Kevin Neufeld kneuf...@refractions.netwrote: Hi Stefan, You're right, I once did have write access to the old JUMP ... that was a long time ago. I'm surprised you remembered :) Sure, if you're willing, I wouldn't mind having access again. I'm not planning on any major core contributions, but in my spare time as I'm working on various plugins, I occasionally come across some minor things that could get cleaned up. I agree that commits to the core should first have the eyes of those that know the code inside and out. So, if you're willing, my account is kdneufeld. Have a good trip, Stefan! -- Kevin On 9/1/2010 8:58 PM, Stefan Steiniger wrote: Hei Kevin, do you want SVN write access? so this way we do not need to sent patches around, and I think you did already a couple of contributions (on the good old JUMP-cvs before it was gone. So there would be no concern about your skills ;) However, if core features are concerned we usually have Larry or Michael testing it before a commit is done. (sorry guys, but indeed Larry and Michael are THOSE who know and have the skill ;) For giving you write access we (Michael, Landon or I) would need your SourceForge account login name - thats all. stefan Kevin Neufeld schrieb: 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=detailaid=3057748group_id=118054atid=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
Re: [JPP-Devel] wishlist
Kevin, If Stefan hasn't beat me to it, give me your Sourceforge user name and I'll get you write access to the SVN. Thanks for testing the patch Larry. Landon On Thu, Sep 2, 2010 at 6:37 AM, Larry Becker becker.la...@gmail.com wrote: Hi Kevin, I had a look at your patch. It looks pretty good to me. Nice addition! regards, Larry On Thu, Sep 2, 2010 at 12:31 AM, Kevin Neufeld kneuf...@refractions.net wrote: Hi Stefan, You're right, I once did have write access to the old JUMP ... that was a long time ago. I'm surprised you remembered :) Sure, if you're willing, I wouldn't mind having access again. I'm not planning on any major core contributions, but in my spare time as I'm working on various plugins, I occasionally come across some minor things that could get cleaned up. I agree that commits to the core should first have the eyes of those that know the code inside and out. So, if you're willing, my account is kdneufeld. Have a good trip, Stefan! -- Kevin On 9/1/2010 8:58 PM, Stefan Steiniger wrote: Hei Kevin, do you want SVN write access? so this way we do not need to sent patches around, and I think you did already a couple of contributions (on the good old JUMP-cvs before it was gone. So there would be no concern about your skills ;) However, if core features are concerned we usually have Larry or Michael testing it before a commit is done. (sorry guys, but indeed Larry and Michael are THOSE who know and have the skill ;) For giving you write access we (Michael, Landon or I) would need your SourceForge account login name - thats all. stefan Kevin Neufeld schrieb: 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=detailaid=3057748group_id=118054atid=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
Re: [JPP-Devel] wishlist
Patch has been committed at r2034, no problems. Let me know if anyone has issues with the addition. Thanx all, -- Kevin On 9/2/2010 8:29 AM, Sunburned Surveyor wrote: Kevin, You've been added to the Jump Pilot Project on Sourceforge and now have write access to the SVN. You can commit your patch so we get the changes in our nightly build. If you have trouble with the commit, please let me know. The Sunburned Surveyor -- 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
[JPP-Devel] wishlist
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
Re: [JPP-Devel] wishlist
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
Re: [JPP-Devel] wishlist
Ah, great, thanx Stefan. I'll add the requests there so others can comment/poke holes/massage/scrap the ideas. Yeah, OJ is by far my preferred desktop GIS client. The fact that OJ is so tightly coupled with JTS (which is the backbone of PostGIS through GEOS) makes it great to work with. Cheers, Kevin On 9/1/2010 11:48 AM, Stefan Steiniger wrote: 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 -- 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
Re: [JPP-Devel] wishlist
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
