On Fri, May 30, 2014 at 2: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
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
wrote:
> Sambo I was referring to the user experience / workflow :)
>
> I know the SQL view code uses JDBC datastore, but if you could tak
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, S
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
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 <
sampo.savo
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
qu
