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