Add a PATCH method endpoint that expects a StylePatchRequest object, and
feel free to tweak it as needed, say,
{
defaultWorkspace: boolean,
workspace: string,
etc....
}
El jue., 25 de jul. de 2019 a la(s) 12:13, Niels Charlier ([email protected])
escribió:
> I have actually found a surprisingly elegant solution.
>
> In the XStream%MessageConverters, I simply do
> XStreamPersister.setUnwrapNulls(false);
>
> this causes an empty tag not to be resolved in the message object (or any
> other tag that contains a non-existing workspace), but leaving a
> ResolvingProxy that is copied along to the modification proxy (since !=
> null). That resolvingproxy is then later resolved to "null" by
> ModificationProxy.commit.
>
> Effectively creating the behaviour that we want: empty tag -> overwrite
> with null ; no tag -> keep the old value. It should be noted that a tag
> with a non-existing workspace also causes an overwrite with null, rather
> than keeping the old value. But to me that seems fair.
>
> Kind Regards
>
> Niels
> On 23/07/2019 15:56, Niels Charlier wrote:
>
> it would have to be
>
> static final WorkspaceInfo GLOBAL_WORKSPACE = new WorkspaceInfoImpl()
>
> because workspace is an info object, not a String.
>
> I think something like that as a work-around might work, but is dodgy/ugly
> for several reasons.
>
> If this dummy object somehow got through to the actual persisted catalog,
> it would be rather problematic. As mentioned, global workspace == null
> there, and that workspace doesn't have an ID or not a real one. This is
> confusing as well.
>
> And we would have to put a bunch of ugly IF's in both the message
> converter as well as the method that copies the message object into the
> persisted object.
> On 23/07/2019 15:34, Jody Garnett wrote:
>
> Could we define a static final String GLOBAL_WORKSPACE = "" internally to
> represent <workspace/> ?
>
> Can we use the empty string <workspace><workspace/> to represent "change
> me"?
> --
> Jody Garnett
>
>
> On Tue, 23 Jul 2019 at 06:19, Niels Charlier <[email protected]> wrote:
>
>> I prefer 3 too, but the main problem with all three suggestions is also
>> one of the implementation kind.
>>
>> The XML/Json is parsed by the configured "XStream%MessageConverter", and
>> converter to a StyleInfo object, which the REST controller receives.
>>
>> The REST controller has therefore no way of knowing whether the workspace
>> tag is present or not, because in both cases workspace = null.
>>
>> How can we even make a difference in the StyleInfo object between "don't
>> change me" and "set this to null"? In particular, knowing that null means
>> "global" when we are talking about a persisted style, but "don't change me"
>> in the context of a REST message.
>>
>> Regards
>>
>> Niels
>> On 23/07/2019 15:06, Jody Garnett wrote:
>>
>> May need to introduce a change, even a documentation change.
>>
>> 1) Marker string of some sort - any suggestion seems bad: "(global)"
>> 2) Change the REST API assumption so that workspace is considered null if
>> not provided.
>> 3) For XML ideally we should use an empty <workspace/> tag - I think that
>> is the most explicit (although I do not know what that looks like in JSON).
>>
>> I think option 3 is the most explicit and the least disruptive, we can
>> discuss in today's meeting.
>> --
>> Jody Garnett
>>
>>
>> On Tue, 23 Jul 2019 at 05:38, Niels Charlier <[email protected]> wrote:
>>
>>> Does anyone have any suggestions on making it possible the change the
>>> workspace back to null using REST?
>>>
>>> I found some more issues with the style rest service, see
>>>
>>> https://osgeo-org.atlassian.net/browse/GEOS-9293
>>> On 23/07/2019 14:18, Niels Charlier wrote:
>>>
>>> https://github.com/geoserver/geoserver/pull/3672
>>> On 18/07/2019 11:42, Andrea Aime wrote:
>>>
>>> On Thu, Jul 18, 2019 at 11:22 AM Niels Charlier <[email protected]> wrote:
>>>
>>>> What if it was still empty but we made sure that the line has a normal
>>>> height? Maybe just css or passing a string with a space " " ?
>>>>
>>>
>>> Works too. I've tried to pass a string with a space, did not work, but I
>>> was just fumbling with it past working hours.... so I suggest
>>> you try that again. CSS sounds like a promising avenue too
>>>
>>> Cheers
>>> Andrea
>>>
>>> ==
>>>
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>>> http://www.geo-solutions.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
>>> [email protected]https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>
> _______________________________________________
> Geoserver-devel mailing
> [email protected]https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Gabriel Roldán
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel