> > Please allow me some considerations: > > - The only case request.vars could be a problem would be when there are > variables with the same name on both methods. On this case i dont know > which one will be overwritten, the get var most likely. >
If post and get vars each contain variables with the same name, request.vars ends up with a list of the two values. > - The form discards extra variable names not declared for processing, so > including get vars should not affect post processing, besides when post and > querystring vars collides. > Or maybe if the query string happens to include a variable with the same name as field left blank in the form (in particular, check boxes, which are not included in the post data when left unchecked). > - If the form was not meant to process get vars, implementing the > functionality would not break compatibility. This would be easy since > request.get_vars and post_vars should be processed/validated the same way > when the form uses either methods. > Actually, it would probably make sense to check the "_method" attribute of the form and use request.post_vars if it is "POST" and request.get_vars otherwise. I would *not* use request.vars -- too many potential edge cases to worry about, and no benefit over simply using post_vars vs. get_vars conditional on _method. > I have made and test the changes and everything is working fine so far. > - The form would do type checking. It does not make sense to pass rooms = > "asd" when it expects an integer. or declare field type "integer" and > IS_INT_IN_RANGE and so on for every Field on our app. > I'm not sure about this. We already have default validators in place when using SQLFORM with a DAL table. This breaks down when using SQLFORM.factory because DAL(None) does not generate the default validators -- but it would probably be a better approach to change that behavior so that DAL(None) does get the default validators. That approach would have more general utility beyond helping with SQLFORM.factory, and it would avoid having to add complexity/duplicate validation code to the FORM class. In other words, let's use a mechanism we already have rather than add more code to the framework. > - The form will detect the variables to test against when _method="get" is > passed as parameter. It would be easy to use request.get_vars/post_vars > instead request.vars to prevent the issues you mention. > OK, yes, same conclusion I reached above. > - The form wont auto generate an id field when the adapter is NullAdapter > (the one used when Fields does not belong to any table, DAL(None)). > What's the problem with that? Have you considered any possible backward compatibility issues with that change? Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
