I do agree with you on the fact that Intake is not much good for anything except validating HTML forms. However, that is a common problem that must be solved for all web based (HTML) applications. For this, Intake is a great tool. That is why I am contributing my time to maintain and improve upon it.
Setting a field to a default value is incredibly easy if you populate the group from a business object. I use the default value in the XML file only for default selection in select boxes.m However, your point it taken. This is not obvious to someone new to Intake. I do like the idea of having a more generic validation layer that is not coupled to ValueParser or Velocity. Part of my internal application imports data from fixed format files (uploaded through a web interface). I would love to have a service that will allow me to define validation rules for that type of input. The same would go for XML submission of data as well. > -----Original Message----- > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 17, 2003 11:11 AM > To: [EMAIL PROTECTED] > Subject: Re: Proposed change to intake validation. > > > "Quinton McCombs" <[EMAIL PROTECTED]> writes: > > >Notice that doAssertValidity is called after testing the > required rule > >bute before any other others. Is there a reason for this? It seems > >that it might be better for the basic forms of validation to occur > >before the subclass begins its validation. > > >Thoughts? > > Well, while I really appreciate your work on the intake, to > me it is some sort of "beating a dead horse". Intake really > is a mess. You can use it exactly as it was designed but > everything else is pretty much obfuscated. Intake works > exactly on one class of things (HTML forms), is heavily tied > to the VelocityService (tool) and Turbine RunData > (fields) and if you want to preset a field with anything else > but a fixed value from the XML form: Good luck. =:-) > > I did read a (german) article about field validation quite a > while ago and there was a generic XML framework presented to > validate input fields from a bean, so we could get a really > thin layer which represents an arbitrary HTML form as a bean, > then call this framework to validate the fields and put them > into the business objects. > > And then there is commons-validator which, while having some > really gross problems (look at > o.a.commons.validator.GenericTypeValidator. > Each of these methods should be in a separate class derived > from a common base type) it is a common framework for a job > we need again and again. And I would really love to have a > framework which can validate arbitrary beans (hey, what did I > get from the XML-RPC call just a millisecond ago) and have > intake just a thin layer for form parsing and bean > representation (Something which should be quite easy with > commons-beanutils). > > But these are ideas that I kept under covers because I won't > find any time in the near future to implement such a service > (unless someone needs this and is willing to pay. =;-) > > Regards > Henning > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- > Geschaeftsfuehrer > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] > > Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] > D-91054 Buckenhof Fax.: 09131 / 50654-20 > > -- > To unsubscribe, e-mail: > <mailto:turbine-dev-> [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]>
