IMHO this vote is going to get really confusing. formally speaking, can a +1 to a vote titled 'Mapper framework in sandbox' really be counted towards a different vote?
can't we have a fresh vote on acceptance straight into the commons with a revised list of initial committers? (i can't propose the vote since i'm not clear who those people would be.) - robert On Thursday, January 17, 2002, at 08:49 AM, Rey Francois wrote: > Sorry, I made a mistake in listing the previous votes. Below is the > correction (switch a and b). > > a: mapper in commons sandbox > b: mapper in commons > > Ted is +1 on b. > Jason is +1 on b. > Jeff is +1 on a, but that was before the suggestion of putting the mapper > in > the commons directly. Jeff, could you please clarify your vote in terms of > option a or b? Thanks. > > Fr. > > -----Original Message----- > From: Rey Francois [mailto:[EMAIL PROTECTED]] > Sent: 17 January 2002 09:45 > To: 'Jakarta Commons Developers List' > Subject: RE: [Vote] Mapper framework in sandbox (was RE: Commons > Validator Packaging/Content) > > > I agree with this list of initial committers. > Since it is proposed as a commons as well, I suggest to qualify your votes > as follows: > > a: mapper in commons sandbox > b: mapper in commons > > Ted is +1 on a. > Jason is +1 on a. > Jeff is +1 on b, but that was before the suggestion of putting the mapper > in > the commons directly. Jeff, could you please clarify your vote in terms of > option a or b? Thanks. > > I of course plan to "standardize" the build process and align with the > Jakarta template, repackage, and test this before submission. > > Fr. > > -----Original Message----- > From: Scott Sanders [mailto:[EMAIL PROTECTED]] > Sent: 16 January 2002 19:34 > To: Jakarta Commons Developers List > Subject: RE: [Vote] Mapper framework in sandbox (was RE: Commons > Validator Packaging/Content) > > > So the initial set of comitters needs to be updated to be: > > Rey? > Ted? > Dave? > Craig? > > Just wondering, as that piece of the proposal is not here. > > Scott > >> -----Original Message----- >> From: Ted Husted [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, January 16, 2002 9:48 AM >> To: Jakarta Commons Developers List >> Subject: Re: [Vote] Mapper framework in sandbox (was RE: >> Commons Validator Packaging/Content) >> >> >> +1 as a Commons package. >> >> Rey's a longtime contributor to the Struts lists, and his >> Mapping framework is often mentioned by the Struts >> developers. Rey's also made some important contributions to >> the Digester package. As he mentioned elsewhere, this package >> complementary to the Commons Validator, and I believe some >> people use both in the same application. >> >> I think both the Mapping framework and Rey himself would both >> be worthy denizens of the Commons. >> >> But, I don't believe it needs to go into the sandbox first. >> The package has been "out there" and available for download >> with full source for some time, and there is a developer >> community already using it. >> >> -Ted. >> >> >> Rey Francois wrote: >>> >>> I've sent this post yesterday but I'm pretty sure it will >> quickly fade >>> under the abyss of all the posts on this list. So I post my >> proposal >>> again, using a more appropriate title, and using the recommended >>> format: >>> >>> Proposal for a mapper framework >>> >>> (0) rationale >>> >>> In many application environments validation needs to be >> performed on >>> data fields, data is converted from one form to another, >> and is being >>> transferred from one object to another. A typical example >> is found in >>> graphical user interfaces that validate user input, convert it to a >>> proper form, and send it to a server application for processing. In >>> the case of HTML front-ends, the HTTP protocol forces user >> input to be >>> sent as text data to the server where the validation and conversion >>> has to be performed. >>> >>> Most of the time implementing such validation and >> conversion requires >>> lots of custom code: get the data element, validate it, convert it, >>> and put the result into another object. In a small >> application, this >>> may not be an issue. However in medium to large >> applications with many >>> different data elements, such coding becomes a tedious and >> error-prone >>> task. >>> >>> In such situation developers tend to achieve some form of reuse in >>> order to reduce the menial work. At the lowest level is the >>> cut'n'paste approach. A better approach is the definition of some >>> high-level abstraction which encapsulate reusable logic: validation >>> and conversion classes are typical abstractions found in >> most systems. >>> >>> However, even with validation and conversion logic being reusable, >>> some custom coding is still required in order to attach those >>> validations and conversions to the data elements. To avoid >> completely >>> the custom code, an even higher level of abstraction is needed in >>> order to model such bindings. The mapper framework >> implemented in this >>> package provides such high-level abstractions, making the >> validation, >>> conversion, and transfer of data a process driven by a >> configuration >>> file. >>> >>> Although the central concept in this framework is the one >> of a mapper, >>> the framework is flexible enough to be used only for >> validating fields >>> of an object, or converting an object into another one, or simply >>> copying fields from one object to another. It is also >> flexible enough >>> so that validation, conversion, and transfer can be performed on >>> multiple objects within the same mapper. >>> >>> (1) scope of the package >>> >>> The mapper framework provides the necessary classes and >> abstractions >>> to perform validation, conversion, and transfer of data >> fields between >>> any types of objects. The configuration of all mappers and other >>> abstractions is done in one or more XML file loaded at startup. The >>> framework does not depend on any other application >> framework such as >>> Struts or Turbine, and integration with such frameworks should be >>> provided separately. >>> >>> (1.5) interaction with other packages >>> >>> The mapper framework makes use of >>> - the Commons Digester >>> - the Commons BeanUtils >>> - JavaCC >>> - the Commons Pool (work in progress) >>> >>> (2) identify the initial source for the package >>> >>> The initial codebase is to be contributed by Francois Rey. >> A version >>> of the source is already available at < >>> http://husted.com/struts/resources/mapper.htm >. >>> >>> (2.1) identify the base name for the package >>> >>> org.apache.commons.mapper >>> org.apache.commons.mapper.parser >>> >>> (3) identify any Jakarta-Commons resources to be created >>> >>> (3.1) mailing list >>> >>> Until traffic justifies, the package will use the >> Jakarta-Commons list >>> for communications. >>> >>> (3.2) CVS repositories >>> >>> For the time being, the package will reside in a sub-project of the >>> Jakarta-Commons sandbox CVS. >>> >>> (3.3) Bugzilla >>> >>> The package should be listed as a component of under the >>> Jakarta-Commons Bugzilla entry. >>> >>> (3.4) Jyve FAQ (when available) >>> >>> commons-mapper >>> >>> (4) identify the initial set of committers to be listed in >> the Status >>> File. >>> >>> Francois Rey >>> >>> -----Original Message----- >>> From: Rey Francois [mailto:[EMAIL PROTECTED]] >>> Sent: 14 January 2002 13:40 >>> To: 'Jakarta Commons Developers List' >>> Subject: RE: Commons Validator Packaging/Content >>> >>> This Intake component is quite interesting. If I had known of its >>> existence about half a year ago I may have inspired myself or even >>> reused it instead of developing my own >> validation/conversion/mapping >>> framework. >>> >>> In any case, I now have this framework that I think is >> quite relevant >>> to all these discussions in the commons list. I've already >> "published" >>> the mapper framework on Ted Husted's resource site (see >>> http://husted.com/struts/resources/mapper.htm) and some of you may >>> remember a few postings about it. >>> >>> Because I see so much discussion about a validation >> framework, about >>> Intake, and competing implementations in the sandbox, I'm also >>> starting to itch: I'd like to put this mapper framework in >> the sandbox >>> so that more people can see it and judge it. Let me give a >> few bullet >>> points about it: >>> - it's a validate/convert/transfer framework: it can take >> values from one >>> object, validate/convert them, and transfer the resulting >> values into >>> another object >>> - it can do all this or just a little (e.g. just >> validation) very easily, in >>> one go or step by step (e.g. step1: validate; step2: convert; step3: >>> transfer; with user control between each step). >>> - XML configuration: mappers, mappings, converters, >> validators, validation >>> rules, getters & setters, etc. are defined in one or more >> XML config file. >>> - it is HTTP and Struts independent: it only depends on the >> PropertyUtils, >>> Digester, JavaCC, JUnit, ... >>> - it is used in production within a Struts web application: >> it handles all >>> form validation, all backend request population, and all >> mappings of backend >>> results to presentation beans. >>> - more info and download on >> http://husted.com/struts/resources/mapper.htm, >>> and in the included HTML file. >>> >>> This framework IMHO is of good quality, but I never bothered >>> "promoting" it by creating a web site for it. Since it was made >>> downloadable from Ted's site, I received a few mails, both >> on the list >>> and personally, from people using this framework asking me >> questions. >>> So it is used out there, but it's usage is very limited compared to >>> David's validator component. >>> >>> Making it available in the sandbox would make it more >> visible, would >>> allow others to participate in its evolution, and would >> also provide a >>> "healthy" competition to the validation framework business. >>> >>> Anybody out there supporting the submission of this mapper >> framework >>> in the sandbox? >>> >>> Fr. >>> >>> -----Original Message----- >>> From: Ted Husted [mailto:[EMAIL PROTECTED]] >>> Sent: 07 January 2002 02:42 >>> To: Jakarta Commons Developers List >>> Subject: Re: Commons Validator Packaging/Content >>> >>> Jon Scott Stevens wrote: >>>> That is my question. Why doesn't David work towards integrating >>>> Intake >>> into >>>> Struts instead of working on pulling what is duplicated >> from Struts >>>> out >>> into >>>> Commons? The answer is simple...it is David's itch to >> scratch and it >>>> is >>> the >>>> simplest thing for him to do. That is the current failure >> of Jakarta >>>> in my eyes. Jakarta has become no better than >> Sourceforge. It is a >>>> place where >>> you >>>> can dump your least common denominator. >>>> >>>> Instead of Struts working to use Turbine code and then >> move it into >>> Commons. >>>> Struts came up with their own validation framework, made >> it stable >>>> in >>> Struts >>>> land and is now dumping it into Commons. There is a >> complete lack of >>>> communication there. >>> >>> Yes, we recognized that last year, and so created the >> Commons. At that >>> time, David's framework already existed. Learning the lessons of >>> Turbine, we decided not to integrate into Struts, and left it as a >>> free-standing component. (It was created that way from the >> beginning.) >>> >>> David has already done the work. At this point, the duplication of >>> effort would be making Intake a free standing component. If someone >>> wants to do that, and donate it to the Commons, I think >> that would be >>> great, especially since the Commons specifically provides for >>> competiting implementations. >>> >>> -- Ted Husted, Husted dot Com, Fairport NY USA. >>> -- Building Java web applications with Struts. >>> -- Tel +1 585 737-3463. >>> -- Web http://www.husted.com/struts/ >>> >>> -- >>> To unsubscribe, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> For additional commands, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> >>> >> ********************************************************************** >>> ** >>> The information in this email is confidential and is intended solely >>> for the addressee(s). >>> Access to this email by anyone else is unauthorised. If you are not >>> an intended recipient, please notify the sender of this email >>> immediately. You should not copy, use or disseminate the >>> information contained in the email. >>> Any views expressed in this message are those of the individual >>> sender, except where the sender specifically states them to be >>> the views of Capco. >>> >>> http://www.capco.com >>> >> ********************************************************************** >>> * >>> >>> >> ********************************************************************** >>> ** >>> The information in this email is confidential and is intended solely >>> for the addressee(s). >>> Access to this email by anyone else is unauthorised. If you are not >>> an intended recipient, please notify the sender of this email >>> immediately. You should not copy, use or disseminate the >>> information contained in the email. >>> Any views expressed in this message are those of the individual >>> sender, except where the sender specifically states them to be >>> the views of Capco. >>> >>> http://www.capco.com >>> >> ********************************************************************** >>> * >>> >>> -- >>> To unsubscribe, e-mail: >> <mailto:commons-dev-> [EMAIL PROTECTED]> >> >> -- >> To >> unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> >> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > ************************************************************************ > The information in this email is confidential and is intended solely > for the addressee(s). > Access to this email by anyone else is unauthorised. If you are not > an intended recipient, please notify the sender of this email > immediately. You should not copy, use or disseminate the > information contained in the email. > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Capco. > > http://www.capco.com > *********************************************************************** > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > ************************************************************************ > The information in this email is confidential and is intended solely > for the addressee(s). > Access to this email by anyone else is unauthorised. If you are not > an intended recipient, please notify the sender of this email > immediately. You should not copy, use or disseminate the > information contained in the email. > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Capco. > > http://www.capco.com > *********************************************************************** > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]. > org> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]. > org> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
