[Zope] List editing with page templates

[Richard Wesley]

Dieter -

Thanks for your patience.

At 9:44 PM +0100 3/30/02, Dieter Maurer wrote:
>Richard Wesley writes:
>  > I need to create a form (using page templates) that does roughly this:
>  >
>  > <BasicData>
>  >
>  > <selectable list of homogenous objects to attach to BasicData>
>  >
>  > <list of homogenous objects already attached to BasicData>
>  >
>  > The problem is that I can't seem to make the attached list
>  > persistent.  In my action script for attaching a new list object, I
>  > check the request to see if the list is present and append the
>  > selected object to the attached object list, but the script never
>  > seems to have access to the request passed to the form.
>Please read the "Web publishing" section of
>
>   <http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html>

Fabulous.  I will read it all!

>You will find that "REQUEST" is what the name suggests (oh wonder!):
>a description of a single, the current, request: no memory for
>earlier requests.

Except that this was not what I was finding empirically, but I was 
unsuccessful in finding an explanation of why this is the case.  It 
appears that if I have a form whose action is a script that reloads 
the page with a changed request variable, that I have no need of 
sessions:

Script 'action':

##parameters name,age,cmd,names=[]

if cmd=='Add':
	names.append('name':name,'age':age})

request.set('names',names)

return container.form()

Template 'form':

<form action="action>
...
<tr tal:repeat="n request/names">
...
<input type="text" name="name">
...

This seems to work without resorting to session objects:

>When you need such a memory, you are looking for a session.
>Zope 2.5 comes with an integrated session product.
>It's very easy to use:
>
>      SESSION.set(key,value)
>
>sets "key" to "value" in one request and
>
>      SESSION[key]
>
>retrieves it in later requests.

which I _had_ found but didn't spend a lot of time on because it 
seemed like overkill.

This seems to require a coding style where you always link to scripts 
which then return a display page template.  That style had a sort of 
aesthetic appeal (Controller/script being central rather than 
View/web page), but as I am new to this sort of application 
development, I was not sure if that was a good idea or not.  (Which 
is also why I am interested in reading your book.)

>An alternative is to code the list in a sequence of hidden variables:
>
>      <input type="hidden" name="myList:list" value="val1">
>      <input type="hidden" name="myList:list" value="val2">
>      ....
>
>Needless to say, that this is much more work...

Not to mention ugly, storing the data in a very unnatural place, 
brittle and hard to maintain!  I think both we agree this is a bad 
idea just on general principles.
- rmgw

http://www.electricfish.com/hawkfish/

----------------------------------------------------------------------------
Richard Wesley           Electric Fish, Inc.       hawkfish@electricfish.com

"The professor is teaching me about 'tea'.  It's very complicated."
         - Leela in "Dr. Who: The Talons of Weng Chi-An"