Hi,
I'm working on some code that should auto configure a
feature type or a coverage. The code can fail for a number
or reasons, and should be usable for both REST and the
web UI.
The thing is, for REST an exception in english probably
does the trick, but for the web UI we want to report
the user why the auto-configuration failed, which means
simply thorwing an exception does not cut it... or else,
it might, but we'd need to be able and get an i18n key
as well as its eventual parameters (complex messages might
need MessageFormat like parametrization).
On the same line we might want to report back warnings,
stuff like "I could not figure out what the heck this
CRS is, so I kept it and forced an on the fly reprojection
to 4326 for data publishing".
Now for the warnings the thing could be that the auto
configure method does not return a simple result, but
returns an "auto configuration processor" that allows
you to call auto-configure and get back the resource,
and then call for warnings.
I could do the same for exceptions in this case, return
null from the main path and have a method that returns
the error messages.
But... I'm more interested in seeing if we can come
up with a general solution, since this problem
might come up in other situations as well.
Is it a good idea to add the exceptions a getKey()
and getParam() -> Object[] methods. Should we come
up with something able to turn an exception into
a localized message instead (pluggable tranformer)?
Or do you feel I'm just overdoing this, and we should
just report back the user it's not his lucky day
without details on the why?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
