Right... i was just talking in terms of UI. I am not sure we want to
tackle this sort of scheme outside of the context of the web interface.
I mean i don't think it makes sense for the catalog or some other
internal subsystem to determine if a failed operation was "severe" or
not... i think only the calling code (the ui) can make that decision.
However that still leaves us with the initial problem of localizing
exception messages... I am curious to figure out how other web
applications / servers tackle this problem. Do they:
1. Not localize exception messages which originate from "lower levels"
of the application
or
2. Come up with an interface similar to what Andrea suggested
or
3. Something else
David Winslow wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> !DSPAM:4007,48653b1f286193327367457!
>
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
-------------------------------------------------------------------------
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
