>   I've been developing an app using form2 and I ran into a little snag.
>
>   In some cases I want to populate one of the fields of a form
> with a value,
>   the problem is that when I pass in the value it gets
> interpreted as a form
>   element and is_submitted() returns True causing the error checking to be
>   run causing an error message be displayed even though this is
> the first time
>   the user has seen the form.
>
>   Is there a good way to handle this?
>
>   Thanks,
>
> Jon

I've seen this also, and I feel your pain... Even if you subclass Form to
change the way is_submitted() works, you're still SOL, because the form2
widgets parse themselves at construction, using request.form, rather than
form.is_submitted() to determine if the form has really been submitted.

Overall I really like form2 over form, but form did give a way to deal with
this situation (only parsing inputs if YOU decided that the form had really
been submitted), and so far I haven't figured out how to do that in form2,
without touching a LOT of code.  At a minimum, I think I'd have to subclass
Form and Widget, and then modify all the other widgets to subclass from my
Widget instead of the normal one...  Argg......  Basically, I'd have to
maintain my own copy of form2, or submit a monster patch.  Any ideas on
this, folks?

One (lousy) work around may be to use the session to hold the info...
Depending on what you're doing it may not be feasible, and even if it is, it
probably isn't a good idea... If a person has more than one browser instance
running, then depending on the brand and how it was opened, there's a really
good chance they share their cookies, and thus, share the session.  Beside,
just on GP, "session state isn't for tracking page state."

In quixote, the most appropriate way I know of to really deal with this
issue it to put the parameter in the URL.  This works particularly well if
you're passing something that represents an object (eg. an ID or login
name).  I like the following url approach:

  /reservations/             <-- get's list of reservations
  /reservations/123/         <-- view reservation with id = 123
  /reservations/123/edit     <-- edit reservation with id = 123
  /reservations/123/delete      ... etc ...

When it's time to create one, you can do something like one of these:
  /reservations/_/edit       <-- my favorite approach
  /reservations/edit
  /reservations/create       <-- personally, I don't like this one...
                                 I'd rather reuse edit if possible

There has been some controversy over the wisdom of using something like the
"_" as a reserved symbol indicating a 'blank' version of your object.
The overall approach, however, is nice because it mirrors objects and their
methods as seen in OO source code.

However, that technique only works well if you're just passing an id (or
something like one).

There's another metaphor that works well, and is better suited for receiving
mutliple (positional) parameters, and it's the TailEater.  I'll let Andrew
tell you about that at http://www.quixote.ca/qx/TailEater.  As Martin
observes at the bottom of the page, the text is a bit dated... _q_lookup()
now replaces the _q_getname() function refered to in the text.  The code
itself is up to date, however.

The one real drawback with both approaches is that they CAN'T handle "/"s in
the data.  url_quote doesn't change a "/" to a %2F, and even if you wrote a
modified url_quote that did convert / to %2F, it get's converted back to a
slash before traversal takes place, so it looks like a normal / to quixote
anyway (which means your URL traversal will blow up)...  Very frustrating,
and it means you can't easily pass URLs (or anything else that might contain
a "/") around as parameters in the url space.  If you MUST pass something
like that, it has to go in the query string, which means you can't use form2
as it was intended.  (I'm sure it could be hacked to work)

Hope this helps,

Jason