Closed jkoudys closed 10 years ago
Commit 52c3991 pushed. This adds several new features to the form helper:
<c5:form>
<c5:form-select name="favouriteFruit[]" options={ Map { 'p' => 'Pears', 'a' => 'Apples', 'o' => 'Oranges' } } selected="a" />
<c5:form-select name="favouriteFruit[]" options={ Map { 'c' => 'Cantaloupe', 'p' => 'Pineapple', 's' => 'Strawberry' } } selected="s" />
</c5:form>
and it will now render their IDs as favouriteFruit1, favouriteFruit2. This is necessary as it's what the c5 backend expects.
if ((string)$valueOrArray === (string)$k && !isset($_REQUEST[$_key]) || ($val !== false && $val == $k) || (is_array($_REQUEST[$_key]) && (in_array($k, $_REQUEST[$_key])))) {
a57a40edb7362954d7b87e1b7f9d143194ab4d17 adds a few more helpers -- avatar, and navigation helper as part of the c5:a. e.g.:
<c5:a href="/dashboard/composer/write/" task={'/edit/' . $page->getCollectionID()}>
<i class="fa fa-edit" alt="edit"></i>
</c5:a>
The above is the most basic form, and it equivalent to calling View::url(href, task). To link to a page:
<c5:a page={$parentCollection}>
{$parentCollection->getCollectionName()}
</c5:a>
I think this is shaping up nicely - I'm getting much more concerned now about properly organizing this package ( #2 ), as new classes can follow the approach I've started, now I need to know new classes are going in the right place.
I'm sort of torn on this decision, since I can see advantages to either side. So long as c5 helpers, like the form helper, are being maintained, it makes sense to use them in the interest of DRYness. On the other side, I wan to reduce the usage of that c5:raw element down to a minimum, and that won't happen as long as I'm just dumping out raw HTML from everything.
As the form helper is rendering actual HTML elements, that logic could be re-implemented inside the render() code for the :c5 elements themselves. This could be extra handy if traversing your xhp dom later on, since form elements are one of the main things you'd want to search inside your tree for.