Yes.. I think that in the longer run, the convert code is going to be what we want.. Otherwise the API is going to become larger and larger as we add on more specialized things like Locales etc...
However, the WebConfiguration does have some use cases.. Yes, it is a translater, but if I want to use everything via the Configuration interface, it allows me to merge my webconfiguration with my regular configuration. Oliver, if you want to follow up with the [convert] folks, that would be great.. I am a little reluctant to add a dependency on a sandbox project since we just got out of Sandbox, but that may be worth it. Let's get 1.0 out as it stands. I'll post to find out what exactly the process is. Then, lets add in WebConfiguration, but start looking seriously at how wrappers etc can help us with all this conversion and extension of [configuration]. Eric > -----Original Message----- > From: Oliver Heger [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 02, 2004 7:43 AM > To: Jakarta Commons Developers List > Subject: Re: [configuration] WebConfiguration > > > I also often run in the problem of converting data types and writing > that Integer.parseInt() stuff. It would be very nice to have > a tool that > implements exactly that. I have something in mind that can be wrapped > over a container object, which implements a generic interface (e.g. a > simple getObject() method), and provides other access methods like > getInt(), getString(), getList() etc. > > But I don't think that a configuration object would be the > right place. > This is no configuration issue, but a data conversion issue. > There is a > sandbox project named [convert], which I think goes in this > direction, > but I am not sure what exactly they are doing. > > A large part of the Configuration interface deals with retrieving > properties in different data types, and there are still requests for > additional types (Locale, URL, ...). An alternative for enhancing the > interface more and more could be to use such a "data type conversion > wrapper". > > Do you think this makes sense? Maybe a [convert] developer > can provide > more information? > > Oliver > > Bill Culp schrieb: > > > What about one that's more generic. The WebConfiguration object > > is being used as a type translator for a simple value get. > > > > The technique here would be reflect into and convert type > > > > public void init(ServletConfig config) { > > try { > > MapUtil config = new MapUtil(config, "initParameter"); > > param = config.getInt("param"); > > } catch (NumberFormatException e) {} > > } > > > > > > > > Paul Libbrecht wrote: > > > >> That has ssome good taste... I would add an > "applet-parameter"-based > >> one as well... > >> > >> paul > >> > >> > >> On 1-Mar-04, at 19:02 Uhr, Emmanuel Bourg wrote: > >> > >>> Hi, I'd like to suggest a new configuration implementation that > >>> bridges between parameters commonly used in web applications > >>> (servlet, filter, application and request parameters) and our > >>> Configuration interface. > >>> > >>> Because I'm tired of writting always the same parsing code like: > >>> > >>> public void init(ServletConfig config) { > >>> try { > >>> param = > Integer.parseInt(config.getInitParameter("param")); > >>> } > >>> catch (NumberFormatException e) { } > >>> } > >>> > >>> I tought it would be much easier to write instead: > >>> > >>> public void init(ServletConfig config) { > >>> Configuration conf = new WebConfiguration(config); > >>> param = conf.getInt("param"); > >>> } > >>> > >>> The WebConfiguration works with 4 types of objets > specified in its > >>> constructor: a ServletConfig, a ServletContext, a > FilterConfig or a > >>> ServletRequest. > >>> > >>> I wrote a test case using mock objects covering the > different cases > >>> except for the FilterConfig, the mock lacks a setInitParameter() > >>> method. Also the mock for the ServletRequest sends an > exception for > >>> unknown parameters instead of returning null, most of its > tests break. > >>> > >>> Emmanuel Bourg > >> > >> > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Dipl.-Inform. Oliver Heger > Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren > Klinikum der Philipps-Universit�t Marburg > Bunsenstra�e 3, > D-35037 Marburg > Tel: +49 6421 28-66592 > mailto:[EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
