As for the wiki updates - you may have overlooked a few shn_ prefixes when
copying the old stuff into the new places, so maybe you want to correct that.
A good way for you to learn this is to answer the following question:
If the user submits a form (POST), and there is a validation error in one of
the fields, then all form widgets are called *2* times before the form is
returned - but why?
I'd say, if you can answer that (it's relatively easy, trust me), then you've
understood the process.
Where to store the current status of an uncompleted wizard form? In the
session? In the database? In the page?
I think to discuss this question properly, we need a better understanding of
the purpose of a wizard form. Sure, the discussion suggested "better UX", but
that's just a buzz phrase people use to whomp sceptics like me over the head
with.
I'm ok with that for a proposal - but for a design I don't buy it, and my
point here is that the exact opposite of wizard forms - i.e. combining
multiple forms into a single form - is also "better UX" and "ease of data
entry".
So - what now? What's the reason to provide a multi-step wizard form rather
than an all-in-one-page form? (please avoid comparative adjectives like
"better" or "easier" in your reasoning - try if/then instead, that's very
helpful for the design).
A good way for you to learn this is to answer the following question:
If the user submits a form (POST), and there is a validation error in one of
the fields, then all form widgets are called *2* times before the form is
returned - but why?
and will try to find a concrete use case.
How are data transmitted from the client to the server (I don't mean "via
network" - that's clear - I rather mean "with which data format" and where are
they initially stored)?
What's a form widget?
What's a validator?
What does "onvalidation" do and when?
"check for errors happens" - where exactly? In the process() function? In
form.accepts()? No.
Why does it call widgets at all?
why does it call each widget in the form a second time if there was an
error?
> I am not sure about this but the data is stored in the form of dictionaryHmm, where exactly?
> in the get_vars and post_vars.
I think the point is that they are stored in web2py's global "request" object.
If the form is submitted by POST, then its request.post_vars, if it is a GET-
form, then it's request.get_vars (=URL query).
How is an S3Request instance related to web2py's global "request" instance?
c
reate a nested structure of XMLComponent instances.
Please checkout SQLFORM.factory - what can this be used for and how?
(recommend you read the web2py book for easy understanding before you dive
into the code).
What do you think - what consequences does that have for the widget design?
Hope this clears up a few more details for you
> so "S3Request" has (in addition to all the attributes of request):
Note that each S3Request can override some details of "request", e.g. all of
the URL (including args and vars).
In contrast to the one global "request" (which is the one and only "real" HTTP
request), there can be multiple S3Request instances during the same call -
addressing different resources with different methods.
An S3Request that overrides some request attributes is sometimes called a
"fake S3Request" - but of course it's not "fake", it's just not 100% congruent
with the global "request".
Many s3_rest_controller calls, for example, "fake" the S3Request by overriding
module prefix and resource name (which would otherwise be the same as
request.controller and request.function).
And since such an S3Request request is no longer 100% congruent with theunderlying HTTP request, it is sometimes called a "fake" S3Request.
Here, the flow diagram of S3SQLCustomForm
Discuss the design to save user progress and users step.
Creating models (if required ) to save the user progress and the step is on.
The diagrams have a weakness: the accepts() gateway has actually threepossible exits:
The two you outline:
- form gets accepted
- form has errors
and a third:
- form has not been submitted yet (=GET cycle)
How does accepts() check whether the form has been submitted? What's for
_formkey for?
I don't think the diagrams should be your focus anymore - it's time to code.
Let's have our weekly meeting on Wednesday, 08:15 UTC.
Remember that I still need a daily short progress report (3 bullet points, not
more): what have you accomplished today? What are you going to accomplish
tomorrow? Are there any roadblocks?
I'm probably going to be a bit late tomorrow - could we postpone to 09:00 UTC
(only this time)?
> this _formkey prevent double submission of forms.
Why do you think this is necessary?
This is going to be my last question for your "learning" goals - I think it's
time to move on. There's certainly still a lot more for you to learn - mostly
small yet important details - but theory isn't nearly as effective as practice
with these ;)
If you have any code ready to review it would be good to publish it before our
meeting. You're a couple of hours ahead of me, so you should still have the
time.
I am still confused with the S3WorkflowNode function that we discussed on IRC.
However, Hardik, you need to confirm whether that's really what you want to do,
otherwise we better take a step back, and take the other road.
A normal REST request is a workflow with a single node. So, if the request does
not indicate any particular workflow, then we run such a single-node request.
However, the request could also address a particular workflow (usually by a URL
parameter). In this case, the REST API would instantiate the S3Workflow
instance and hand over the request processing.
The S3WorkflowNode can utilize then regular S3Methods to execute the step, and
then update status and/or data for the workflow.
session = current.sessionif "workflow" in r.post_vars or r.post_vars and "workflow" in session.v:from s3.s3workflow import S3Workflowif "workflow" in r.post_vars:session.v = r.post_vars.items()session.v= session.v[:3]request.post_vars = {}
c = session.v.pop()w = S3Workflow()output = w(c)
class S3WorkflowNode():def __call__(self,c):s3_rest_controller = current.rest_controllerreturn s3_rest_controller("req",c[1])
/req/req/create?workflow=<workflow_name>:<workflow_uid>
workflow_name - identifies the workflow type
workflow_uid - identifies a workflow instance (so you can resume a workflow after
navigating away from it)
However it can also wait if you're simply not at that stage yet - all
as you like :)
I prefer pull requests on GitHub over pastebin snippets when I'm to review
code/changes - even if incomplete.
Probably better for us :)
Let's see if next week we can talk about this - either on-list or,
if-necessary, we can escalate to a call.
To view this discussion on the web visit https://groups.google.com/d/msgid/sahana-eden/CAPKzkt%2BOzzQ1tgMZWQtBfiBXmM98zJc%3Dgy0t7sEHWXMN4viO2w%40mail.gmail.com.