Re: restrictedTraverse() and encapsulated image Codesource with VMH

Heiko Besemann <[email protected]> Thu, 16 Jul 2009 10:02:49 +0200
Newsgroups gmane.comp.web.zope.silva.devel
Message-ID <af1679f66ce5a7e72b2fd439969bcc86@localhost>
Hi Kit,

thanks for your info. I think that we can live with the workaround (adding
the path) or simply put the pictures in the same or subfolder as mentioned
by you. On the other hand I had the same idea, fixing the code source
template and adding some additional program logic to find out if we are in
a vhost tree or not. 

So for now I played around with something like this (path is the argument
passed to the script which is the absolute path to test.jpg like
/bilder/test.jpg):

-- snip --
strPath = ''
lstObjstr = context.getPhysicalPath()  # get complete path from cms root to
object
for strObj in lstObjstr:
strTmpPath = '/'.join(lstObjstr)   # create full absolute path (like
/cms/watt/bilder/test.jpg)
iPos = strTmpPath.find(strObj)     # find position of my current context
object
strTmpPath = strTmpPath[:iPos]     # now roll back from current object to
cms root ...
oObj = context.restrictedTraverse(strTmpPath)
try:
binding = context.service_metadata.getMetadata(oObj)
boStatus = binding.get('silva-layout-vhost-root', element_id='vhostroot') #
... and check if we found a vhost meta data property
if boStatus:
strPath = '%s%s' % (strTmpPath, path) # if yes, return the path to vhost
publication and add the relative path (/bilder/test.jpg)
return strPath
except:
pass # not all objects do have meta data so ignore this exception
return path # if no vhost meta data property was found return the relative
path as it must be like the relative path
-- snapp --

The above code works when I execute it from the pages context (i.e. put
that script into the folder object) and I am not using the same object ids
twice (find would get confused, but should be fixed with a few more lines
python).

However when I put this into code source (my cs is located on an upper
level behind vhost) I get an error, because context.getPyhsicalRoot() will
get the path for the code source location and not the context of the silva
page location. I think that I have to pass an additional argument from the
zpt to the script telling it the page's context.

So for now this is ok and I will switch DNS entries in a few days to get an
old website running on new Silva cms ;-)

Cheers,
Heiko


On Wed, 15 Jul 2009 17:19:21 +0200, Kit BLAKE <[email protected]> wrote:
> Hi Heiko,
> 
>> my name is Heiko and I am the technical maintainer of  
>> www.noordsee.de, a
>> small website running Silva 2.1. Currently I am migrating content  
>> from an
>> older legacy website to a new publication within noordsee.de's root  
>> folder
>> and found a problem with code source encapsulated image using
>> restrictedTraverse().
>>
>> For the setup (all absolute paths beginning from the Silva root:
>>
>> (1) /cms        # This is the noordsee.de's Silva root (virtual host
>> monstered as www.noordsee.de)
>> (2) /cms/watt   # This is the new publications root folder (currently
>> vhm'ed as beta.noordsee.de, the folder is marked as virtual host  
>> within
>> Silva)
>> (3) /cms/watt/pictures/test.jpg  # Here is my image object located
>> (4) /cms/watt/watt_allgemein/gezeiten/sturmflut # Here I want to
>> encapsulate an image found in (3)
>>
>> The problem I run into is when I want to link a code source  
>> encapsulated
>> image found in (3) to a Silva document found in (4). Code source  
>> stores
>> only "/pictures/test.jpg" as the image_path, whereas  
>> restrictedTraverse()
>> called from "/watt_allgemein/gezeiten/sturmflut" would need the  
>> absolute
>> path (3).
>> This happends only for virtual hosts.
> 
> This code source has been around for a long time but you're right, it  
> not working in virtual host situations when the image is not in the  
> same folder or a lower folder as the doc. Fixing that is a tricky  
> proposition. This issue created a lot of discussion, but no clean  
> solution.
> 
> There is a workaround. When you use the 'get reference..." button  
> while editing the code source, the lookup window returns a path from  
> the virtual host root. In your case that is /pictures/test.jpg. If you  
> manually add the missing path segments above the vhr, so the content  
> of the image path field is:
> 
> /cms/watt//pictures/test.jpg
> 
> Then save the code source and save the doc, the encapsulated image  
> should render properly.
> 
> 
>> When I put as a workaound the image
>> file within the same folder where the document is located it works ok.
>> Nevertheless to get a more structured website a separate pictures  
>> folder
>> would be good.
>>
>> So my question to the folks the at silva-dev is how can I modify
>> encapsulated image code source to get the full absolute path needed by
>> restrictedTraverse()? Funny thing is that linking an image with the
>> standard image koopu menu function Silva returns the full absolute  
>> path.
> 
> With the image path there is some work done 'underwater', where the  
> path from the vhr is saved, but removed when displaying to an author  
> in the editor. Sometime authors don't know they're in a vh, and it  
> could get confusing.
> 
>> On the code source site the fomulator view uses the following call to
>> launch Silva object browser:
>>
>> (onclick event fired)
>>
>> reference.getReference(
>> function(path, id, title) {
>> document.getElementsByName('%(field_id)s')[0].value = path;;
>> }, '%(url)s', 'Silva Image', true)
>>
>> Would it be clever to change the onclick function to use the same  
>> function
>> the standard image selector uses?
> 
> Both lookup windows store the same path segment. But for the image  
> there's a modification on save. You can see this if you examine what's  
> saved in the raw xml.
> 
>> Or would it be clever to modify the
>> template file used by code source encapsulated image? There I found  
>> the
>> following line...
>>
>> ...
>> imagepath    options/image_path;
>> image        python: context.restrictedTraverse(str(imagepath));
>> ...
> 
> If you have authors that shouldn't be bothered with the above  
> workaround, we could do something like this:
> 
> ...
> vhostsegment  
> python:get_not_yet_written_code_to_return_vhost_path_segment;
> imagepath    options/image_path;
> image        python: context.restrictedTraverse(str(vhostsegment +  
> imagepath));
> ...
> 
> Actually there would have to be another step to make sure it works  
> with relative urls too, where we only insert the vhostsegment if the  
> path begins with a slash, but you get the idea....
> 
> Hope this helps,
> 
> Kit