livepage and IClientHandle().transient
Hi, I'm in trouble with livepage. Looking at livepage.LivePage.__doc__ I can see this example: ..... def render_clickable(self, ctx, data): def hello(ctx): return livepage.alert("Hello, world. You can only click me once.") return ctx.tag(onclick=IClientHandle(ctx).transient(hello)) ..... I have tested it, but I can't find IClientHandle inside the "normal" page context; I can find it only inside the handle_XX's context, but I can't use "transient" (It doesn't function, I can click as many times as I want). How can I "grant the client the capability of calling a handler once and exactly once"? I'm going to use the server side sessions and something similar "return client.get(btn_idname).disable=true"... but I don't like it. thanks Alessandro
On Sat, 24 Jun 2006 02:04:21 +0200, Alessandro
Hi, I'm in trouble with livepage. Looking at livepage.LivePage.__doc__ I can see this example: ..... def render_clickable(self, ctx, data): def hello(ctx): return livepage.alert("Hello, world. You can only click me once.") return ctx.tag(onclick=IClientHandle(ctx).transient(hello)) .....
I have tested it, but I can't find IClientHandle inside the "normal" page context; I can find it only inside the handle_XX's context, but I can't use "transient" (It doesn't function, I can click as many times as I want).
Check that you are using livepage.LivePage as a base class and report here the code you are using _completely_.
How can I "grant the client the capability of calling a handler once and exactly once"?
With transient.
I'm going to use the server side sessions and something similar "return client.get(btn_idname).disable=true"... but I don't like it.
Sessions should not be used at all because you must always be able to serialize them and their fields should remain somewhat fixed. I suggest moving to Athena which is newer and more actively maintained and better overall, moving from one to the other is not very complex or hard if your app is not medium-big and there is a considerable gain in code complexity using Athena (less closures and such).
Valentino Volonghi aka Dialtone wrote:
Check that you are using livepage.LivePage as a base class and report here the code you are using _completely_.
At the bottom of this email. I'm using nevow from svn, last revision. Python 2.4.1
I'm going to use the server side sessions and something similar "return client.get(btn_idname).disable=true"... but I don't like it.
Sessions should not be used at all because you must always be able to serialize them and their fields should remain somewhat fixed.
I can't understand: why sessions should be "serializzable"? Do you mean that I should be able to write them to a file whenever I want?
I suggest moving to Athena which is newer and more actively maintained and better overall, moving from one to the other is not very complex or hard if your app is not medium-big and there is a considerable gain in code complexity using Athena (less closures and such).
Probably you are right; my app is only made by few test modules. I have choosed livepage because It is simpler to understand IMHO Thanks Alessandro Here the code: from nevow import appserver, loaders, tags as T from twisted.application import service, strports from nevow.livepage import glue, LivePage from nevow import livepage class LiveExample(LivePage): docFactory = loaders.stan( T.html[ T.head[glue], T.body[ T.invisible(render=T.directive('choice')) ] ]) def render_choice(self, ctx, data): def chosen(ctx, choseWhat): return livepage.set("choosable", \ ["Thanks for choosing ", choseWhat]) chooser = livepage.IClientHandle(ctx).transient(chosen) return T.span(id="choosable")["Choose one:", T.p(onclick=chooser("one"))["One"], T.p(onclick=chooser("two"))["Two"]] site = appserver.NevowSite(LiveExample()) application = service.Application("site") strports.service("8080", site).setServiceParent(application)
On Sat, 24 Jun 2006 14:23:43 +0200, Alessandro
At the bottom of this email. I'm using nevow from svn, last revision. Python 2.4.1
Ok, I think this is a bug. IClientHandle is not registered in the context so transient cannot be used in the way it is documented (at least). This is a bug IMHO and you should report it in trac under divmod.org. But as I said the current version of livepage (which I think should be removed because buggy, not really working and not very supported lately) is not the main one.
I'm going to use the server side sessions and something similar "return client.get(btn_idname).disable=true"... but I don't like it.
Sessions should not be used at all because you must always be able to serialize them and their fields should remain somewhat fixed.
I can't understand: why sessions should be "serializzable"? Do you mean that I should be able to write them to a file whenever I want?
Sessions are not in your control. Sessions are there for the server and not for the user. It's the server that needs to distinguish between different requests from the users and not the developer. Sessions are also a complete implementation detail (I mean the session object) because it could easily be just a string (although that would be impractical). Adding/Removing stuff from something that you do not own is pretty risky and it's asking for trouble.
Probably you are right; my app is only made by few test modules. I have choosed livepage because It is simpler to understand IMHO
Not understanding the source of a problem is a clear sign of not being simple. Athena and livepage are similar in respect to difficulty and IMHO the americano way is a bit better.
On Sun, 25 Jun 2006 02:31:21 +0200, Valentino Volonghi aka Dialtone
Not understanding the source of a problem is a clear sign of not being simple. Athena and livepage are similar in respect to difficulty and IMHO the americano way is a bit better.
The Athena way not the americano way... Yesterday night I must have had very bad problems...
participants (2)
-
Alessandro -
Valentino Volonghi aka Dialtone