Hi, I've only recently started putting my forms on request scope, and encountered this issue with DynaValidatorForm. A request scoped "out of the box" DynaValidatorForm is also unable to handle indexed properties e.g. throws IndexOutOfBoundsException in DynaActionForm.get(string, int) - I guess this is just one of those Struts "quirks" encountered from time to time. My actual form extends DynaValidatorForm so I suppose I could override this method and populate the array with my object type (see how LazyValidatorForm does it). Perhaps the struts indexed properties documentation could improve how various form implementations should "grow" arrays. This exercise has taught me that having the form on session scope won't necessarily solve the problem...ie if more http params are posted than the array size. Cheers, Paul p.s. for a DynaForm the request parameters are passed through a Map so the form List is not populated in any particular order - although it matches the http request params exactly when its completed. I havn't worked with ActionForms so that may be the case there too - but I'd keep the form at request scope. ________________________________
From: Urso Wieske [mailto:[EMAIL PROTECTED] Sent: Fri 8/12/2006 7:58 PM To: user@struts.apache.org Subject: FW: Struts1: CHALLENGE "Indexed Properties can not be used with FORMS on REQUEST scope!" TRUE or NOT TRUE? Hi folks, Unfortunately I have not got any reactions about my statement yet? I really would like to hear some views on this matter. Kind Regards Urso Wieske -----Oorspronkelijk bericht----- Van: Urso Wieske Verzonden: donderdag 7 december 2006 14:11 Aan: 'Struts Users Mailing List' Onderwerp: Struts1: CHALLENGE "Indexed Properties can not be used with FORMS on REQUEST scope!" TRUE or NOT TRUE? Hi folks, Very low reactions on my posting about indexed properties, form, beanutils and request scope. I therefore impose the following CHALLENGE STATEMENT: "Indexed Properties can not be used with FORMS on REQUEST scope!" I am curious to know who is able to support or reject this statement, beceause until now I was not able do implement this scenario without exceptions. Ted Husted: I would really like your view on the above... :-) Kind regards Urso Wieske --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
