On 14/03/2006, at 14:58, Michele Cella wrote:
> > If we really want to support that we can do that without the fqf > thing, > we just need to add a category to input_values and validation_errors, > since only a form at once can be submitted we validate that particular > form, for example: > > input_values['form_name'] = .... Hmmm, you mean at the validate decorator, right? Remember all the troubles we had regarding the method's signature. I f the form is FQ then the controller will receive just one arg unless we hack it at the decoding filter (which we already considered a bad hack). Normalizing the variables at the decorator is not possible because it's too late, the method's sig wont match. Maybe I missed your point, if so please clarify... :) > > this is different from fqf because we end up to always have a fqf but > that's transparent to the user that doesn't see that in it's final > page > and the method, display_field_for works flawlessly because your are > calling a method on that particular form asking him to display the its > (for example) "age" field. > Replied above, to have a FQF transparent to the user (having a normal controller method which receives the form's fields, not the form itself) we need to hack that at the filter :/ > This is something I'm more keen to support because it doesn't require > bad hacks... it even makes sense probably, it makes for sure much more > sense than the fqf and it should be pretty easy and still pretty > clean. > > I say more let's make it! :D > Maybe I'm wrong, a working example will surely prove it :) Alberto > Ciao > Michele > > Alberto Valverde wrote: >> On 14/03/2006, at 14:23, Jorge Godoy wrote: >>> Wrong... I have more than 10 forms on the same page. And this >>> will also be >>> common with the TabWidget where everything is on the same page and >>> "beautified" to be in tabs... >> >> >> Jorge is making some good points here... Maybe we should support >> multiple forms per page (arggg). The hack at the schema generation is >> already done and works so don't need to worry about it... Dunno >> exactly the problems you're facing at display_field_for exactly but >> maybe could be solved somehow... could try to help if you tell me >> exactly what you want to do. I know I'm contradicting my prev. post, >> but it's true that people might want multiple forms... :( >> >> I think we need more feedback on this... >> >> Attention people, RFC: >> >> Would you want the Form widgets to support multiple forms per page? >> >> Your controllers will need to receive the whole form as input like >> def controllermethod(self, form): >> If you want to receive data from a FQF. It will be a (possibly) >> nested dicts representing your form's struucture. Normal paramters >> for non-FQFs. This cannot be easily solved so don't come complaining >> later... :) >> >>> I agree that too many hacks are wrong... :-) Maybe we can change >>> those to >>> "technical implementations" :-) (Just kidding) >> >> Patches are always welcomed :) >> >> Alberto > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
