Hello Carlo - Know, there is no right or wrong - but I am trying to understand...
On Apr 2, 3:38 am, carlo <syseng...@gmail.com> wrote: > Thank you Yarko for accepting my "challenge" and I am looking forward > to get your answer. > > > When I need to do this, I do it with making a memory-based table, and > > SQLFORM or SQLFORM.factory, and do whatevervalidationI need. > > I do not want to discuss your solution though personally I do not like > any solution based on SQLFORM: > - I do not like to have to create a table just to validate my html > form server side: so the manual solution "SQLFORM in HTML" is not for > me; Then you can use the FORM pattern, as shown on http://www.web2py.com/book/default/section/7/1 I have not used this, so I do not think of it often, but there it is. > - I do not like the SQLFORM.factory either because this simply shifts > the problem and create a "fake" table in the controller; Of course, you are free to have your preferences. But in this case you state it "shifts the problem" - but I am not sure what "the problem" is... That web2py is push-style mvc, and that the first thing that happens on a request is that data context is setup in preparation for a response (i.e. models are run, then controller) it is (by it's nature) table centric. IT is not so structured that it is object (e.g. business+engineering logic) centric, but if DAL were replaced by an ORM, then you would have your first focus on attention on the business-objects (and the persistence would be part of the mechanism the ORM would manage). ...and so on... My point is that there is always of view of the problem inherent, and you pick how you like to look at the problem (i.e. how you are comfortable at working)... > - I do not like Custom Forms particularly because, apart from the fact > I find the widgets a little tricky and "magic", they are based on a > table as well. Custom forms are no more than a way to do in forms the equivalent of a "join" on data (you can literally do this) and non-persisted items. You can almost think of them as SQLFORM.join(FORM)[.join(SQLFORM)] - where the brackets mean optional (in the "man page" sense - nothing about python lists). > > As I said, maybe I am totally wrong with my above thinking and I do > not want to criticize anyone but I prefer the "there is only one way > to make things" philosophy, which is very pythonic btw, over what I > read sometimes in this forum (and the book) "You can do that in > thousands of ways" or "It is easy to validate pure html forms" etc etc > ( which reminds me of the "Turbogears way" to make things). Well ... yes, it is nice to have one way to do things; and, of course, even in the python language there are several ways to do things (oftern as a reaction to some performance issue, or other design need / trait). The real "terrible" thing is when there are multiple ways to do the same thing with no discernable reason; The good thing is when you have a design goal you are trying to accomplish, there is a way to do it (and hopefully it is "natural" to how you think of what you are doing - that part really is hard, unless you write everything yourself). > > So I will take that your answer to "What is the best way to keep > validation and pure html forms?" is "doing a memory-based table and > SQLFORM/SQLFORM.factory" For complex situations, I find this less "verbose" than writing my own FORMs... but you can certainly use FORM() > > > There is a fundamental "fuzziness" around this: If you have manual > > forms without data persistence, what are you validating? (and what > > can you not do by building up a simpel memory-db model, and validating > > transient data against that?) > > your the first question is retoric of course, I can validate > everything I want even how many capital letters a user chose for his > password. Well - yes, of course - but my point is that (in your example) the password is of little use if it is not in persistent storage somehow. But perhaps a clear example for what I think you are arguing for might be a game action, say a word game, or a student quiz where you really are only storing results (perhaps a count of correct, validated responses). > The second is a serious one but, apart from philosofic > questions against "persistency at all costs", you pose me the answer > later, suppose I fear heavy server load or I have to be spare about > server memory resources.. Well, if you are doing a student quiz (for example) then server load probably is not an issue; if you are doing an on-line game with tens- of-thousands of people simultaneously connected to a gaming context, that is a completely different problem. > > > Second - if it is _really_ transient data that you arevalidation, > > then even memory db, per request, could get pretty "heavy" in terms of > > server load - why not do client-sidevalidation? > > Of course you can if you have JS enabled. There are many choices for client side processing - even within the constraints of a browser. You have ActionScript/flash, JavaScript, Java, Processing (although at the moment, implementations are in either java or javascript), and for HTML5 perhaps more. A browser might not be the solution of choice, for example if you write for a mobile environment - you might prefer a client-native app which connects with the server. This may be your choice because of more efficient programming use (i.e. better client performance, or less battery/bandwidth use), or to give you better control and access to device's facilities, i.e. gps, motion / positoin sensors, etc. > So your answer here would be "if your data are really transient go > with client side validation". Sometimes - like I say: it is a design decision, and should be driven by needs of the problem, and an appropriate solution selected by rational consideration. > > > Either way, this begs the question: why exactly this form of > > question? > > My answer would have simply been a pure html Contact Form you see in > any web site but I now read a Thadeous' post where he gives his form > example. This example is missing something: consider the boundary condition of what you say: "Form + contact information, on client only" - not saved. My question was: "What is your purpose?" --- in this example, what use is contact information without persistence? (Even in a game, user-name or player-name is likely stored!). > > Thank you Yarko for following me in these apparently futile arguments > but I would just like that people beginning with Web2py do not have to > read, like in many other python frameworks docs, "it is easy to get > this thing done" but they can never grasp that "easy way". IT IS easy - but the hardest part (always) is having a concrete "why" behind each of your "I want"s --- a reason for an action / decision --- and end goal in mind. You can explore different ways to do things (i.e. performance testing of various built-in web servers) to understand more specifically what they offer you; You can explore interfaces to "see" if you like how they look. But ultimately, you need to know "I want to do this - how? what are my choices?" Web2py offers you FORM, SQLFORM, and SQLFORM.factory. Thank you for the discussion. Kind regards, Yarko > > carlo -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
