Re: [Zope-dev] closed collector issues 1252 and 1308

2004-08-25 Thread Chris Withers
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

2004-08-25 Thread Paul Winkler
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?

2004-08-25 Thread Aruna Kathiriya

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

2004-08-25 Thread Dario Lopez-Kästen
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 )