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.
>
------------------------------------------------------------------------------
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
