pat-checklist selectAll/deselectAll only works inside .pat-checklist element

[adrianwhite]

Initially raised in ploneintranet/ploneintranet.theme#23

Whilst working with @cornae we tried to add buttons for Select and Deselect All outside of the pat-checklist element and target them via an id and class but they did not function.

<fieldset class=pat-checklist" data-pat-checklist="select: #ElemOutsidePatChecklist .select-all; deselect: #ElemOutsidePatChecklist .deselect-all" >

@cornae mentioned he thought this was a regression as he had seen them function outside of a .pat-checklist element before.

The js only looks for the select and deselect elements within the checklist ($trigger), line 27 and 28 of checklist.js:

$trigger.find(options.select).on("click.pat-checklist", {trigger: $trigger}, _.onSelectAll);
$trigger.find(options.deselect).on("click.pat-checklist", {trigger: $trigger},_.onDeselectAll);

This is my first issue raised for this repo, is there anything I can do to make it better/clearer?

[wichert]

The current behaviour is deliberate: for many patterns, including this one, you want to use a selector against the local context for the pattern. For example when you specify the selector for the close-button of a tooltip you only want that to match the close button in the current tooltip – you don't want to all close buttons on a page to close all tooltips. That means that changing our standard behaviour to always search globally we have a large risk of undesirable behavioural changes.

I can think of several possible ways to try to address this:

• if a selector fails to find anything in the context of the pattern retry the search globally. This will result in strange behaviour in existing sites where a selector currently does not match (for example a tooltip without a close button), and the selector would suddenly find other elements on a page.
• if the selector is rooted at an object id do a global search, otherwise always do a local search. This should be safe.
• add a new flag to every pattern which indicates of a selector must be interpreted locally or globally. In my opinion that would result in an overly complex API.

[jcbrand]

I've opted for the middle option. Do a local search, unless the selector starts with an object id.

[adrianwhite]

@jcbrand Sorry, I meant to reply to your initial response.

I've opted for the middle option. Do a local search, unless the selector starts with an object id.

This does seem the cleanest solution.

Cheers for doing this.

[cornae]

+1

Op 5 sep. 2014 om 17:19 heeft Adrian White notifications@github.com het volgende geschreven:

@jcbrand Sorry, I meant to reply to your initial response.

I've opted for the middle option. Do a local search, unless the selector starts with an object id.

This does seem the cleanest solution.

Cheers for doing this.

—
Reply to this email directly or view it on GitHub.

[jcbrand]

@adrianwhite Thanks, my pleasure.