Symphony.

Edit: I didn’t find any information on this prior to posting this - and I thought I looked. However I’ve found plenty of threads afterwards so feel free to let the post pass to oblivion unless you just have to post some feedback :-)

I admit that this is a lazy question, I could as well spend time testing it out, but I’m not quite certain it’s the best way to achieve what I want.

Given a regular program menu, how would you create a section to hold the data?

This is what I’ve done:

Textfield: Menu Name (required)

Textfield: Menu Translation (optional - Multilingual field failed under scrutiny)

Select Link Box to Texfield Menu Name: Parent Menu (optional)

Looking at the DB it doesn’t appear to be very wrong to self link like this. However top level menus do result in Null values in the DB - I’ve always been told to avoid this… hence my doubts about this solution.

The resulting XML looks like something that could easily be transformed to provide a basic list structure in HTML. But I’m not experienced enough with XSLT to see if there’s any apparent pitfalls.

<?xml version="1.0" encoding="utf-8" ?>
<data>
    <events />
    <indesign-hmenu>
        <section id="13" handle="hierarchic-menu">Hierarchic menu </section>
        <entry id="32" hierarchic-menu="0">
            <menu-en handle="print">Print</menu-en>
            <parent-menu>
                <item id="27" handle="file" section-handle="hierarchic-menu" section-name="Hierarchic menu ">File</item>
            </parent-menu>
        </entry>
       <entry id="29" hierarchic-menu="0">
            <menu-dk handle="dokument">Dokument</menu-dk>
            <menu-en handle="document">Document</menu-en>
            <parent-menu>
                <item id="28" handle="new" section-handle="hierarchic-menu" section-name="Hierarchic menu ">New</item>
            </parent-menu>
        </entry>
        <entry id="28" hierarchic-menu="2">
            <menu-dk handle="ny">Ny</menu-dk>
            <menu-en handle="new">New</menu-en>
            <parent-menu>
                <item id="27" handle="file" section-handle="hierarchic-menu" section-name="Hierarchic menu ">File</item>
            </parent-menu>
        </entry>
        <entry id="27" hierarchic-menu="3">
            <menu-dk handle="filer">Filer</menu-dk>
            <menu-en handle="file">File</menu-en>
        </entry>
    </indesign-hmenu>
</data>

Welcome to the forum Aalandriel :)

• Recursive Navigation
• Multilevel Navigation

You can take these XSLT utilities as example to create yours. For more information on XSLT, see: http://www.w3schools.com/xsl/xsl_w3celementref.asp

Cheers rainer.

I’ll definitely look into that.

Velkommen til Symphony-forumet :)

Just thought I’d add that there’s nothing wrong with NULL values in database columns, and not something one should avoid at all costs. With foreign keys (columns referring to another table row) which is not required NULL values is the correct solution. There’s no other logical value.

Also, what trouble did you have with the multilingual field? I’m using it myself for a lot of sections.

Thanks for the welcome :-)

Yeah my logic always told me that Null values where OK in certain cases, but one thing is what is logical an other things is what people tell you. I don’t claim to be a developer so I don’t always rely on my own logic when it comes to this - maybe I should more often ^^

The multilingual field is awesome if you want to switch language. But if you want to output both languages not so much. Think of a dictionary, you don’t want to look up the word and then browse to an other page to get the translation, you want the translation up front. I thought I could output the translation from the handle values but those are sanitized so that won’t work.

However I will still use the extension as the site will be multilingual, however for this particular feature the extension doesn’t make sense to use.

Databases are very logical things, so trusting your logic would probably be… logical. I guess you’ll just need to be careful with who you take advice from, not all web developers are database developers (they are quite different fields of knowledge) :)

And you’re right, the multilingual field is definitely not the solution for dictionaries. Good to know it wasn’t a bug with the multilingual field extension, just not the right tool for the job in this case.