commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration] WebConfiguration
Date Tue, 02 Mar 2004 12:18:05 GMT
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:hegero@med.uni-marburg.de]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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:oliver.heger@med.uni-marburg.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message