[email protected] ha scritto: > Hmm, one parameter for layout AND data access ? > > However, looking at geotools as a library, it is very "unlucky" to > introduce a new parameter passing mechanism. This is surly not what a > developer expects and will cause confusion. And one has to take care to > clean up all the values in the environment properly (specially in the > case of exceptions) to avoid nasty side effects. > > A proposal to bring it under an umbrella. > > Andrea, if you implement the parameter passing using the query objects > and additionally, if a VT misses a parameter, you look up into the > environment. This has an additional effect, giving the caller the > possibility to override environment settings. > > Too make it clear, we offer both possibilities, giving the priority to > parameters passed in the expected manner. If the parameter is not > passed, we look up with EnvFunction. This should work for all of us. > > What do you think ?
I fear it would be worse. If we have one and only one way for both sld and parametrized queries, it's easy, but you may forget that you used the same param name in sld and views. If we have two separate ways, it's clear what goes where instead. But if we have a fallback from one way to the other it may lead to the unexpected issues that the sponsor was trying to avoid (having an SLD param influence the data access) in even more subtle ways, because it would happen only if you did not provide the param value in the query hints. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
