thank you Yarko for your always informative answers and for your
natural attitude to understand there are different point of views (I
wish I had someone like you in my company :-).
Just to come close to something I will show an example (though not
particularly smart):
my controller:
form=FORM(INPUT(_name='contact_email',requires=IS_EMAIL(error_message='Wrong
Address')),\
INPUT(_name='contact_company',requires=IS_NOT_EMPTY(error_message='Can
not be empty!')))
errors=form.errors
if form.accepts(request.vars,session=None,formname='contacts'):
redirect(URL(r=request, f='index'))
elif form.errors:
return dict(errors=form.errors)
return dict(errors=errors)
my view:
<form action='#' id='contacts' method='post'>
<ul><li>
<label for="contact_company" class="fixedwidth">Company</label>
<input type="text" name="contact_company" id="contact_company"/>
{{if errors.contact_company:}}
<span id="error">{{=errors['contact_company']}}</span> {{pass}}
</li>
<li>
<label for="contact_email" class="fixedwidth">E-mail</label>
<input type="text" name="contact_email" id="contact_email"/>
{{if errors.contact_email:}}
<span id="error">{{=errors['contact_email']}}</span> {{pass}}
</li>
<input type="hidden" name="_formname" value="contacts"/>
<li id="submit"><input type="submit" value="Send"/></li>
<li>...other inputs you do not need to validate..</li>
</ul>
</form>
Well this uses FORM and leaves me free to have HTML the way I like:
but if you want to use FORM and for whatever reason you do not want
SQLFORM you have to go through something like that. My purpose: a
contact form without persistence because I do not need it and because
contacts requests are sent to me by email (or I am on a public hosting
with no db or whatever); I want to use web2py embedded validation; I
want to use HTML because my designer has already coded my web
pages..Though I put down some reasons with no particular care I think
this is, in general, not such a remote choice.
As you said:
>>But ultimately, you need to know "I want to do this - how? what are my
>>choices?"
>>Web2py offers you FORM, SQLFORM, and SQLFORM.factory.
My example is poor and maybe it is irrealistic there is not a model
but it works with FORM,
rgds
carlo
On 2 Apr, 16:09, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote:
> 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
> onhttp://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.
