On Wed, Aug 10, 2016 at 7:52 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
> *Divergence between GSIP and code*
>
> Part of the motivation between getting this particular GSIP in now is so
> that it can be a) included in GeoServer 16-M0 and b) used in the GeoServer
> CSS Styling workshop being presented at FOSS4G Bonn.
>
A "CSS" styling workshop? You mean this one, a YSLD and CSS one?
http://2016.foss4g.org/ws28.html
If that's the case, just a quick reminder about a new functionality. Often
people get tripped by the "cascading" part of CSS, in master there is a
directive one can add to turn off cascading,
and making the CSS more similar in behavior to SLD, see here:
http://docs.geoserver.org/latest/en/user/extensions/css/cascading.html#the-flat-translation-mode
>
> For 1-4, I basically ran out of time to implement them, so it came done to
> the choice of getting something that was a functional improvement to the
> style page completed or having the GSIP languish in a state of perpetual
> incompletion for the next few months.
>
> For 5, that is still in the plan, I just felt it was more sensible to
> remove the CSS Styles page as a seperate commit (I just neglected to
> acutually mention this was the case)
>
That's fine.
>
>
>
> *Documentation updates*
>
> Forgot to consider this, intend to have the documentation updates done
> prior to the 16.0 release, but probably not sooner than that.
>
Normally a GSIP is committed in one shot, proposals in general were
proposed by Jody years ago to ensure that changes have the right
set of resources and never die mid-way because of lack of funding or other
priorities hijacking the developer work.
Committing "half a GSIP" introduces risks, and it might get hard to revert
it if other code builds on top of it (we have had very painful experiences
of that in the GeoTools history).
Long story short, that's now how we have worked in the past few years. I
should probably add this as a clarification in the other discussion about
pull request expected behavior.
> *Serious issues*
>
> A lot of the updatess are a direct port from the CSS page. This brings to
> light some interesting behaviors from the CSS page:
>
The CSS page by itself suffers from a few of the issues I've reported (I
believe the last two, plus the one Kevin reported) and is used by a small
amounts of users. The scope of this GSIP is instead core code used by all
users, and requires a different level of attention and dedication compared
to an optional extension.
Committing it with easy to reproduce hard failures is not the way to go,
nor is blaming existing code because you used it in a different context and
it's not "just working" in it. It was meant to be used sort of a "single
page direct application" thing, it has never been very robust to start
with, at times it's somewhat clunky, has a few known issues, but it's
rather usable nonetheless... at the very least, I had good experiences with
in in various workshop, both with guided and improvised styles. (most of
the bug reports are not about the page, but the translation engine itself).
I actually haven't directly introduced SLD directly in years, it's just too
hard, but used the CSS editor to get people introduced to CSS as the first
styling language, while comparing with the generated SLD and introducing it
as a side effect, to then move to more complex pure SLD cases.
In other words, when I'm running the workshop, it's always this first:
http://geoserver.geo-solutions.it/edu/en/pretty_maps/css.html
and then this:
http://geoserver.geo-solutions.it/edu/en/pretty_maps/styling.html
(And no, in case you were worrying, our workshop always use the maintenance
series, so the changes you're performing on master now are not going to
affect GeoSolutions's workshops in Bonn)
>
> Preview tab mostly useless - The ultimate reason behind this is that the
> Styling page returns to Style list upon submit while the CSS page saves the
> style but stays on the same page. To fix this we can either a) have the
> style page stay on the same page when you click submit or b) add an [apply]
> button that submits the changes without leaving the page (such that we have
> both [apply] and a conventional [submit] button).
>
Agreed, quite similar to what I already proposed in my feedback.
Publishing tab - This is a direct carry-over from the CSS page.
>
In the CSS page that works because all the page is "direct save", creation
included, so the case of style not yet being saved does not happen. When
carrying over code to a different environment and UI workflow you must pay
attention to such differences.
> I agree the behavior is a bit of a surprise, but I don't have a better
> solution that is relatively easy to implement. The only option I came up
> with was to store a model for every layer in geoserver on that tab, which
> seems like a bad idea.
>
Agreed, that would indeed be a terrible idea. A potential one is to only
save the list of deltas, assuming we never allow a "associate with all"
behavior. Mind, implementing it is not trivial, it would be similar to
direct application and you'd probably need to subclass the
GeoServerTablePanel (so that you can override the list of selected items).
I believe the main point making it confusing is that unlike the CSS dialogs
there is a "submit" button at the bottom of the page, which makes one think
it's the usual "edit and then save later" workflow, while the CSS page is
an entirely different beast from the get go.
> Edits lost while switching tabs - this is quite unfortunate (and I'm a bit
> sad that i didn't notice it). Seems like the default tabbed panels don't
> work like I thought and don't preserve content when switching. I just took
> a look at ResourceConfigurationPage and it turns out it uses some sort of
> special workaround to do this.
>
Yep. If memory serves me right the tab panels are "submitting" ones, making
sure the form gets back to the server, is validated, and its state gets
stored.
>
>
> The rest of the hard crashes look to be readily fixible by adding proper
> boundary cases to the setup code. I can add one more crash to that list
> (Kevin found it yesterday afternoon) - If you try do view the layer preview
> when there are no layers in geoserver, you get an NPE (this is another one
> that likely carried over from the existing CSS page).
>
Quite likely.
>
> *Moving Forward*
>
> The style page + some bugfixes will be included in the 16-M0 release, with
> the plan of getting all bugs fixed before the 16.0 release. (Not optimal,
> but not to terrible either).
>
If this is going to be used in workshops, I suggest you include enough to
avoid all hard crashes for the new style, and make sure it's possible to
get instant preview. The crashes with cascaded wms layers or disabled
layers are indeed lower priority and normally controllable in a workshop
environment.
If the M0 is going to be distributed to the public, it's also a good idea
to open tickets for all residual issues, with a "fix for" 16.0, and provide
a list of "known issues" in the announcement, that should avoid duplicate
bug reports.
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
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
