I think the WFS code is probably just a case of having to implement Feature
modification detection at a higher level, since there was no low level
support for it. Modifications to BasicFeature (not AbstractFeatureClass
BTW) would not require a listener to detect changes. Therefor Feature
modification status would always be valid and not depend on the order of
listener invocation.
Larry
On Thu, Apr 2, 2009 at 9:29 AM, Sunburned Surveyor <
sunburned.surve...@gmail.com> wrote:
> Larry wrote: "You missed the point. After loading the layer, with a
> simple boolean it would always be set to true."
>
> This must be due to the attributes being set once when the feature is
> created from the data source when a layer is loaded. I see now that
> your code accounts for this.
>
> It is interesting that the deegree folks tracked changes by using
> Layer listeners, and not by modifying the behavior of Feature. Still,
> I think Larry's modifications might be useful for situations in which
> a Feature object is used outside a Layer. This probably doesn't happen
> in OpenJUMP much, but could happen if you were using the Feature model
> code outside OpenJUMP.
>
> Larry: Could we use layer listeners to implement your change as deegree
> did?
>
> I still like the idea of tracking changes to individual feature
> attributes. That would be one nifty thing about his code. Should I try
> whipping up a modification to the AbstractFeatureClass that works as
> Larry describes? We could have a cool plug-in that selects all
> features in a layer that were modified after loading...
>
> SS
>
> On Thu, Apr 2, 2009 at 6:12 AM, Larry Becker <becker.la...@gmail.com>
> wrote:
> > Hi SS,
> >
> > You missed the point. After loading the layer, with a simple boolean
> it
> > would always be set to true.
> >
> > Larry
> >
> > On Wed, Apr 1, 2009 at 5:34 PM, Sunburned Surveyor
> > <sunburned.surve...@gmail.com> wrote:
> >>
> >> Larry,
> >>
> >> I like your solution to this problem, but I wonder if it is necessary
> >> to track the modifications to all of the attributes. As soon as a
> >> single attribute value has been modified, you could flag the whole
> >> feature as in need of an update.
> >>
> >> In this case our code might look like this:
> >>
> >> // Declare a boolean flag to determine if the feature has been modified.
> >> private boolean isModified;
> >>
> >> public void setAttribute(int attributeIndex, Object newAttribute)
> >> {
> >> // Existing code here.
> >> this.isModified = true;
> >> // Existing code here.
> >> }
> >>
> >> public void setAttributes(Object[] attributes)
> >> {
> >> // Existing code here.
> >> this.isModified = true;
> >> // Existing code here.
> >> }
> >>
> >> public boolean isFeatureModified()
> >> {
> >> return this.isModified;
> >> }
> >>
> >> Your technique would allow us to add a method indicating that an
> >> individual attribute had been modified. This would be useful, but I
> >> think it would only take a single change to trigger a database update.
> >> I suppose there would be a performance penalty if you were needlessly
> >> writing all of the attribute values to a database in a Feature with
> >> many attributes, but it might also slow you down to verify which
> >> attributes to write out. It might be quicker (and easier) to just
> >> write out all the attribute values for a modified feature. There is
> >> probably no way to no without some tests.
> >>
> >> However, I think if we use the technique you mentioned we should add a
> >> method to indicate if a specific attribute value has been modified. We
> >> are doing most of that work anyways. :]
> >>
> >> The Sunburned Surveyor
> >>
> >> On Wed, Apr 1, 2009 at 2:01 PM, Larry Becker <becker.la...@gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > As I mentioned in the other thread, before the problem of partial
> >> > database
> >> > updates can be solved, we must first be able to determine if a Feature
> >> > has
> >> > been modified. This is not currently possible in all of the JUMP
> >> > variants
> >> > that I am familiar with, although Kosmo may have implemented it.
> >> >
> >> > The simplest way of implementing it that I can see is to modify
> >> > BasicFeature
> >> > to include:
> >> >
> >> > private int[] attributeModCount; //this is a parallel array to
> Object[]
> >> > attributes
> >> >
> >> > Then it would be necessary to allocate the attributeModCount array
> when
> >> > setAttributes(Object[] attributes) is called.
> >> >
> >> > In addition each time setAttribute(int attributeIndex, Object
> >> > newAttribute)
> >> > is called, add the line of code:
> >> >
> >> > attributeModCount[attributeIndex]++
> >> >
> >> > With these modifications we could then define:
> >> >
> >> > public boolean isFeatureModified() {
> >> > for (int i=0; i<attributeModCount.length; i++) {
> >> > if (attributeModCount[i] > 1) //modified is defined as setting
> an
> >> > attribute more than once
> >> > return true;
> >> > }
> >> > return false;
> >> > }
> >> >
> >> > Would this work and does this seem like something we should consider?
> >> >
> >> > regards,
> >> > Larry
> >> > --
> >> > http://amusingprogrammer.blogspot.com/
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Jump-pilot-devel mailing list
> >> > Jump-pilot-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >> >
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Jump-pilot-devel mailing list
> >> Jump-pilot-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
> >
> > --
> > http://amusingprogrammer.blogspot.com/
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
http://amusingprogrammer.blogspot.com/
------------------------------------------------------------------------------
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
