Symphony.

A new extension, "Sections event" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Read about & grab from GitHub.

It looks great! I will try for sure.

I wonder if it prevents data from being entered into unwanted sections for some malicious attempt by changing the html frontend.

Thanks Vlad!

you're a genius.

I wonder if it prevents data from being entered into unwanted sections for some malicious attempt by changing the html frontend.

It doesn't. That's one of my concerns as well.

A few days ago I opened an issue in the Members extension to allow setting of permissions at section level, beside events.

Sections event updated to version 1.1 on 26th of January 2013

Important improvements:

• Variable replacement in posted field's data now extended to any field, not only system:id. See examples #4 and #7 from readme.
• Reworked Identification parameteres for sform-controls. They can now cover any sort of field and requirement.
• Event now passed as a string handle instead of XML node-set.
• Control ID identification parts are now separated by _ instead of -.
• Reworked validation for sform-controls. It now allows individual control validation, better control of rendered mark-up, full custom rendering.
• Added a new template for helping the build of a replaceable variable. see here

Nice extension and great timing for me :)

Just one question. Everything works great except one thing. Maybe I missed something. I have two sections Forum Topics and Forum Posts which are chained together.

For showing validation messages i wrote:

<xsl:variable name="interpretation">
<xsl:call-template name="sform:validation-interpret">
    <xsl:with-param name="section" select="$section_topics"/>
</xsl:call-template>
<xsl:call-template name="sform:validation-interpret">
    <xsl:with-param name="section" select="$section_posts"/>
</xsl:call-template>

If I don't pass 'section' parameter - validation messages are not rendered. If I specify one of my section, validation messages are appeared (for the section)

So I tried to pass both sections to show all validation messages. Of course, its works, but to show message header for both sections.

What i missed, if i want to show only entry error + fields errors. Customize render template? Or something else?

Thank you

The validation is done per 'Entry' basis. So you will have a validation for your Forum Topics entry and another validation for the Forum Posts entry.

If you want to display a unified report you have two options:

1. Store each interpretation in it's own variable and output as you please.
2. Store each interpretation in it's own variable, merge them together in a new interpretation variable and then output using the sform:validation-render template.

eg for #2:

<!-- Get interpretation for Topics -->
<xsl:variable name="i_topics-nodeset">
    <xsl:call-template name="sform:validation-interpret">
        <xsl:with-param name="section" select="$section_topics"/>
    </xsl:call-template>
</xsl:variable>

<!-- Get interpretation for Posts -->
<xsl:variable name="i_posts-nodeset">
    <xsl:call-template name="sform:validation-interpret">
        <xsl:with-param name="section" select="$section_posts"/>
    </xsl:call-template>
</xsl:variable>

<xsl:variable name="i_topics" select="exsl:node-set($i_topics-nodeset)"/>
<xsl:variable name="i_posts" select="exsl:node-set($i_posts-nodeset)"/>

<!-- Merge them -->
<xsl:variable name="interpretation">
    <entry>
        <xsl:copy-of select="$i_topics/entry/*"/>
        <xsl:copy-of select="$i_posts/entry/*"/>
    </entry>
    <filters>
        <xsl:copy-of select="$i_topics/filters/*"/>
        <xsl:copy-of select="$i_posts/filters/*"/>
    </filters>
    <fields>
        <xsl:copy-of select="$i_topics/fields/*"/>
        <xsl:copy-of select="$i_posts/fields/*"/>
    </fields>
</xsl:variable>

<!-- Render as one report -->
<xsl:call-template name="sform:validation-render">
    <xsl:with-param name="interpretation" select="$interpretation"/>
</xsl:call-template>

Sections event updated to version 1.2 on 29th of January 2013

• Fixed selection of custom messages.

Sections event updated to version 1.2.1 on 29th of January 2013

• Field's interpretation now includes all orfan XML nodes from Entry data. This is useful to catch all custom errors thrown by various Events. (eg: Members: Generate recovery code)
• Readme fixes.

