Hi Jody,
Yeah. I knew you meant the UI, not the backend. I just pivoted fast to the
issue at hand :)
Sampo
On Fri, May 30, 2014 at 3:44 PM, Jody Garnett <[email protected]>
wrote:
> Sambo I was referring to the user experience / workflow :)
>
> I know the SQL view code uses JDBC datastore, but if you could take your
> design queues - and even cut and paste some UI code - GeoServer will be
> that much more consistent and easy to use.
>
> Jody Garnett
>
>
> On Fri, May 30, 2014 at 10:26 PM, Sampo Savolainen <
> [email protected]> wrote:
>
>> Hi Jody,
>>
>> Thanks for the tip. It does seem that model could work well in this case
>> as well. However there lies a nasty problem here. The SQL View code relies
>> in many places on the DataStore to be an instance of JDBCDataStore. Like we
>> discussed earlier with Andrea, this is method is slightly dubious because a
>> DataStore might have to be wrapped in a retyping DataStore.
>>
>> Retyping causes headaches with WFS-NG as that happens almost always. As
>> I've understood, retyping is required when colons are used in the localPart
>> of a feature name. Stored query id's will contain colons (the mandatory
>> stored query in WFS 2.0.0 is "urn:ogc:def:query:OGC-WFS::GetFeatureById").
>> Because of the retyping, it's difficult to detect which features are backed
>> by WFS-NG. But even more troubling is the fact that I can't access the
>> underlying store in any sane way.
>>
>> Andrea, you mentioned that you had a plan to refactor the parts affecting
>> this. Is there any movement on this, or should I hack a
>> "getUnderlyingDataStore()" into RetypingDataStore?
>>
>>
>> Sampo
>>
>>
>> On Fri, May 30, 2014 at 2:51 PM, Jody Garnett <[email protected]>
>> wrote:
>>
>>> I may be late to the conversation, I would expect it to be handled in a
>>> consistent fashion to the sql view (
>>> http://docs.geoserver.org/stable/en/user/data/database/sqlview.html) as
>>> these are both "data binding" problems.
>>>
>>> Jody Garnett
>>>
>>>
>>> On Fri, May 30, 2014 at 5:37 PM, Sampo Savolainen <
>>> [email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm now looking into exposing the stored query parameter configuration
>>>> to the administrator configuring the layer derived from a stored query.
>>>>
>>>> To recap: this configuration relates to how the stored query parameters
>>>> are constructed from viewparams in a request and a context derived from the
>>>> query filter (access to query filter bounds, etc).
>>>>
>>>> First of all we should decide where to put the UI. To me there are two
>>>> logical options:
>>>> 1) In the layer configuration "Data" tab under feature type details
>>>> 2) As a new tab in the layer configuration view
>>>>
>>>> I'd vote for 1) because this is practically mandatory configuration.
>>>> Without this configuration, the layer would require clients to provide all
>>>> required viewparams to get any meaningful data out of the layer.
>>>>
>>>> The UI would list all parameters supported by the stored query and
>>>> offer a choice for each one. The choice would be either: 'No default',
>>>> 'Static value', 'Expression'. Selecting either of the last two options
>>>> would display an input box or textarea respectively for the user to fill in
>>>> the static value or expression value.
>>>>
>>>> Each parameter would also be accompanied by a checkbox to configure
>>>> whether the user may override the configured value via a viewparams option
>>>> or not.
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>> Sampo
>>>>
>>>> --
>>>> Sampo Savolainen
>>>> R&D Director, Spatineo Oy
>>>> [email protected]
>>>> +358-407555649
>>>> Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
>>>> www.spatineo.com, twitter.com/#!/spatineo
>>>> www.linkedin.com/company/spatineo-inc
>>>>
>>>> This message may contain privileged and/or confidential information. If
>>>> you
>>>> have received this e-mail in error or are not the intended recipient,
>>>> you
>>>> may not use, copy, disseminate, or distribute it; do not open any
>>>> attachments, delete it immediately from your system and notify the
>>>> sender
>>>> promptly by e-mail that you have done so.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Time is money. Stop wasting it! Get your web API in 5 minutes.
>>>> www.restlet.com/download
>>>> http://p.sf.net/sfu/restlet
>>>> _______________________________________________
>>>> Geoserver-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>
>>
>>
>> --
>> Sampo Savolainen
>> R&D Director, Spatineo Oy
>> [email protected]
>> +358-407555649
>> Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
>> www.spatineo.com, twitter.com/#!/spatineo
>> www.linkedin.com/company/spatineo-inc
>>
>> This message may contain privileged and/or confidential information. If
>> you
>> have received this e-mail in error or are not the intended recipient, you
>> may not use, copy, disseminate, or distribute it; do not open any
>> attachments, delete it immediately from your system and notify the sender
>> promptly by e-mail that you have done so.
>>
>
>
--
Sampo Savolainen
R&D Director, Spatineo Oy
[email protected]
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
