Does using the wicket feedback system tie us to only doing configuration
in a Wicket UI? There are other places (well, RESTConfig is pretty much
it at the moment) where autoconfiguration could be useful. Also, it
feels a little icky having the Catalog tied to the UI this way. An
adapter would be great of course.
(Disclaimer: the FeedbackMessage stuff is one of many parts of Wicket I
haven't really looked at yet)
-David
Justin Deoliveira wrote:
> This is an interesting idea. I like it although I wonder if we could
> just use the wicket Feedback stuff rather than break out our own. At
> first glance the FeedbackMessage class seems to embody this same
> functionality.
>
> David Winslow wrote:
>> I'm not sure doing this directly at the level of exceptions is
>> exactly what we should be doing here. If we want to report some
>> potential problems but continue the operation as normal then
>> exceptions don't really model what we want to do very well. I am
>> thinking we do something like
>>
>> public static class ResourceUtilities {
>> public static class Report{
>> public ReportStatus getSeverity(); // Some indication of how
>> critical the problem was
>> public String getMessage(Locale locale); // A description of
>> what went wrong, readable to users in (locale)
>> }
>>
>> public static class ConfigurationException extends Exception{
>> public List<Report> getReports();
>> }
>>
>> public List<Report> autoConfigure(Catalog catalog, ResourceInfo
>> resource, String layerName); // or whatever parameters make sense for
>> the autoconfiguration operation
>> }
>>
>> This would let us have error messages accessible when things are
>> recoverable, but access them all when there's an exception as well.
>> We could possibly have a Report with status == Report.SUCCESS that
>> wraps up any associated data needed (like the resulting configured
>> layer, for example).
>>
>> -David
>>
>> Justin Deoliveira wrote:
>>> Hmmm... good question. Is there any standard wicket way for i18n'ing
>>> exception messages? Also what does Geotools do. It uses resources
>>> bundles for exception messages like wicket does, perhaps the two
>>> might be compatible?
>>>
>>> Andrea Aime wrote:
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
-------------------------------------------------------------------------
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
