Hi Nuno, thanks a lot for your feedback, replying to your inputs:
Proposed XML alternative format: >> The XML alternative format will include the following tags: >> - <Layer> : defines a layer parameters, using the same layers order as >> the regular view parameters format. >> > > -1 here, I would recommend not relying on the order, but instead tying a > parameter to a layer based on an XML tag, for example: > > <Layer name="layer1"><Parameter name="mmsi">22,44</Parameter></Layer> > Indeed having explicit layer name makes sense, since we can have layers without parameters and using the name as identification we can set only the ones we want. The updated example: &viewParams=<Layer name="Layer1"><Parameter name="mmsi">538008302,244060802,538008505</Parameter></Layer><Layer name="Layer3"><Parameter name="mmsi">22,44</Parameter></Layer><Layer name="Layer6"><Parameter name="csvInput">acv,rrp;1,0;0,7;22,1</Parameter></Layer> > > - <Parameter> : To be included inside the <Layer> element. Defines a >> parameter on its nested element value, setting its parameter name using the >> "name" attribute. >> >> Example: >> &viewParams=<Layer><Parameter >> name="mmsi">538008302,244060802,538008505</Parameter></Layer><Layer><Parameter >> name="mmsi">22,44</Parameter></Layer><Layer><Parameter >> name="csvInput">acv,rrp;1,0;0,7;22,1</Parameter></Layer> >> > > I'm assuming that the values will then be used as-is in the downstream SQL > query? In terms of XML encoding, this will follow a similar path to other > XML parameters currently support in GeoServer? We will be able to escape > reserved characters, the XML prefix and namespace will be optional? > - Yes the values will be used in the internal SQL query parameters. - Yes we will use the same approach as already existing Filter KVP parsers, layers parsers. - We will use the same escape strategy as current view parameters implementation for all the values. - Yes, the XML prefix and namespace are optional. > >> >> Current format support and backward compatibility: >> The new alternative format will be only activated when a well formed XML >> including the Layer and Parameter tags are provided as value for the >> viewParams URL parameter in the request. >> If this condition criteria is not accomplished, the regular view >> parameter format will be used, respecting backward compatibility and >> regular use cases. >> > > I would suggest adding a new parameter, *viewParamsFormat* to define the > view parameters format explicitly, looks to me like it will be more > efficient than trying each time to parsing n XML The parameter would be > optional, and if not provided the default URL encoding would be used. > > This makes sense and is indeed more efficient. I will add it to the plan making the *viewParamsFormat *parameter optional using the regular view params format as the default (allowing backward compatibility). Example to activate the XML parsing: &viewParamsFormat=xml Regards, Fernando Mino == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Fernando Mino Software Engineer @fmy2kec GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 https://www.geosolutionsgroup.com/ 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. On Mon, Jul 4, 2022 at 4:57 AM Nuno Oliveira < nuno.olive...@geosolutionsgroup.com> wrote: > Hi Fernando, > overall looks like a good addition, but I have a couple of comments, > please see them below: > > On Fri, Jul 1, 2022 at 10:13 PM Fernando Mino < > fernando.m...@geosolutionsgroup.com> wrote: > >> Dear community, >> >> This is an idea proposal to enhance GeoServer view parameters to allow an >> XML format with more complex values definitions without the limit on not >> using reserved characters as the current plain format. >> > >> Current GeoServer view params documentation: >> >> https://docs.geoserver.org/master/en/user/data/database/sqlview.html#using-a-parametric-sql-view >> >> Motivation: >> To have the ability of sending complex values into view parameters, like >> comma separated sublists, semicolon and comma separated inner >> sub-parameters, CSV sets, JSON/XML, etc. >> > > Right, JSON support in RDBS is becoming more and more efficient, and I can > see this being handy to pass down complex JSON expressions. > > >> >> Proposed XML alternative format: >> The XML alternative format will include the following tags: >> - <Layer> : defines a layer parameters, using the same layers order as >> the regular view parameters format. >> > > -1 here, I would recommend not relying on the order, but instead tying a > parameter to a layer based on an XML tag, for example: > > <Layer name="layer1"><Parameter name="mmsi">22,44</Parameter></Layer> > > >> - <Parameter> : To be included inside the <Layer> element. Defines a >> parameter on its nested element value, setting its parameter name using the >> "name" attribute. >> >> Example: >> &viewParams=<Layer><Parameter >> name="mmsi">538008302,244060802,538008505</Parameter></Layer><Layer><Parameter >> name="mmsi">22,44</Parameter></Layer><Layer><Parameter >> name="csvInput">acv,rrp;1,0;0,7;22,1</Parameter></Layer> >> > > I'm assuming that the values will then be used as-is in the downstream SQL > query? In terms of XML encoding, this will follow a similar path to other > XML parameters currently support in GeoServer? We will be able to escape > reserved characters, the XML prefix and namespace will be optional? > > >> >> >> Current format support and backward compatibility: >> The new alternative format will be only activated when a well formed XML >> including the Layer and Parameter tags are provided as value for the >> viewParams URL parameter in the request. >> If this condition criteria is not accomplished, the regular view >> parameter format will be used, respecting backward compatibility and >> regular use cases. >> > > I would suggest adding a new parameter, *viewParamsFormat* to define the > view parameters format explicitly, looks to me like it will be more > efficient than trying each time to parsing n XML The parameter would be > optional, and if not provided the default URL encoding would be used. > > >> >> Implementation hints: >> Before writing the complete plan/proposal I would like to know the >> community feedback about this enhancement idea, but summarizing we should >> have: >> - New KVP parser implementation for XML formatted view parameters. >> - New tests checking this new implementation and checking backward >> compatibility. >> - A new section on GeoServer documentation covering this new format. >> >> Naturally, any feedback to this enhancement is welcome. Thanks!!! >> >> Regards, >> >> Fernando Mino >> >> == >> >> GeoServer Professional Services from the experts! >> >> Visit http://bit.ly/gs-services-us for more information. >> >> == >> >> Fernando Mino >> >> Software Engineer >> >> @fmy2kec >> >> GeoSolutions Group >> phone: +39 0584 962313 >> >> fax: +39 0584 1660272 >> >> https://www.geosolutionsgroup.com/ >> >> 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 >> > > > -- > > Regards, > > Nuno Oliveira > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Nuno Miguel Carvalho Oliveira > @nmcoliveira > Technical Lead / Project Manager > > > GeoSolutions Group > phone: +39 0584 962313 > fax: +39 0584 1660272 > > https://www.geosolutionsgroup.com/ > 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
