[TransWarp] peak.web and forms
roche at upfrontsystems.co.za
Tue Aug 5 14:15:45 EDT 2003
* Phillip J. Eby <pje at telecommunity.com> [2003-08-05 16:32]:
> Now that I've explained all that,
Thank you very much, I really appreciate it. There are a lot classes in
the web mix at the moment and to get one's head around - an updated web
example will really help ground the concepts and make more feedback
> >> Mostly good, but there are some pieces I'm having trouble wrapping my
> >> around, like where does the POST go to? What if there's more than one
> >> on the page? (These two questions overlap a bit, since if there's more
> >> than one form, they can't both POST to the same place.) If you POST to
> >> widget set (a logical alternative), how do you get back to the template
> >> that rendered the submitting page?
> >I think this is really a pattern that each app should work out for
> >itself but what follows is what I would like to do. I am not sure yet
> >how this would work in PEAK but the POST goes to any method that keeps
> >the form stuff in play eg. (I'll try to explain this in PEAK terms): I
> >want to add, edit and view contacts TTW. I create an IWebTraversable
> >that has add, edit and view methods - lets call them actions. 'add',
> >'edit' and 'view' returns the templates 'add_template', 'edit_template'
> >and 'view_template' when called for the first time or when we come from
> >a given location. Each of the contact templates are coded to post back
> >to their corresponding action on the contact traversable.
> Hmmm... here's an interesting thought... I could make the
> CallableAsWebPage adapter look for a 'templateResource' attribute on a
> method, and then pass the return value of the method as input to the
> template in some way. So you'd do, e.g.:
> def add(self, REQUEST):
> add.templateResource = "contact_addForm"
> Of course, I'm not sure that this really saves anything. It may be that I
> should just work out how to easily invoke a template from inside a method
> on an object.
At the moment they can only be invoked from a TraversalContext, right?
And a WebTraversable has access to the traversal context so one should
be able to instruct a template to render itself from there as well?
> One thing that talking about this scenario has brought up,
> is that there's currently no way to get at the traversal context from
> inside a method like this, so that makes things harder.
Inside methods of which other objects should a template be accessible?
It sounds convenient to have access to the context all over the place
but on the other hand if one only has access to the traversal context
from within a web traversable or a decorator won't this enforce a modular
design? Anyway, it feels like I might be missing the point again,
or lacking context ;-)
> Otherwise, you
> could just say something like:
> return context.subcontext('addForm', self.addForm).render()
> return context.contextFor('addForm').render()
What is the difference between just "context" and
"contextFor('addForm')" in the line above. I know the interface says
contextFor returns a new traversal context but why would you want one?
> depending on whether 'addForm' was publicly accessible. Hmm, technically
> the above should both be context.getParentComponent().whatever, as the
> context would be the method, not the owner of the method. So you'd have to
> go "up one", then "over".
> Clearly, I need to have a way to allow the traversal context to be passed
> to Python methods; probably this will be as simple as setting a value in
> the request, that you can then use as a parameter name. Maybe
> CONTEXT? traversalContext? ctx? Maybe CONTEXT for the context and
> SUBJECT for the context that references the object whose method it
> is? I'll think on this.
I like CONTEXT, all capitals. It think CONTEXT is just one of those
variables that should be highly visible so that you don't loose it ;-)
Upfront Systems http://www.upfrontsystems.co.za
More information about the PEAK