Splitting the registration into two cases is also a very good Idea. I could let them complete their profile through the member area. Thanks for the suggestion.
Now, off to something else. I tried the DTO approach and just found out something peculiar: I can't really use the ActiveRecord Validation framework with that since those DTOs are not in the Database and even for simple stuff like [ValidateNonEmpty] the Validator requires a AR mapping. Any suggestions on what Validator I should use? I'm currently tempted to simply roll my own little validation and be done with it. greetings Daniel On Fri, Sep 11, 2009 at 12:39 PM, Gauthier Segay <[email protected]>wrote: > > > just a ordinary website that is pretty curious about it's members > > In my experience, member registration on a public facing website is a > critical scenario, also being too curious was a weak point of a site I > took off, since I transformed the registration in a two stage use > case, the registration / day ratio has climb up drastically. > > > I think I'll go with the postback validation since it should be easiest > to implement. If I feel fancy I'll try the AJAX validation at a later stage. > > My current experience is that ajax validation is easier because you > don't have to mind the form state (it's still on the client DOM), but > the weak point is that it requires enabled javascript which is not > mandatory with plain POST implementation. > > On Sep 11, 12:25 pm, Daniel Hölbling <[email protected]> wrote: > > Thanks! > > > > The Form-DTO idea is really good. I'll do that.Also I agree Ken, it's a > > Session-wide operation so that's probably the best way to go about that. > > > > I guess what impaired my thinking on this one was that every step of the > > Wizard corresponded to one Component in my Entity. > > My current approach was to save every step into the session and the last > > Step then pushes them together into the Entity and validates that > (leaving > > me with issues on how to correct validation errors). > > > > Thanks again. I'll try your suggestions and maybe compile them into a > help > > topic for the users guide. > > > > @Gauthier: Oh, I guess you did mistake my use-case. It's the most > > un-critical thing in the world anyone will ever build :) (just a ordinary > > website that is pretty curious about it's members). > > I think I'll go with the postback validation since it should be easiest > to > > implement. If I feel fancy I'll try the AJAX validation at a later stage. > > > > greetings Daniel > > > > On Fri, Sep 11, 2009 at 12:01 PM, Gauthier Segay > > <[email protected]>wrote: > > > > > > > > > > > > > I'm not used to the MR wizard but here are some thoughts: > > > > > - instead of validating a fullfledged DB entity, you could validate > > > plain Form DTO that match each registration steps, monorail controller > > > has a validator runner that you can use on any DTO bringing validation > > > attributes > > > - if session feel like unsecure storage (I feel the same way), isn't > > > there a possibility to store each form DTO in a serialized form in a > > > DB table that would be purged for expired / incomplete registration > > > > > theses look like extra work, but your usecase seems a bit critical and > > > it's better to design with more separation rather than making that at > > > a later stage > > > > > For the ajax instant validation, it depends if you want full fledged > > > validation (ie: validating every rules) or can accomodate only > > > validate simplest rules (that is mandatory fields, email format, group > > > non empty) > > > > > For the simplest rules, using FormHelper with Validation enabled DTO + > > > JQuery validation support would help, but it's still limitated to some > > > validation attributes, this works without AJAX/reaching the server > > > > > for more complex things (unique member name checked on server side, > > > etc.) there is two ways I can think about: > > > > > - ajax enabled way: having a controller action handling the form > > > (ajax) POST returning JSON and use that JSON to handle validation > > > feedback > > > > > - get post redirect way: having a controller action handling the form > > > POST performing a redirect on the next page if everything is ok, or > > > redirect to the initial form if there is any failed validation, > > > passing the form DTO in Flash (which is backed in Session), there > > > again using FormHelper would help to restore the state of the form as > > > it was submitted > > > > > Let us know if you have any specific questions according to your > > > implementation choices > > > > > I hope this helps > > > > > On Sep 11, 11:30 am, Daniel Hölbling <[email protected]> wrote: > > > > Hi, > > > > I'm currently building a Registration form for my MonoRail > application > > > and > > > > there is a LOT of data to be entered by the user. > > > > So I decided to split it through using a Wizard interface. > > > > > > I just feel a bit at a loss what the best way would be to carry that > > > > intermediary data from Step to Step. > > > > I obviously can't put it in the DB or I'd see bad records in the > Database > > > > hat need to be cleaned up afterwards. > > > > On the other hand I don't really feel comfortable putting that Data > into > > > the > > > > Session. > > > > > > Another problem I see is Validation: > > > > Since I am hydrating only one entity from the Form, the ActiveRecord > > > > validator will always report invalidity until the very last step when > all > > > > required fields have been met. > > > > I'd really like to do some sort of AJAX instant validation on that > form, > > > so > > > > how do I query the validity of exactly one field? > > > > > > Does anyone have experience with the Wizards and can share some > wisdom on > > > > how to use it without the solution getting too complicated? > > > > > > greetings Daniel > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
