On Sun, Apr 15, 2012 at 5:12 PM, Gabriel Roldan <[email protected]> wrote:
> On Sun, Apr 15, 2012 at 5:55 PM, Justin Deoliveira <[email protected]>
> wrote:
> > It may be a bit too lax... but that is the general idea. We did the same
> > thing for layers so I kind of just followed that template. As you say the
> > issue is null is kind of ambiguous... does it mean global or does it mean
> > any workspace? I sort of opted to make it mean both since we don;t really
> > expose the concept of an ANY workspace. And it only really takes affect
> in
> > cases where only a single style exists which matches the name.
> >
> > That said I am fine with making it stricter, as I can't think of any use
> > case that doesn't involve going through a virtual service endpoint, and
> that
> > which the right workspace will be forcibly set anyways. So to be clear
> you
> > are advocating for removing the last part of the lookup heuristic? Have
> you
> > tried doing so and see what happens in unit tests?
>
> Find attached the complete patch with the tests expectations that
> needed to be changed.
> I think the check for ANY_WORKSPACE in
> DefaultCatalogFacade.getStyleByName(Workspace, String) should also be
> removed. End goal being having less code that's never gonna be
> executed, as you mentioned, because it is there without a use case
> that hits it.
>
> Well the fact that test assertions are being changed sort of means there
is a use case :)
I am always weary of changing this sort of stuff just for the purposes of
code cleanup. Can you provide more information about how it makes your life
easier to have this removed? Is it strictly just api clarity? Does it make
implementing a new catalog easier?
Anyways, not trying to discourage just trying to be careful. As this is
generally new code shouldn't be a big deal though. Just want to do my due
diligence :)
> Cheers,
> Gabriel
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
