<?php echo $form->label('page_list_parent_id', t('Page List 1')); ?> <?php echo $page_selector_form->selectPage('page_list_parent_id', $parent_id); ?> <?php echo $form->label('page_list_parent_id', t('Page List 2')); ?> <?php echo $page_selector_form->selectPage('page_list_parent_id', $parent_id); ?> <?php echo $form->label('page_list_parent_id', t('Page List 3')); ?> <?php echo $page_selector_form->selectPage('page_list_parent_id', $parent_id); ?>
It works fine for me personally since if I ever need more I can just add to the add/edit.php but it would be nice to add and remove these dynamically so that this can be a little more re-usable for others.
I have tried looking at Image gallery type blocks to see how it's done, as a sort of model, but I still don't understand everything that's going on with that stuff. Maybe I'll figure it out soon.
Once the jQuery has cloned the row, the most I would expect to have to do is tweak an element before re-writing it to catch any duplicated id="" or name="".
The first is the dialog popup, and the second is the trash can. I guess I can take a look at the form helper and probably pull out the trash can code. And I'm just not overly versed in using the concrete5 dialog popup. Is there a howto of that lying around?
Btw, those two howtos(the add row and sortable) are great work. Thank you for those.
after creating the page selector via the method describe in the howto(except I used siblings instead of closest) I get a new select box. All that is left is to bind an even to the trash can that removes the selector instead of just removing the page selection. I guess I'll post the snippet when I'm done.
That did the trick for me!
I found a more efficient way to dynamically change the selected page of the Page Selector widget via JS:
It works in 18.104.22.168, haven't tested in earlier versions.
Just mentioning it here in case you like that better and want to update your how-to with it. (But I won't be offended if you like everything the way it is already :)
Weird that C5 defines the function body in this way and doesn't just have the function defined for utility purposes and then either call that utility or your own callback when needed (not sure if that makes sense).
Carry on then.
Its interesting stuff and stuff that I will find useful, but I think that (unless I am cleverer I thought I was) you may be crediting me with someone else's howto.
The howto I link above is purely about making a growing form.
...which is by Mnkras. Not sure why I thought that was you (maybe linked from some other post). Okay well everything I've said here today is wrong then. Meh, Friday.
First, in each "row", I have this:
<div> Link To Page: <span class="gallery-selected-page-name" data-slideshowImgId="<?php echo $imgInfo['slideshowImgId']; ?>" style="font-weight: bold;"> <?php echo ($imgInfo['linkToCID'] > 0) ? Page::getByID($imgInfo['linkToCID'])->getCollectionName() : ''; ?> </span> <span class="gallery-clear-selected-page" data-slideshowImgId="<?php echo $imgInfo['slideshowImgId']; ?>" style="display: <?php echo ($imgInfo['linkToCID'] > 0) ? 'inline' : 'none' ; ?>;"> [<a href="#" onclick="clearPageSelection(<?php echo $imgInfo['slideshowImgId']; ?>); return false;">X</a>] </span> <span class="gallery-select-page-wrapper" data-slideshowImgId="<?php echo $imgInfo['slideshowImgId']; ?>" style="display: <?php echo ($imgInfo['linkToCID'] > 0) ? 'none' : 'inline' ; ?>;"> [<a class="gallery-select-page" dialog-width="90%" dialog-height="70%" dialog-modal="false" dialog-title="Choose Page"
($imgInfo is an array that contains data about the one particular image that this "row" is for).
Then I have this code in one place on my add/edit page (so this is used by all the rows, not repeated for each):
Not saying this is the best way to do it, but maybe between the slideshow block and this it can help you understand the necessary process better?
What do you think such a widget should include? Off the top of my head, I'd think there should be one specifically for files, and then one that's more generic and you could put any other fields in. The display options could be to include a sitemap selector, an image selector, etc.
One thing that weirds me out about the way the built-in slideshow block does things is instead of just adding a row and then choosing an image for that row, you add the image and that adds the row. I guess this is a little more efficient for the user because it's just one click (and perhaps more importantly, it lets you choose more than one image from the file manager at a time, which is really cool). But for a more general-purpose widget like this, I wonder if it would be better to just have file selector and sitemap selector as options that could be on a row, and you just add blank rows regardless of what's in them?
Does any of this even make sense? What do you think? Want to help build something like this after the new year?
Trigger jquery events or callbacks (or both) for add/remove/sort (for list items) and open/close/select/cancel of inner C5 helpers should give enough hooks for integrating functionality into the list.
Whilst the current thinking is rows of a table for form elements, what is actually within a row should be any DOM element, so maybe the entire structure should be div based rather than table based, that way it could format the list across a page or flow and wrap down a page.
Such a flexible list widget may also be useful for front end functionality, not just add/edit and dashboard forms.
As for clean and re-usable I would love to see an outside core addon library. Something that could evolve outside the core but be a somewhat standard toolkit for addons.
I'll post back when I get it together.
On the bricks and paving games I cloned the dialog elements before opening, stored the clone, then rebuilt them where needed after closing.