Symphony.

I would like to know everyone's thoughts on developing backend (extensions) vs. frontend ('bauhousian') tools for extending admin capabilities.

I see the ability to create frontend admin interfaces as a very promising future for Symphony(for my projects anyway). Creating reusable tools to facilitate these interfaces is a goal of mine, but it seems to conflict with the extensions system built into Symphony itself. I'm not sure which would be better to invest in.

Case in point: I am trying to decide the best method for implementing an images section. If this would be a backend setup, that would mean an extension to allow for previewing images I'm adding to the section, as well as integrating that section (and whatever browsing functionality) into a formatter, or otherwise making it accessible to other entry editing pages.

Alternatively, the whole thing could be done in the front end, which would involve creating Pages for image adding, browsing, and editing the destination content fields in which I want to reference the image entries.

I don't have a total understanding of the scope of extensions, so maybe I'm making an issue out of nothing. I'm just wondering if developing a method for sharing frontend components that may functionally overlap extensions is good, bad, what do you think?

I like the idea of keeping it all contained in the back-end. Extensions are certainly capable.

I agree with Lewis. Although Bauhouse's work is wonderful and impressive, most Symphony users will certainly stick to the backend admin. (Even understanding what Bauhouse does there is hard - we do not dare to think about doing this ourselves...) Plus: Why re-create all the stuff on the frontend which is already there, in the backend?

As time passes by, we wil certainly have great extensions to satisfy the needs of most users.

(Just in case you really go for your own "application", Bauhouse's work is the right place to learn!)

Thanks, micheal-e. If I knew enough about PHP and MySQL, I would be creating extensions. That's my long-term goal, if I find some time to learn. But I'm trying to use what I already know to build on concepts that will hopefully filter into back-end development either by the Symphony team or by others as extensions. It seems the easiest way to add functionality to Symphony or remove it. I consider my front-end admin work to be hacks that would probably be much more efficient as extensions, both to build and to implement.

Hopefully this piece of news will help make answer some questions (if not, it'll at least clarify some things): the next revision of Symphony will take advantage of DOMDocument as discussed by Alistair. DOMDocument will be used for both XML creation for data sources but it will also be used for the back-end admin. In another words, Symphony's back-end admin will be powered by XML and XSLT. This have several benefits:

1. Developers will be able to customise the admin interface using XSLT.
2. Extension developers will produce XML instead of HTML for their extension interface.
3. An emergent benefit of #2 is that when we make an update to Symphony's CSS and HTML, extensions' interface will no longer break compatibility.
4. It allows a more rapid development cycle for us. Currently, interface code is heavily embedded into each php file so when we make a big change to the admin interface, a bunch of files need to be updated. To change the interface with the new way, it'll be a matter of changing one XSLT file.

Regarding point #4, this quote is from Coding Horror on MVC:

... probably gotten your model's chocolate in your view's peanut butter ...

The separation of XHTML markup from the PHP gets Symphony much closer to a MVC pattern implementation.

This is very good news!

Symphony's back-end admin will be powered by XML and XSLT

So I expect that means the admin interface ensembles I've developed should port easily as extensions. But does that mean another rewrite for the existing extensions developed for Symphony 2 so far? I was going to dive into learning what I could to build extensions, but it sounds like the API is in flux.

hmm, not a whole lot will change. Currently Extensions produce XHTML markup directly. The main difference will be that instead they produce XML, in a similar way to Data Sources, which is combined with an XSLT document for that specific page. The API will more-or-less be the same.

Yes, unfortunately the state of the extension API is like putty. Or as Britney Spears would say, "Not a girl, not yet a woman".

Forgive me... could someone point me to the API documentation? I'm having trouble finding it.

If I knew enough about PHP and MySQL, I would be creating extensions.

i feel like a lot of symphonians are in the same boat, bauhouse, me included.

@wtdtan, it does give me a good reason to learn, though.

@bzerangue, as far as I know, there is no documentation for the extensions API, other than what Alistair has just provided: http://symphony21.com/forum/discussions/254/1/

thanks stephen! i'm guessing the final documentation for the API will be available when s2 final has arrived. thanks for your help!

i'm guessing the final documentation for the API will be available when s2 final has arrived.

Yes.

Yes, unfortunately the state of the extension API is like putty.

Given the state of flux, the lack of documentation is for good reason. So, like Britney Spears, the Extensions API is going through some issues while the public stalks every appearance to discover the final outcome.

Extensions seem to be the unanimous response, so naturally I'll play devil's advocate (this all sounds good and makes sense, but I still have a one or two items in the 'pro' column for frontend).

What about user management? If we use the backend admin for end-users, this would mean all users would have to be Symphony users, which would mean having extended management for Symphony users. We'll need something with full access to the User data model (or at least the ability to extend it arbitrarily).

The flexibility of interface was my biggest concern, but it sounds like in the near future back-end pages are going to be closer to front-end pages, just with access to extensions. Is this correct?

What about bona-fide web applications written in Symphony, like Bauhouse's project management? It's not meant for site administration, but is just as sophisticated. Should any application with extensive data input functionality be done as admin pages/extensions?

I agree with Bauhouse that the portability of extensions (and especially their data models), makes them much more efficient than an ensemble or just a collection of XSL.

The biggest problem I see with with keeping all management on the back-end is that Symphony Admin only works in Safari or Firefox. (Which I love and think was a wise decision... I LOVE SAFARI!). But having end-users modify data through the Admin interface is the equivalent of asking over 60% of internet users to switch browsers just to upload an image/file or edit their membership details (or whatever) on my site.

I'd love to see a good implementation of a membership extension that gives end users a front-end admin (plus login, etc) to edit their member details, etc. I plan on looking into that one S2 is released.

I will be implementing another site into S1.7 tomorrow for a client... can't wait! It was so much fun the first time. :)

I'd love to see a good implementation of a membership extension that gives end users a front-end admin (plus login, etc) to edit their member details, etc. I plan on looking into that one S2 is released.

We've been commissioned by Airlock to create a membership extension a few weeks ago. Whilst it's complete, we won't be able to release it until Symphony RC1 (formerly rev6) since it requires some features not found in rev5.

The biggest problem I see with with keeping all management on the back-end is that Symphony Admin only works in Safari or Firefox.

It's always been our intention to support IE in Symphony 2 but it only makes sense for us to work on the compatibility aspect at the end of the beta period. We plan to support IE by Symphony RC1.