Hi all,
For the geosync project, we need to create an rss feed which contains the wfs:Transaction objects which get executed against a particular feature type.
This should be pretty straight forward, as a first shot we intend to simply register a transaction listener, and then serialize the "Events" into an rss feed.
It would be incredibly convenient for us if the transaction event contained the original transaction object, one of:
UpdateElementType
InsertElementType
DeleteElementType
RollbackElementType
So I would like to add the following method to TransactionEvent:
Object getSource();
Does anyone have any objections to this?
Also, a side note. The TransactionListener interface currently looks like:
void dataStoreChange(TransactionEvent event) throws WFSException;
the term "dataStore" in the method does not quite fit... would not something like:
void handleTransaction(TransactionEvent ... );
make more sense? Not a big deal i know but you know me, i cant give up an opportunity to be anal about a method name ;).
-Justin
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin this is the same as the feature event model; did you want to combine forces and only debug this once?
You will also find you are missing some information I think you need - namely the generated feature ids.
Do you get my earlier feedback about the geosync project? I don't want to repeat myself if it was not useful the first time.
Jody
Hi all,
For the geosync project, we need to create an rss feed which contains the wfs:Transaction objects which get executed against a particular feature type.
This should be pretty straight forward, as a first shot we intend to simply register a transaction listener, and then serialize the "Events" into an rss feed.
It would be incredibly convenient for us if the transaction event contained the original transaction object, one of:
UpdateElementType
InsertElementType
DeleteElementType
RollbackElementType
So I would like to add the following method to TransactionEvent:
Object getSource();
Does anyone have any objections to this?
Also, a side note. The TransactionListener interface currently looks like:
void dataStoreChange(TransactionEvent event) throws WFSException;
the term "dataStore" in the method does not quite fit... would not something like:
void handleTransaction(TransactionEvent ... );
make more sense? Not a big deal i know but you know me, i cant give up an opportunity to be anal about a method name ;).
-Justin
Jody Garnett wrote:
Justin this is the same as the feature event model; did you want to combine forces and only debug this once?
I dont understand, how are they related? The transaction listener api i am talking about is geoserver only, not geotools.
You will also find you are missing some information I think you need - namely the generated feature ids.
Do you get my earlier feedback about the geosync project? I don't want to repeat myself if it was not useful the first time.
Jody
Yes, but the geosync stuff we are doing now is *very* prototype. We are pretty much doing the minimum to participate in the ows-5 testbed, and see what it fleshes out. Based on that we can go back and do it "properly".
Hi all,
For the geosync project, we need to create an rss feed which contains the wfs:Transaction objects which get executed against a particular feature type.
This should be pretty straight forward, as a first shot we intend to simply register a transaction listener, and then serialize the "Events" into an rss feed.
It would be incredibly convenient for us if the transaction event contained the original transaction object, one of:
UpdateElementType
InsertElementType
DeleteElementType
RollbackElementType
So I would like to add the following method to TransactionEvent:
Object getSource();
Does anyone have any objections to this?
Also, a side note. The TransactionListener interface currently looks like:
void dataStoreChange(TransactionEvent event) throws WFSException;
the term "dataStore" in the method does not quite fit... would not something like:
void handleTransaction(TransactionEvent ... );
make more sense? Not a big deal i know but you know me, i cant give up an opportunity to be anal about a method name ;).
-Justin
!DSPAM:4007,47d1e3c962212085621377!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
Justin this is the same as the feature event model; did you want to combine forces and only debug this once?
I dont understand, how are they related? The transaction listener api i am talking about is geoserver only, not geotools.
We have the same needs for the events that go out when a commit() and rollback() go out...
You will also find you are missing some information I think you need - namely the generated feature ids.
Do you get my earlier feedback about the geosync project? I don't want to repeat myself if it was not useful the first time.
Jody
Yes, but the geosync stuff we are doing now is *very* prototype. We are pretty much doing the minimum to participate in the ows-5 testbed, and see what it fleshes out. Based on that we can go back and do it "properly".
Fair enough; I was just worried that FeatureId was being ignored in the mix 
But if it is just play time have fun...
Jody