Re: the TOC Code Source and lookup window in 2.2

Andy Altepeter <[email protected]> Thu, 4 Feb 2010 20:26:20 -0600
Newsgroups gmane.comp.web.zope.silva.devel
Organization Bethel University
Message-ID <[email protected]>
Hi Kit, all,
> 
> So there's a couple of points here.
> 
> 1. It would be best if the lookup window didn't make a full path when
> linking to the current container. For instance, the images toolbox
> doesn't make a full path if it's not needed. If you link to an image
> in the current container, it only inserts the image id.

Agreed.  It would be possible to just use the name of the container (which 
would be found by acquisition), but if the container was renamed the reference 
would break.
> 
> 2. I tried using, instead of the container id, a '.'. That didn't
> work. Too bad, because if it did, that toc would work regardless of
> moving or renaming. Another option would be to accept an empty field
> and then the toc would display the contents of the current location.
> Maybe this is a better idea?

I think a single '.' is the best approach, and more explicit than an empty 
field.  This would be possible to do, in one of two approaches:

1) would require changing the lookupwindow code (to place a '.' instead of the 
full path) whenever placing a reference to the current container.  This 
behavior would then take effect every time, and affect all uses of the 
lookupwindow (wherever it is used to place references to containers).  This 
could have a large impact on other external / code sources.

2) add an additional, optional parameter to the javascript call 
'reference.getReference' (which opens the lookup window), which will enable 
the use of a '.' for references to the current container.  New lookupwindow 
fields could have this enabled by default.

Thoughts?

> ps: At this moment the toc lookup window doesn't insert. It pops up
> but when I try to select something, but it doesn't close itself and
> insert a path. This might be my system, although I tried it with both
> FF3 and Safari.

This problem isn't with your system.  Silva 2.2 introduces new features to the 
lookupwindowfield.  In addition to the "edit reference" button, it now 
supports multiple references in separate input fields.  It is possible to add 
more references to the TOC "paths" field by clicking the "plus" button.  This 
is good for the TOC code source, as it unifies the "toc" element with the 
"multitoc" code source delivered with SilvaExternalSources.   I don't think 
this discrepancy is cleaned up in the 2.2 beta yet (so there are two TOC code 
sources in service_codesources).  Additionally, the lookupwindowfield and 
referencelookupwindowfield now have the exact same functionality.

This field can have a configurable number of references, up to a maximum (also 
configurable).  Unfortunately, this good change also required a change to the 
"onclick" javascript for the "lookup reference" button.  I don't believe this 
has been documented yet, nor due to the nature of the onclick field (it is 
javascript text) has an upgrader been written.

The old onclick handler was this pattern:
reference.getReference(
function(path, id, title) {
document.getElementsByName('%(field_id)s')[0].value = path;;
}, '%(url)s', 'Container', true)

Where the string 'Container' was empty by default, and can accept various 
classes of silva content types (container, content, assets) or meta types.

The new javascript code is this (and can be seen if you add a new lookupwindow 
field):
{
var myid = this.getAttribute('id').replace(/^button/,'input');
reference.getReference(
function(path, id, title) {
document.getElementById(myid).value = path;;
}, '%(url)s', 'Container', true, '%(selected_path)s')}

In order for the looupwindowfield's 'get reference' buttons to function, they 
need to be updated to match the above code.

I'm hesitant to write an upgrader to change this, since it is javascript and 
quite possibly has been changed from the default.  But I suppose an upgrader 
could be written to inform the site manager where the lookupfields are.  I 
welcome any feedback about this process, and also ask where I might be able to 
put up documentation about this?  Prior to Silva 2.2 these were placed in the 
'developer_changes.txt' file in the Silva product.

peace,
Andy