Symphony.

This is a "how to" or "best practice" question: If I like to extend the features of an existing field, e. g. if I like to add an image browser to the standard textarea field, how could I add options and markup in an unobtrusive way?

I'm thinking of some kind of "add on" field extensions: these extensions do not create fields themselves but they add features that can be deactivated again later without touching the content of the original field.

Any ideas?

I think it should be done through JavaScript whenever possible. Also in 1.7 there were PreRender delegates which allowed You to modify rendered page before it is sent to client.

I used both ways in some internal modules: first i generated small additional markup where needed, and then made additional changes (like hook into keypress events of textarea) in JS.

Thanks for your input, akwayakchih. Do you know if there are also delegates for the field administration (Blueprints > Sections) in case it is necessary to add special settings?

I've been wondering the same, because I've been working on a few field extensions that are really more enhancements of existing fields than separate fields in themselves. Hopefully, the team can give us a brief overview of how best to do this...

I scanned Symphony 2 for "prerender" but found only 1 delegate, and it was for navigation/menu :(.

field.textarea calls "ModifyTextareaFieldPublishWidget" delegate, so You can modify it before it's rendered to client. But it's not for section edit page, just for entry edit page.

class.administrationpage.php calls "InitaliseAdminPageHead" and "AppendElementBelowView" delegates, and there are comments that You can access page through context. So i guess there is a way to modify XML before it is "flattened" to HTML (unless xmlelement->appendChild() flattens everything everytime it's called), but i didn't try it yet :(.

Try to look for every file inside symphony folder, where word "delegate" is used :).

As ahwayakchih says, javascript might work well if you just want to enhance an existing field. We've tried to support this with textarea fields especially by adding a @class for the chosen formatter so that, for example, you could use JS to add specific controls for Markdown-formatted textareas. Scripts are also fairly easy to package as an extension that just uses the addScriptToHead method of admin pages.

If you're significantly modifying the field's functionality, it's probably better to create it as a new field instead.

Thanks for your responses.

Think of the following scenario: I have a blog with a huge number of articles. After a while I like to add the ability to select and insert images from a specified folder directly into the textarea. If I need a separate (this means new or different) field for this, I will loose all the data of the old textarea. If I don't want to use the image browser anymore and like to deactivate it, I had to switch fields again (loosing all data again).

Thinking of javascript: it would be possible of course to create the image browser only by using JavaScript. But how should I set up fields and save information into the database on a per field base: different textareas in the same section probably need different settings. What about browsers with deactivated javascript?

In my opinion field extensions should do what's in their name: extend fields not just adding fields. (Of course both should be possible.)

Indeed it would be easier to have some delegate to add form fields to section field edit area.

But You can still add options to field edit area by using JS/AJAX to send value of option to extension :).

Speaking of JS... Scott, any guidelines in that dept? I'm imagining a scenario in which a handful of extensions could be calling all sorts of different frameworks and plugins, etc. Maybe there's no avoiding this, really, but curious to know what you think.

To avoid conflicts with, say, multiple extensions all including copies of jQuery, I reckon the standard we should set is to use Google's hosted JS libraries for those kinds of things. That way, we can update the addScriptToHead method to just ignore calls where the URL argument is the same as a previously added script.

To avoid conflicts with, say, multiple extensions all including copies of jQuery, I reckon the standard we should set is to use Google's hosted JS libraries for those kinds of things.

Now that Symphony is OpenSource, why don't you bundle one library with the system and use it for the whole admin interface? JQuery, Mootools or whatever seems to be the best for the purpose ...

Thanks, Scott. That makes sense.

Scott, I'm assuming the idea is to include the library using its direct path (e.g. http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js), rather than (Google's recommended method) the google.load() function, since including http://www.google.com/jsapi requires a domain-specific API key and so couldn't be hard-coded into the extension?

Correct - linking directly to the minified version of these files is standard practice, I believe.

I'm not sure what the benefit of using Google's API is, aside from being able to choose libraries dynamically, which I can't see a use for.

To avoid conflicts with, say, multiple extensions all including copies of jQuery, I reckon the standard we should set is to use Google's hosted JS libraries for those kinds of things.

I have been thinking about JavaScript and extensions for a while now and I found a few problems:

1. The function addScriptToHead() does not check if a file has already been added to the head. So if an user adds multiple instances of a field the same script files will be added over and over to the head which will result in conflicts and a large number of file requests.
2. If we are integrating Google's hosted libraries, extensions relying on JavaScript will stop working when the user is not connected to the internet (local installs).
3. If we are not relying of a hosted solution, how should the system decide if a framework has already been loaded? /extensions/selectbox/assets/mootools.js may or may not be the same as /extensions/imagefield/lib/mootools-core1.2.1.js.
4. What about custom tailored builds of frameworks that only integrate the needed submodules? It seems to be necessary to always integrate the full framework.

I have to say that I don't like the the hosted library solution as it doesn't really solve problems but does create a new one (see #2).

As stated a while ago I think it would be a good idea to settle with one framework which seems to be the best for Symphony. This way we could solve a lot of the mentioned problems and extensions would use the same methods.

If each extension could decide which framework it is relying on, it should at least be possible to coordinate the script calls. Would it be possible in some way to let extension register for a framework? So if an extension sets a flag for jQuery it will automatically be added to the head. If more than one extension is calling the same framework, only one will be added to the head. This could solve a few problems, but still we will have to deal with a lot of framework and script calls if a user uses a lot of different fields.

Just had a thought about this: a simple solution might be to put JavaScript libraries into separate extensions. If you want to use an extension that requires jQuery you'd also have to install the jQuery 1.2.6 extension.

I haven't had any experience getting multiple frameworks to work together, but if it was a requirement to write your JS in compatibility mode then it should work.

What do you reckon?