From: Ken W. <ke...@su...> - 2009-06-03 18:51:36
|
Raphael Ritz wrote: > > ... > while I'm not sure I understand your issue couldn't you just > write a little script yourself that gets the custom var from > the query string, calls invokeFactory to construct the object > and then edits it accordingly? > > Something like > > context.invokeFactory(type_name=MyType,id=some_id) > new_object = context[some_id] > new_object.edit(myattr='shiny new value') > new_object.reindexObject() > > (and then return whatever you see fit or re-direct > to the new object's URL) > Thanks, Raphael ~ My question about your suggestion is: Where/how can I "install" this little script so that the script gets called at the right point in the servicing of a GET request, and the args that it captures are passed on to the code that needs to make use of it in responding to the request? My understanding of the process of responding to a GET request for an Archetypes object is this: 1. The request arrives at the Zope web server. Its URL includes an HTML query string, in the format "?arg1=val1&arg2=val2". The query string is the only place that the args are available to the responding server. 2. ZPA (Zope/Plone/Archetypes, which here I am treating as a single black box) follows the URL path and determines that the request is for an instance of an AT content type. Based on the actions and aliases in the content type definition, ZPA rewrites the tail of the URL. Among other things, it discards the query string from the original URL. Then it calls the rewritten URL. In my case, the rewritten URL triggers the controller script (.cpy) of the requested AT object. 3. The .cpy script would be the right place to mine out and use the arg data. But the arg data are not available to it anywhere, as far as I can tell. The rewritten REQUEST object no longer contains them anywhere - for example, the URLs it shows are the ones that ZPA rewrote back in step 2, where it tossed out the args. As a Plone product developer, I have full control over the URL that is built in step 1 and the script that is invoked in step 3. But I don't have control over what ZPA does in step 2 - except what I put into my content type definition, and I don't know how to tweak that definition to get a live argument through to my script. If someone can show where my understanding of this process is faulty, maybe we'll have a solution. ~ Thanks ~ Ken -- View this message in context: http://n2.nabble.com/Passing-a-dynamic-argument-to-an-Archetype-instance-tp2984939p3020291.html Sent from the Archetypes mailing list archive at Nabble.com. |