Symphony.

I'm sure some of you have already gotten across this; I did before however wasn't happy with the solution I implemented so checking what's actually a best practice...

I've got a website dealing with some tourist attractions; and the client would like to denote the opening & closing times of each of these tourist attractions.

In their current CMS this is a chunk of text; which I would like to separate to make it a little-bit semantic.

I was initially thinking something like a Selectbox to choose the days; and two time fields; to denote opening/close times. However some of them also have different summer & Winter times; and varying opening hours for different days...

In my previous work I've opted for a SSM field; with the different days/times [however I only had no summer times]. Would this still be the good approach? or is there another way to show this.

Finally there's also a possibility that some things are only available in certain months (summer only) except summer is also defined as a different period.

I'm not sure if there's something which could do the trick or else I would have to define some custom field; or at least custom UI to give a good user-experience...

So you have date ranges (season) with sub time ranges (opening times)? Does sound like a job for nested subsections/SBLs. I'm not sure how you would UX that well with existing Symphony tools. The functionality is there but you might have to customise the UI side of it. Interesting use case.

Definitely a job for HTML Panel Field. Create the necessary sections, link them with SBL/SBL+ and generate the UI in a Page.

1. Section Seasons. eg: summer, winter
2. Section Days. eg: monday, tuesday ...
3. Section Opening hours: SBL Seasons, SBL Days, Date/Time Start, Date/Time End, Checkbox Closed.
4. Section Locations: HTML Panel -> Opening hours

Make a tabbed form:

Summer | Winter

        Start  End    Closed
Monday  input  input  checkbox
Tuesday input  input  checkbox
...
Sunday  input  input  checkbox

Much work. Totally worth it ;)

Another option may be the Meta Keys field?

One key is the season (Summer), then it's just a comma separated list of times (Mon 9-5, Tues 9-5). In the XSLT you can break these times up using tokenize method.

This won't work if you want to do some actually filtering based on the current date though :)

@vlad looks interesting never quite used the HTML Panel Field before but it totally makes sense. It does abstract quite a lot of stuff to the end user. It would also give me the flexibility I need; as some places do define Summer/Winter in a different way so I could have them 'add' seasons with different ranges.

I'll give it a shot this evening :)

@brendo Meta Keys would work if I was taking care of everything myself.. but I want the client or one of their staff to handle updates & changes. The less complex for the client the better.

@vladG just a quick question... as trying to implement it now... I would assume If I'm using the HTML panel to replace standard behaviour to save stuff from other sections I would need to add some save event in the HTML panel; or I can actually link this?

What I was thinking was to create an entry in what you defined Opening Hours Section for each & every opening-hour set created in the HTML panel however not sure that's entirely possible without adding some AJAX stuff (I don't really want to over-complicate things and do extra stuff I don't need)

Yep, totally forgot about that part. You'll have to do it with AJAX.

If you're still doing this, here's how I'm displaying an HTML Panel page. In the HTML Panel page I'm putting an iframe and in that iframe sits the form (generated by that same page). Form submission for HTML Panel is done through AJAX.

<!-- Import master stylesheet. I have a separate one for this kind of pages -->
<xsl:import href="......../master.xsl"/>


<!-- Match the root node to override rendering -->
<xsl:template match="/">
    <xsl:choose>

        <!-- Set iframe path -->
        <xsl:when test="not($params/url-src) or $params/url-src != 'yes-it-comes-from-me-bla-bla-bla'">
            <!-- Add a switch to iframe URL to display the content, not the iframe, again -->
            <iframe src="{$params/current-url}?src=yes-it-comes-from-me-bla-bla-bla"/>
        </xsl:when>

        <!-- Display page as usual -->
        <xsl:otherwise>
            <xsl:apply-imports/>
        </xsl:otherwise>

    </xsl:choose>
</xsl:template>


<!-- Normal page data goes here, as usual -->
<xsl:template match="data">
    ...
</xsl:template>

Hmmm ok no problem. I've already got some form submissions in AJAX on front-end so shouldn't be a big deal to set-up. Was just wondering as it seemed like a missing piece.

Just a question on the iFrame; is there any particular reason to use this? except possibly re-loading it to show updates... I was thinking of hijacking the symphony submit form; do the ajax first then continue saving the rest of the entry.

It's quite a neat solution did the UI for what I needed and it was like an Eureka moment with this HTML panel field... already used it in another two cases.

Well, I'm not fond on hijacking the backend form. I'd have to create an extension to add necessary styles only for those entries in that section.

In my setup I have a small mini-site with widgets et all (XSLT, CSS, JS etc), similar to desktop version, which helps with building this kind of functionality.

In the end, it might be just a matter of preference.

yes I guess; form hijacking is not very neat true; however with the way the panel field works you don't even need an extra extension; however looking at it I think it could solve some problems in a 'prettier' way then SSM. Though it might involve a little bit more work. Back to coding :)

Implemented its quite neat as a solution :); have some minor UI things to fix to show some responsiveness...

The only caveat with this system is that new entries cannot be linked that way really... You'd have to enable it after the first save, otherwise its an interesting way to build relationships when you need a somewhat complex UI

The only caveat with this system is that new entries cannot be linked that way really... You'd have to enable it after the first save.

Yeah, indeed.