On Thu, 20 Oct 2005 22:19:58 -0700
Naotoshi Seo <[EMAIL PROTECTED]> wrote:
> This is easy problem in normal web application. Scripts which receive
> POST just print out new html (in this case Classname.post). However, I
> would like to use browser:editview and I have only idea, redirecting, to
> sh
Hi. I have one more question.
Imagine there are a MessageBoard and many Message objects.
I would like to allow users to modify only his message as common message
board if user type a password for the message.
I made a view to show forms to be typed password, and I processed POSTed
values, and I r
Hello.
On Thu, 20 Oct 2005 20:20:17 -0700
Naotoshi Seo <[EMAIL PROTECTED]> wrote:
> So, this is just redirecting to different page after users add object.
> I have no idea to access to the data of the added object at
> 'nexturl.html'. If possible, I can show what users inputted.
You can use "add"
I would like to make a page like that users can make sure what they
inputted at addform page. Now, my codes are simply like
And, in the specified class name,
class Classname:
def nextURL(self):
return 'nexturl.html'
So, this is just redirecting to different page after us
Johan Carlsson wrote:
For anyone that might be interested in the update to my code (still only
parsely working):
Here is my code (which uses the Poll as base, that stuff has been
removed though):
interfaces.py:
from zope.interface import Interface
from zope.schema import Object
from zo
Johan Carlsson wrote:
Hi all,
I'm trying to figure out the easiest way to get fields holding Files or
Images in my content type class.
I've tried the following:
I've tried using the Object field specifying the
zope.app.file.interfaces.IFile as the schema and then
implement a CustomWidgetFac
Hi all,
I'm trying to figure out the easiest way to get fields holding Files or
Images in my content type class.
I've tried the following:
I've tried using the Object field specifying the
zope.app.file.interfaces.IFile as the schema and then
implement a CustomWidgetFactory with zope.app.file
On 10/20/05, Chris Withers <[EMAIL PROTECTED]> wrote:
> What an unfortunate name, I'd have called it Uncomparable on some such...
While the current name is unfortunate, and Uncomparable would make the
two easier to distinguish, Uncomparable would also be wrong. (If a
comparison cannot be performe
Fred Drake wrote:
A rich-comparison method should return NotImplemented to indicate that
it doesn't implement the specific comparison; the response should be
for Python to allow the other operand a chance to handle the
comparison (inverted, of course).
Oh :-(
What an unfortunate name, I'd have