How would the utilities work for off-the-shelf events?

How would the utilities work for off-the-shelf events?

These utilities are not specific to Sections Event. They can be used with other events. There are hardly any limitations (scratched my head to find them). Each utility accepts the post-back value as a parameter to by-pass all the post-back logic if the event is out of the standard.

I'm successfully using them with the Members: * Events, accommodating the localisation for various error messages.

Would you do it like so:

<xsl:call-template name="sform:input">
    <xsl:with-param name="handle" select="'firstname'"/>
    <xsl:with-param name="event" select="'register-customers'"/>
    <xsl:with-param name="section" select="''"/>
    <xsl:with-param name="prefix" select="'fields'"/>
    <xsl:with-param name="attributes">
        <placeholder>First</placeholder>
    </xsl:with-param>
</xsl:call-template>

Why not have $section default to empty?

Okay, I'm starting to wrap my head around the logic with your approach. It is similar to Nick's approach yet it comes from the opposite direction (which had me thinking in circles yesterday). I'm also starting to remember a couple of the pitfalls using form-controls. The password field for the members extension is a perfect example.

One thing I'm not quite clear about is the impact of passing $interpretation via one of the field's parameters. Can you give an example of why you'd want to override the default behavior? Is it possible to apply an error message beneath its field, perhaps?

Should the following assign a type of password? It doesn't, but placeholder works...

<xsl:call-template name="sform:input">
    <xsl:with-param name="handle" select="'password'"/>
    <xsl:with-param name="event" select="'register-customers'"/>
    <xsl:with-param name="section" select="'password'"/>
    <xsl:with-param name="prefix" select="'fields'"/>
    <xsl:with-param name="attributes">
        <placeholder>Password</placeholder>
        <type>password</type>
    </xsl:with-param>
</xsl:call-template>

Comment #12

Would you do it like so: ... Why not have $section default to empty?

Because the primary use is with Sections Event so I'm setting the defaults to work with it. You're code snippet is correct if you want to use with a 'classic' event that Register customers is.

Comment #13

It is similar to Nick's approach

VERY similar.

I'm also starting to remember a couple of the pitfalls using form-controls

Stumbled on them myself. They're the reason SForm Controls exist.

One thing I'm not quite clear about is the impact of passing $interpretation via one of the field's parameters. Can you give an example of why you'd want to override the default behavior?

The validation for controls is done by looking at an $interpretation variable. Looking at sform:input you notice it can be overloaded as a parameter for the simple reason of performance. Each sform:control will compute it unless you pass it as a parameter. Example #6 shows this best practice.

Is it possible to apply an error message beneath its field, perhaps?

Yes. The template sform:validation-interpretaion has one job: interpret the results from the event and return them in a consistent way. This interpretation can then be passed to sform:validation-render and it will be displayed automatically or you can process the errors yourself and render them as you please, where you like.

Comment #14

Should the following assign a type of password? It doesn't, but placeholder works...

I just tested and it sets type to password:

<input type="password" placeholder="Password" id="fields_password_password" name="fields[password][password]">

Sorry man...

I just tested and it sets type to password:

I had added the XHTML namespace to make suggestions work in PhpStorm. Once I removed it, type did indeed change to password. Sorry for the false alarm.

it can be overloaded as a parameter for the simple reason of performance

That clears it up! Thanks.

Because the primary use is with Sections Event

That's what I figured, but my curiosity wanted to confirm.

Good stuff, thank you!

You're welcome.

How do you redirect to a new page on form submit with Sections Event? I am using the standard redirect code within the standard events but it isn't working :(

Does this work?

<input name="sections[__redirect]" value="http://www.google.com" type="hidden"/>

Indeed it does mr vlad.

Is there a cheatsheet or any documentation which covers all potential form elements when used with Sections_Event? It would be super handy.