Symphony.

I'm taking some first steps to making an extension, and have been looking at some others and think I understand some of the concepts. I'm a novice programmer and not familiar with OOP's ins and outs.

I've managed to add three text fields to the Symphony Preferences page. I think I've seen a couple of ways of using values that are set there, but don't understand them. What is the best/simplest way to grab these values in my extension.driver.php?

Thanks.

Take a look at the maintenance mode extension, it's probably the simplest example. The extension driver subscribes to the AddCustomPreferenceFieldsets delegate to add the checkbox — you've got that far. Name your fields like:

settings[your_extension_name][option_name]

That's all you need to do. When the System > Preferences page is saved these options will be saved to the manfiest/config.php file. The above would give you:

###### YOUR_EXTENSION_NAME ######
'your_extension_name' => array(
    'option_name' => 'the-option-value',
),
########

Some extensions also subscribe to the Save delegate of the preferences page to do additional processing of the values (e.g. JIT saves the whitelist URLs to a file on disk). But if you just want to save values, make sure your HTML form elements are namespaced under settings[...] and they'll be persisted to the config file.

To retrieve all keys for your extension:

Symphony::Configuration()->get('your_extension_name');

Or a single option:

Symphony::Configuration()->get('option_name', 'your_extension_name');

Great - thanks a lot Nick. The text fields are saving data to the config file and I can get to the values.

Is there somehwere I can read up on what can be done with appendChild(Widget::Input()) ? I need to have the saved values entered into the fields when the Preferences page is loaded, and I'd like to make one of the fields a password-type field.

Is there somehwere I can read up on what can be done with appendChild(Widget::Input())

Of course :-)

The API docs for the Widget class show you what methods are available. You'll see the third argument of the Input method is $type so you can pass password as a value and that'll do the trick. The Widget class is a more friendly wrapper on top of the XMLElement class, making it quicker to write HTML elements.

Even though I was looking through the API docs earlier I managed to miss Widget. Thanks.

Preferences in place. Just need to write the extension now. ;)

@DavidOliver: What is your ext about ?

My idea is to use the handsetdetection.com service via its API and to make XML available to pages so that served content can be controlled and made suitable for mobiles or other device types.

I realise that the Mobile Device Detection extension is similar, but I would like to be able to have the option of leaving the device identification based on the user agent string to an external service that is constantly kept up-to-date. I'd also like to be able to use it with PHP 5.2.

The XML returned would look something like this, depending on which options were requested:

<?xml version="1.0" encoding="UTF-8" ?>
<reply>
    <class>Mobile</class>
    <display>
        <resolution_width>240</resolution_width>
        <resolution_height>320</resolution_height>
        <columns>15</columns>
        <max_image_width>240</max_image_width>
        <max_image_height>280</max_image_height>
        <rows>6</rows>
    </display>
    <geoip>
        <country>France</country>
        <city>Arcueil</city>
        <countrycode>FR</countrycode>
        <region>A8</region>
        <latitude>48.8</latitude>
        <longitude>2.3333</longitude>
        <isp></isp>
        <company></company>
    </geoip>
    <product_info>
        <brand_name>Nokia</brand_name>
        <model_name>N95</model_name>
        <unique>1</unique>
        <ununiqueness_handler></ununiqueness_handler>
        <is_wireless_device>1</is_wireless_device>
        <device_claims_web_support>1</device_claims_web_support>
        <has_pointing_device>1</has_pointing_device>
        <has_qwerty_keyboard></has_qwerty_keyboard>
        <can_skip_aligned_link_row>1</can_skip_aligned_link_row>
        <uaprof>http://nds1.nds.nokia.com/uaprof/NN95-1r100.xml</uaprof>
        <uaprof2></uaprof2>
        <uaprof3></uaprof3>
        <nokia_series>60</nokia_series>
        <nokia_edition>3</nokia_edition>
        <device_os>Symbian OS</device_os>
        <mobile_browser>Nokia</mobile_browser>
        <mobile_browser_version></mobile_browser_version>
    </product_info>
</reply>

Then, in your template, you could do something like:

<xsl:choose>
    <xsl:when test="/reply/display/resolution_width">
        <!-- serve image via JIT at resolution_width -->
    </xsl:when>
    <xsl:otherwise>
        <!-- serve image at normal size -->
    </xsl:otherwise>
</xsl:choose>

(There would, of course, be different approaches to image sizing depending on preferences/project, perhaps basing it on the returned /reply/class instead.)

HandsetDetection is a paid service, but they offer a free account with 10,000 detections per month. I was thinking that before sending an API request I would first check for the common desktop browser user agent strings to avoid unnecessary detections. Detection results can also be cached/saved in sessions to avoid detecting the same browser over and over again on each page load.

I also thought I could build in redirection to a separate mobile site at some point, but my focus was on single-version sites with responsively-sized images/content and responsive CSS via media queries, etc.

However, I've given up for now. I first tried to use the PHP API kit and effectively wrap it in a Symphony extension, but I couldn't get this to work so I changed tack thinking I would build a more basic interaction by posting the user agent string myself as XML, but I realised this was beyond me.

At least I learned how to set up preferences fields. :-) These three fields are for the handsetdetection.com account email address, secret and site ID.

@DavidOliver: Learning is always good !