[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