Symphony.

I’m fairly sure I catered for this already, allowing you to pass a number in the section parameter. Hopefully this will allow you do what you need:

<xsl:call-template name="form:input">
    <xsl:with-param name="section" select="'fields[0]'"/>
    <xsl:with-param name="handle" select="'option'"/>
</xsl:call-template>

The rationale for the section parameter is both to add an index like above. However passing a customised section handle allows you to use Form Controls with EventEx — an as yet undocumented piece of code for more powerful events.

Ah ha. Yes that will work as well! Thanks. But what’s EventEx?

It’s a wrapper around a Symphony Event. Put simply, it allows you to submit a form to one event, but add entries to more than one section — by using the section handle instead of fields in the HTML.

It allows you to do things like this:

<input type="text" name="articles[title]" value="My article title" />
<input type="text" name="articles[system:id]" value="123" />

<input type="text" name="comments[0][content]" value="This is a comment" />
<input type="text" name="comments[0][article]" value="articles[system:id]" />

<input type="text" name="comments[1][content]" value="This is another comment" />
<input type="text" name="comments[1][article]" value="articles[system:id]" />

This will modify an Articles entry, and submit two new Comments entries, filling in the section link “Article” field.

But I don’t want to discuss EventEx here (yet). When it’s released and documented (in the next week or two) there will be another thread for it, I’d rather keep this thread Form Controls only please :-)

That does sound a lot easier than what I did. After a brief look, would that handle something like ‘fields[0][date][start]’? It looks like if you put the first part in the section param and start in the handle it’ll confuse your template that handles sections.

Indeed it will confuse the hell out of Form Controls! This is a fringe case I didn’t consider, since the same result can be achieved using EventEx in a slightly different way (documentation to follow).

How does a field named like this interact with a Symphony event anyway?

When submitting the event given form data like fields[0..n][some name] it worked fine, and in my case I was trying to duplicate a repeating date field, which requires some other parameters. All I had to do was add the other data after the [date] parameter:

fields[0][date][start]
fields[0][date][end]
fields[0][date][mode]
fields[0][date][units]

It validates the field using the extension’s built in validation.

PHP sets the post parameters up as an multi-dimensional array, so I guess it just works out, given the way event.section.php was written. It doesn’t look like it’ll work any deeper than three parameters, but I don’t really remember PHP that well :)

How would we change it to work with:

fields[login-details][username]

You could try:

<with-param name="section" select="'fields[login-details]'"/>
<with-param name="handle" select="'username'"/>

This will send the correct post information, but will probably not work with maintaining postback values and validation. What does the XML for the failed event look like?

What does the XML for the failed event look like?

Unfortunately, Symphony does not distinguish between the two fields because it’s technically 1 (I’m using the unofficial release of the members extension). Hmm… at least your workaround gets me one step further. I love this utility!

<sign-up result="error">
    <message>Entry encountered errors when saving.</message>
    <last-name type="missing" message="'Last Name' is a required field." />
    <yob type="missing" message="'YOB' is a required field." />
    <e-mail type="missing" message="'E-mail' is a required field." />
    <home-address type="missing" message="'Home Address' is a required field." />
    <home-city type="missing" message="'Home City' is a required field." />
    <home-zip type="missing" message="'Home Zip' is a required field." />
    <mailing-address type="missing" message="'Mailing Address' is a required field." />
    <mailing-city type="missing" message="'Mailing City' is a required field." />
    <mailing-zip type="missing" message="'Mailing Zip' is a required field." />
    <home-phone type="missing" message="'Home Phone' is a required field." />
    <business-phone type="missing" message="'Business Phone' is a required field." />
    <mobile-phone type="missing" message="'Mobile Phone' is a required field." />
    <post-values>
        <first-name>huh</first-name>
        <login-details>lewis</login-details>
        <login-details>123456</login-details>
        <home-state>AL</home-state>
        <mailing-state>AL</mailing-state>
        <role>2</role>
    </post-values>
</sign-up>

I’m afraid so. Form Controls works wonders with native Events, and EventEx, but anything more then it starts becoming muddy. It was hard enough making it work with the EventEx syntax, I’m not sure I could expand it to be more generic.

I suppose for these particular fields you could just build them normally. Form Controls will still build the correct validation summary etc.

One-time submit forms such as comment, login and contact forms, using Form Controls to build text input fields may be considered overkill. Its power is realised when you need an edit form where the fields are already pre-populated on page load. Form Controls chooses what values to persist on page refreshes, which saves many if/choose/when/otherwise statements polluting your page views.

I suppose for these particular fields you could just build them normally.

I think this is a good solution :-)

@buzzomatic: Can you post your utility here? I’d love to take a look at it!

(Could you post it as a new thread — I’m sure it deserves its own discussion, and this one is getting pretty long.)

Nick

I ran across a bug in IE8 when using Form Controls along with the jQuery Validate plug-in for front-end validation.

It would throw a JS error when validating a select field because the option element did not have a value attribute.

This throws an error:

<option>January</option>

This doesn’t:

<option value="january">January</option>

Hrm, that’s more a bug with the jQuery Validate plug-in I reckon ;-)

As a quick workaround instead of using the months string to auto-generate the list, you could send through custom XML instead:

January

This should be interpreted and output what you require.

Oh, its a bug with the plug-in for sure!

Good call re the XML idea.

Nick how do I populate a drop down/list of entries from a section in form controls?

I had this but nothing shows up in the drop down?

    <xsl:call-template name="form:label">
     <xsl:with-param name="for" select="'title'"/>
     <xsl:with-param name="text" select="$labels/company-logo"/>
     <xsl:with-param name="child">
        <xsl:call-template name="form:select">
        <xsl:with-param name="handle" select="'company-logo'"/>
        <xsl:with-param name="options">
         <xsl:for-each select="/data/company-logos/@id">
           <option value=""><xsl:copy-of select="company-name"/></option>
        </xsl:for-each>
        </xsl:with-param>
     </xsl:call-template>
     </xsl:with-param>
     </xsl:call-template>

Trying to retreive the Company Names from a section called “Company Logos”

<xsl:with-param name="options" select="/data/countries/country"/>

Im pretty sure that one line does what your asking for

So if I have a section called Company logos and I want to list the company names within this section as the options.. I should use this:

<xsl:with-param name="options" select="/data/company-logos/company-name"/>

Is this right?

yup you can also add hardcoded options like a default select company for the drop down to start with

<xsl:with-param name="options">

           <option value="">Select Company</option>

 </xsl:with-param>
<xsl:with-param name="options" select="/data/company-logos/company-name"/>