Lookup window needs to list containers

Assigning to thisfred who's already subbed – I think – because his name is listed.

Is this something you'd like me to work on? At least the part about including containers in all lookups?

If the filter doesn't include containers, I suppose the containers in the list shouldn't have a radio button?

Yes, please do. Right, If the filter doesn't include containers, the containers in the list shouldn't have a radio button. If you can figure out how to make the item place when the radio button is selected, that would be cool.

Since I'm in here, I'm also going to add a "place reference to this container" button at the bottom, per a user request.

I've committed changes to get the containers listed (but not selectable, by setting visibility: hidden in the input field).

I added a "place reference to this container..." button. The text is rather long, but I'm not sure how it can be shortened.

I haven't added the JS to auto-place-reference when a radio button is clicked. I'll do that soon.

This is a check fo the obvious: with some filters, it *is* the idea that authors can select (place) containers and then the visibility of the radio button should be on. In other cases, e.g. when the filters is images only, the containers are displayed for navigation.

The "place reference to this container..." button is curious. I guess they sometime navigate into a container when they should have selected it. Can't think of a shorter button text. "reference this container" maybe, but it's missing the keyword place.

If the placing happens automatically when a radio button is selected, we might just remove the "place reference..." button altogether.

I've double-verified that containers are placeable when they should be, and not placeable when they shouldn't be.

The placing is now automatic. As such, I've set removed the "place reference" button, so now the only two buttons on the bottom are "cancel" and "place reference to container...".

After someone commented about the lack of a "place reference to this container" button, I found, when using the reference lookup window, that button would actually be very useful. I found that I was often going up one level to link back to the container. Let me know if you don't like it, and I'll remove it.

This works nicely and the automatic place action is a big improvement, preventing the need to scroll through long listings of content to find the button.

As reported by Marc Petitmermet:
>> Several lookup window improvements:
>> 1. the lookup window will now always list containers which you can
>> click to ‘drill down’, in addition to navigating with the sidebar
>> 2. a “place reference to this container...“ button was added, so you
>> don’t have to use the sidebar to navigate up one level
>
> well, this feature does not make any sense in the "get image
> reference" because a container is not an image;-)

Can we hide this button conditionally? (If that means a lot of work, it might have to wait, we're in 2.1 triaging mode, hoping to release tuesday, so I want to avoid large changes that might break things)

Moving to milestone 2.2

mostly fixed this problem of displaying the "place reference to this container" button for Silva 2.1. I added logic to the button like:
tal:condition="python:not show_containers and ..."

show_containers contains the list of subcontainers in the current container in the event containers are to be "shown" rather than selectable (i.e. the radio buttons are hidden)

The fix above will work in all cases except when there are no sub-containers, as "show_containers" will then be false anyways.

For 2.2, I need to adjust this so that the value returned for show_containers from Silva.browser.lookup objectLookupGetObjects is a true/false AND the list of containers. During the "place reference to this..." refactor show_containers became the list of containers that shouldn't be selectable, which is buggy when the current container has no containers. The list of containers was returned because there are many different types of containers, some of which may be selectable, so just returning true/false isn't accurate enough. Perhaps there is a better way to fix this than how I described, I don't know yet.

The 'place reference to container...' button now only displays when it is an acceptable meta type to be selected. I added a method on Silva/browser/lookup/ObjectLookup, displayContainerReferenceButton(filter) which, based on the filter, determines whether the containers meta type can be selected. If true, the button is displayed in the lookup window.

released in 2.2a