Re: MessagesResources - some thoughts
But technically couldn't the application developer do this already? They could just add another init-param to the Servlet which specified a Resources class other than the default. The servlet writter would simply use this resource bundle instead, getting it's messages from there. You could have something like UIResource and ServletResource classes. The UIResource class would be the one you set in the ActionServlet's application init-param, and the ServletResource class can be loaded programatically by the servlet writter based on some custom init-param which specified the class name. Craig T. Rob Leland wrote: Roland Huss wrote: Hi, for some reasons I would like to separate messages put into JSP-pages with bean:message from messages generated within java code. +1 This sounds like a good Idea. I would vote for this change. Maybe you could post it to the bug/feature request so it ends up one the list for version 1.1. -Rob -- I've been trying to change the world for years, but they just won't give me the source code begin:vcard n:Tataryn;Craig tel;home:952-884-6752 tel;work:952-842-5576 x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Division adr:;;3600 West 80th St. Suite 400;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Staff Analyst fn:Craig Tataryn end:vcard
Re: Validation and automatic form bean generation
At 09:16 AM 2/16/01 +0100, Michael Gerdau wrote: I'm not quite sure about the difference between (2) and (3). Sorry, I should have been more clear. In option (2), the bean-generation tool would read validation rules from the XML definition of the beans and generate code to perform the necessary validation. The validation code would be built in to the bean itself. In option (3), the bean-generation tool would always generate the same validate() method. That method would read an XML definition of the validation rules at run time, and perform the necessary validation. This is what David Winterfeldt's Validator does. I don't see why "must match 'mm/dd/yy'" shouldn't be part of this automatically created validator either. And that could as well check wether the date entered actually is a valid one (e.g. no 31. Apr, 29 Feb outside leapyears etc.). After all that basically implements the requirement 'must be a date' which would be in line with 'must be an integer'. I guess I picked a poor example. What I meant was that built-in validation might be restricted to simple stuff like "Does Integer.parseInt succeed?" while validation that is domain-specific could be left to an external specification. As an aside, validation of dates brings up the issue of introducing the locale to the validation scheme. And while I'm at it it might come handy if we could somehow describe some rules which define valid patterns for other types as well. Regular expressions are an obvious candidate here. The Validator uses the Jakarta Regexp package for this. Last not least I easily can envision the need for dynamically adding constraint derived from other attributes, e.g. for floats (monetary values) to require they have no more than 2 fractional digits, being lower than a certain upper value (e.g. an account balance), defining relationships between entered values (e.g. one being a multiple of the other or being between two others etc) and possibly quite a few more such things. Yes, there are many options to consider in the validation "big picture". At some point, especially when you get into relationships between fields, we have to ask ourselves whether it's worth trying to write a specification versus just writing the code. Since I'm already in 'wish mode': a generic 'currency module' possibly combined with an 'interest module' would be rather nice as well. If there is more demand for such things I'd be happy to help here as I'm currently working on porting something like that from C/C++ to Java anyway. Knowing others requirements would help making it of general useability. I'll leave that to the generic validation discussion, which is in full swing over on struts-user right now. What I'd really like to pursue in this thread is how to address validation within the context of automatically generating form beans. Just my thoughts, best, Michael Thanks! -- Martin Cooper Tumbleweed Communications
Re: Validation and automatic form bean generation
Martin, I'm new to the Struts project, but we're about to migrate a massive codebase to JSP/Struts and have identified this as a sore spot. Basically we need a rules-based engine for populating/generating forms. In addition, many of the form fields are directly correlated with our forms, and it's painful to manually copy the fields from forms to beans. We're preparing to grow our own, but here are a few of the ideas we're planing on implementing. Caveat: we're assuming everything is enforced at runtime - it's similar to, but a step beyond, David Winterfeldt's work. Basic Features: 1) The base action form is a Map (a hashtable*). At request-time, the proper definition is retrieved and the map is populated based on its definition. Form definitions will look something like this: form id="Foo" field name="people" type="Integer" required="true" field name="adate" type="Date" required="true" ... 2) The popuulated map is validated against the definition - types are enforced by input validators which are defined a separate section of the XML definition: mapper type="Date" class="com.xyz.mapper.Date" mapper type="Integer" class="com.xyz.mapper.Integer" ... 3) At the appropriate point in the action, the form can be mapped to/from a data bean, again based on the definition: form ... mapping class="com.xyz.entity.Foo" map property="people" map property="startDate" field="adate" ... Our JSP authors has expressed interest in having the form definition influence page generation. I haven't delved into this aspect, but I'm expecting the requirements to extend to Javascript validation as well. Hope this helps! Nino * Extending PropertyUtils.set/getSimpleProperty to handle maps is actually a very simple change... Martin Cooper wrote: I'm signed up for the Struts 1.1 task entitled "XML -- ActionForm Code Generator", and am working on such a tool at the moment. There has been a fair amount of discussion on various types of validation recently, so I wanted to throw this variant into the mix and see what people think. Server-side validation in a Struts application typically happens in two different phases. What might be referred to as "early" validation (usually just syntactic validation) is done within the form bean (in ActionForm.validate()), while "late" (more complex) validation is left to the Action to handle. The question, then, is how best to handle "early" validation in the case where the form bean is being generated automatically rather than being hand-coded. At this point, I see three alternatives, and this is where I'd like to hear what people think. 1) Do nothing. If the developer wants to do early validation, s/he can implement the validate() method by hand to do whatever is necessary. 2) Generate the validate() method based on validation rules specified in the XML definition of the form bean (e.g. within struts-config). This would generate a static (i.e. at bean-creation-time) specification of the validation algorithm. 3) Generate a validate() method whose behaviour is defined by an external specification (e.g. in XML). This could be along the lines of the Validator implementation proposed by David Winterfeldt. A combination of (2) and (3) might also make sense, where a basic validation scheme might take care of existence rules (e.g. 'required') and type definitions (e.g. 'must be an integer'), but where more sophisticated validation (e.g. must match 'mm/dd/yy') would be left to an external validator. What do people think about this? -- Martin Cooper Tumbleweed Communications
