See my answers inline:
Am 20.10.2022 um 13:05 schrieb Andrea Aime:
On Tue, Oct 18, 2022 at 7:28 AM Carsten Klein <c.kl...@datagis.com> wrote:
Hello Andrea,
prior to porting back, I'd like to make another change. I'd like
to have a context/storage to share data between methods
encodeSimpleFeatures and writeExtraCollectionProperties. This is
at least a requirement for building and serializing a shared
string table.
What do you need it for?
All features and their data are iterated in encodeSimpleFeatures. That's
where I build the Shared String Table. I need this table in method
writeExtraCollectionProperties, since that table needs to be serialized
as a collection property. Also, I could collect schema information
(property names and geometry name) in encodeSimpleFeatures. Having this
data available in writeExtraCollectionProperties as well, will simplify
the implementation of method writeExtraCollectionProperties significantly.
Since there is no dedicated instance of the ...GetFeatureResponse
class per request, using `this` is likely not an option. (If a
single instance of the class is guaranteed to be used for a single
request, that is while the write method has not yet finished, this
could nonetheless be done safely but that may be bad practice). Or
am I wrong here? At least I did not see a constructor call for
every request...
What other options do I have? The simples would be (with the
fewest changes in existing code) to wrap/extend the GeoJSONBuilder
class (which is already passed to all relevant methods) and add a
generic Map<String, Object> storage. By overriding protected
method getJSONBuilder, I could bring my extended class into use.
However, that's still a hack, isn't it?
Or subclass it and add whatever fields you need in the subclass?
Yes, likely the simplest solution is to subclass GeoJSONBuilder and to
add the required fields or a generic Map<String, Object> storage.
However, still think that's kind of abuse, since a JSON builder should
not be (ab)used as a data storage...
Adding such a context storage to class
GeoJSONGetFeatureResponse.FeaturesInfo is another option. However,
then the FeaturesInfo instance should be passed to all (for the
sake of completeness) write... (writeCollectionCounts to
writeExtraCollectionProperties) methods in method
GeoJSONGetFeatureResponse.write.
I'd avoid having signature changes to all these methods (the class is
being subclassed elsewhere).
Good point, such changes are not ideal...
Cheers
Andrea
==
GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for
more information.==Ing. Andrea Aime @geowolfTechnical Lead
GeoSolutions Groupphone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>
http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>
-------------------------------------------------------
Con riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati
“GDPR”), si precisa che ogni circostanza inerente alla presente email
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui
conoscenza è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato
se potesse darmene notizia.This email is intended only for the person
or entity to which it is addressed and may contain information that is
privileged, confidential or otherwise protected from disclosure. We
remind that - as provided by European Regulation 2016/679 “GDPR” -
copying, dissemination or use of this e-mail or the information herein
by anyone other than the intended recipient is prohibited. If you have
received this email by mistake, please notify us immediately by
telephone or e-mail
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel