I like the direction your ideas are heading. We have not used Functor
before - instead returning features to the user that they can then "fill
in" with appropriate values. Trusting they are filled in before commit() is
called.
One question for you is the handling of Commit. A WFS Commit operation is
supped to return the FeatureIds of any content that was created during the
Transaction.
In GeoTools each addFeature operation returns a java.util.List<FeatureId>.
These FeatureId instances are updated with their actual value when
Transaction.commit() is called - we also send out a BatchFeature events (so
that any user interfaces can be advised on the change).
It would help me figure out your API suggestion if you could provide a code
example of how it is used. Here is is a link to our code examples used for
the original API.
http://docs.geotools.org/latest/userguide/library/main/feature.html
Jody Garnett
On Tue, Sep 16, 2014 at 5:53 AM, Falko Bräutigam <fa...@polymap.de> wrote:
> Thanks Jody, for your reply.
>
> I would raise a bug but currently I'm still trying to figure the ideas
> behind
> the API. To get things going I make a proposal about API changes. The idea
> is
> not to actually change things but to have something to discuss about.
>
> ----
> So, basic idea of my proposal is to have an explicite and clear
> create-modify-update API.
>
> Currently the *FeatureStore* looks like this:
>
> public interface FeatureStore extends FeatureSource {
> ... addFeatures(FeatureCollection<T, F> collection) ...
> ... modifyFeatures(AttributeDescriptor[], Object[], Filter) ...
> }
>
> These are different concepts to create(add) and to modify features.
> addFeature()
> forces the store to take an ordinary Feature and translate it into
> whatever the
> backend needs to create all of its properties. In contrast to
> modifyFeature()
> which works on property level and so leaves this responsibility to the
> client
> programm.
>
> Consider the following:
>
> public interface FeatureStore extends FeatureSource {
> /**
> * Creates a new feature in this store.
> *
> * @param id Feature id, or null.
> * @param initializer Functor that allows to init non-nillable
> values.
> */
> Feature createFeature(id, initializer) throws ...
>
> /**
> * Modifies the given Features.
> *
> * @throws IOException If feature does not exist.
> */
> void updateFeatures(FeatureCollection collection) throws ...
> }
>
> Foremost this delegates the problem of identifying complex/collection
> properties
> to the store (which is a good idea IMO). Besides it is symmetric between
> create
> and update. And it is easier(?) to use for the client.
>
> Likewise *Feature* (ComplexAttribute):
>
> public interface ComplexAttribute extends Attribute {
> /**
> * Creates a Property for the given name.
> *
> * @param initializer Functor that allows to init non-nillable
> values.
> * @throws IllegalArgumentException If 'maxoccurs' exceeded.
> * @throws IllegalArgumentException If the name does not exists
> in the
> * FeatureType.
> */
> createProperty(Name name, Initializer initializer);
>
> /**
> *
> * @return The collection of properties which match the specified
> name,
> * or an empty collection if no such properties match.
> * @throws IllegalArgumentException If the name does not exists
> in the
> * FeatureType.
> */
> getProperties(Name);
>
> /**
> *
> * @return The value of this property, or null!!!
> * or an empty collection if no such properties match.
> * @throws IllegalArgumentException If the name does not exists
> in the
> * FeatureType.
> */
> getProperty(Name);
> }
>
> Now there is a clear factory for properties. This allows to let
> getProperty()
> return null if its value is null (not-initialized).
>
> Ideas:
>
> - Semantic of methods is clear for both primitive and complex values. All
> the
> questions about semantic and how to work with complex features are solved
> with
> this API.
>
> - Creating a Feature in the store is very similar to creating a
> ComplexAttribute
> member inside the Feature. Easier to work with.
>
> - Having the Store being the factory of Features and ComplexAttributes
> makes it
> much easier to use store dependent Feature implementations. Very important
> IMO.
>
> - Droping addFeature() in favour of create/modify gives the programmer a
> better
> idea of the identity of a feature. addFeature() sounds like one can
> transfer a
> feature from store A into store B - which is not true as ID changes in
> almost
> all cases.
>
> Jody and all, it would be really great if you could check this, comment
> and/or
> complain mistakes and/or any misunderstanding of the API.
>
> Thanks!
>
> -Falko
>
> Am 12.09.2014 09:07, schrieb Jody Garnett:
> >
> > maybe and hopefully someone can help me with the following questions
> regarding
> > complex features and properties.
> >
> > Question: What is the semantic of: feature.getProperty("foo") ==
> null ?
> >
> > 1.: the property is not initialized
> > 2.: the property is not initialized *or* it does not exist in the
> type at all
> >
> >
> > If the property did not exist ... it would not be there. The fact that
> you see a
> > property (with a null value) probably indicates something like
> > <foo/> is present in the XML. You could consider that significant for
> your
> > application? I am not sure ...
> >
> > Keep in mind that not a lot of people do this stuff yet (most of use use
> simple
> > features) - and thus you may find our library inconsistent with the GML
> > specification (if so raise a bug) or inconsistent with itself (if so
> raise a bug!).
>
> --
> Falko Bräutigam
> http://polymap.org/polymap3
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> GeoTools-GT2-Users mailing list
> GeoTools-GT2-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
