[Twisted-web] Q: Hidden field in TypedInterface?
Samuel Reynolds
twisted-web@twistedmatrix.com
Tue, 16 Dec 2003 14:15:40 -0700
At 2003-12-16 01:39 PM -0500, you wrote:
>On Dec 16, 2003, at 1:19 PM, Samuel Reynolds wrote:
>
>>In a formless.TypedInterface, how does one specify a "hidden" parameter
>>(i.e., force generation of a 'hidden' input widget in the generated form)?
>>
>>E.g., in :
>>class IMyProxy(formless.TypedInterface):
>> class PropertyGroup(formless.TypedInterface):
>> id = formless.Integer()
>> subject = formless.String()
>>How to make id become a hidden field
>> <input type='hidden' value ='...' name='id' />
>>?
>
>It looks like you can't right now, although you used to be able to in the
>older formless and formmethod. I'll probably add it, but I'd like to think
>a bit about the right way to do it. I can think of two methods:
>
>class IMyProxy(TypedInterface):
> id = formless.Hidden()
>
>or
>
>class IMyProxy(TypedInterface):
> id = formless.Integer(hidden=True)
>
>I think the former makes more sense, at least when it comes to html, but
>it also discards information about which Typed.coerce method to use. I
>would really like to know what you were planning to do with this invisible
>field. Right now, I can see three ways to fill the invisible field with
>your python code. The first is simply to have an 'id' attribute on your
>configurable which implements IMyProxy. This id attribute will be used to
>fill the field. The second is to pass a default value (which will always
>be the value that is used...) like so: Integer(default=5). The third is to
>get the IFormDefaults adapter around the request, and call setDefault with
>the fully-qualified key of the form field.
>
>If you were planning on filling this field using javascript on the client,
>that is a different matter entirely.
>
>Can you give me a bit more information about what you are trying to do,
>and how you would *like* to accomplish it?
>
>dp
I was planning to use it to look up the appropriate object
from an SQL database, for doing an update. However, as fzZzy
pointed out to me on #twisted.web, I should already have the
correct object from the previous stage of path resolution.
So the id field does not need to be present in the form at all;
it's implicit in the path. (E.g., in /myapp/mything/17/view,
the id is 17.)
The other use I had for a hidden field was for providing a
processing directive (possibly set by Javascript) to my form
processing code. Again, this is unnecessary with REST URLs.
Instead of, e.g., .../17/submit with dbc='update' or dbc='delete',
I can simply use .../17/update or .../17/delete.
I'm just not accustomed to REST addressing yet.
Gotta get my head turned around.
I guess what I need to do is figure out how to handle
.../17 (view entry)
.../17/edit (return edit form)
.../17/update (process edit form submission)
.../17/delete (process delete submission), and
.../new (process new object submission)
or the equivalent. (17 is just a representative ID).
- Sam