Re: [Zope-dev] closed collector issues 1252 and 1308
Paul Winkler wrote: absolute_url - containment only, does not include contextual elements from the client's URL, that's the whole point of this method :-) What do you mean by contextual elements from the client's URL absolute_url(relative=1) - same as absolute_url, and not usable in some VHM situations. But what's it for? What change does relative=1 make? Why is it not usuable in some situtations? absolute_url_path - is usable with VHM, but still containment only. virtual_url_path - is usable with VHM, but still containment only. Again, what do both of these do? getPhysicalPath - containment only, not compatible with VHM at all and should NEVER be used for URLs. ?! it certainyl works as inteneded with VHMs, what are you trying to say here? request/URLx - close, but no cigar: leaves out traverse_subpath elements. Really? Should it? request/VIRTUAL_URL - includes context and traverse_subpath elements, but doesn't work if a VHM is not present or is not triggered. Interesting. What's wrong with just: python:request.URL+'/'+'/'.join(request.traverse_subpath)+'?'+REQUEST.QUERY_STRING ? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] closed collector issues 1252 and 1308
On Wed, Aug 25, 2004 at 01:52:26PM +0100, Chris Withers wrote: Paul Winkler wrote: absolute_url - containment only, does not include contextual elements from the client's URL, that's the whole point of this method :-) What do you mean by contextual elements from the client's URL Anything in the acquisition context (i.e. in aq_chain) that is not in the object's physical path. The use case that prompted this thread requires building URLs that include these contextual elements. Right now there is no clean, simple way to get at that information. This particular bit of information (the actual URL that the client requested) is very often irrelevant, or we'd have dealt with this a long time ago :-) But occasionally it's really handy to know. It's a wheel that people get to occasionally reinvent for no good reason, and while it's not rocket science to get it right, it IS way too easy to get wrong. absolute_url(relative=1) - same as absolute_url, and not usable in some VHM situations. But what's it for? What change does relative=1 make? Why is it not usuable in some situtations? relative=1 is the same as virtual_url_path (which it now calls). absolute_url_path - is usable with VHM, but still containment only. virtual_url_path - is usable with VHM, but still containment only. Again, what do both of these do? virtual_url_path replaces absolute_url(relative=1) which IIRC is going to be deprecated because everybody hates the inherent absurdity of it. absolute_url_path includes a leading slash and virtual_url_path does not. absolute_url_path is always safe to use with VHM but virtual_url_path may not be if it really behaves the same as the old absolute_url(relative=1). I don't recall when or why this breaks. I haven't the time to grok it right now. Anyway, neither of them include contextual elements as described above. Nor do they give you access to the traverse_subpath. So they do not fit the use case. getPhysicalPath - containment only, not compatible with VHM at all and should NEVER be used for URLs. ?! it certainyl works as inteneded with VHMs, what are you trying to say here? Yes it works as intended. See the docstring: '''Returns a path (an immutable sequence of strings) that can be used to access this object again later, for example in a copy/paste operation. getPhysicalRoot() and getPhysicalPath() are designed to operate together. ''' This says nothing about URLs because that's not the intended usage. Maybe a warning about this should be added to the docstring to make it explicit. When I said not compatible with VHM, I should have said should not be abused for generating URLs as the resulting paths do not take account of virtual hosting. E.g. such a URL does not include _vh_foo virtual path elements and it does include the hidden path elements that come before VirtualHostRoot. Of course you can use getPhysicalPath to build your URLs if you take care of these VHM issues, but why on earth should you? That's why absolute_url and absolute_url_path exist. request/URLx - close, but no cigar: leaves out traverse_subpath elements. Really? Yes, really. Should it? Good question! Why the heck doesn't it? Seems counterintuitive to me. While we're on the topic, there's also request/PATH_INFO ... which is not what's wanted because it includes the complete request sent to Zope including all the VHM gunk. request/VIRTUAL_URL - includes context and traverse_subpath elements, but doesn't work if a VHM is not present or is not triggered. Interesting. What's wrong with just: python:request.URL+'/'+'/'.join(request.traverse_subpath)+'?'+REQUEST.QUERY_STRING ? It's a mouthful, and it's non-obvious. And, one nitpick: if traverse_subpath is empty, this idiom adds a spurious trailing slash. I would rather have request/URL include the traverse_subpath. Either that or have request/VIRTUAL_URL always available, as proposed earlier in this thread. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] how to start workflow instance on another zope serverwith SOAP?
Hi, I am very new to open source. I am trying to start an instance of a workflow on a Zope server from another Zope server. I did successfully with XML-RPC call but I need to do it with SOAP. I am note sure weather I can do it or not. I am running two Zope servers on my local m/c on 2 different ports. One is 8080 and 2nd one is 8090. On 8080: Page_template : SoapTest2 html body Activate instance at other server: span tal:define= l_user python:request.get('AUTHENTICATED_USER'); form action=SubmitNewSoapTest2 method=post enctype=multipart/form-data input type=file name=p_filebr input type=hidden name=user tal:attributes= value python:l_user; input type=hidden name=password value=Aruna input type=submit value=Submit /form /span /body /html SubmitNewSoapTest2 is external method. the python script for that is testTrigger as follow. from SOAPpy import SOAPProxy import xml.sax def startTestInstance2(self,p_file,user,password): myFile =p_file.read() # parser = xml.sax.make_parser() # parser.parse(myFile) url = 'http://localhost:8090/' namespace = 'urn:xmethods-testInstance' server = SOAPProxy(url, namespace) return server.SoapTestInstance(p_file,user,password) On 8090: I have a python script SoapTestInstance having 3 parameters (p_file,user,password) and following code. wf = context.TestFlow i_id = wf.addInstance('TestProcess', '', '', '', 0) instance = wf.getInstance(i_id) instance.manage_addFile(id=theFile, file=p_file, title=) wf.startInstance(i_id) wf.activateWorkitem(i_id, '0', user ) wf.completeWorkitem(i_id, '0') return created new instance with code %s % i_id It gives me following error. Error Type: SAXParseException Error Value: http://www.w3.org/TR/REC-html40/loose.dtd:31:2: error in processing external entity reference Any help will be appriciated. I already stucked here.. Thanks Aruna Kathiriya Sr.Consultant CIGNEX Technologies, Inc T:408.501.0455 x 306 F:408.273.6785 C:408.896.1330 E:[EMAIL PROTECTED] U:www.cignex.com Implement IT Right ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Preventing scripts from being called directly
Florent Guillaume wrote: The way I do it is: ##parameters=foo, bar, ..., REQUEST=None if REQUEST is not None: raise 'Unauthorized', 'Not callable TTW' I believe this is much better. I get function not accessible in restricted mode with my own solution. Thanks, /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )