Symphony.

Personally, as a novice extension maker, I’d love for there to be a “best practice” and a guide to how best to do extensions in Symphony. One of the reasons I haven’t really tried making my own extensions a lot is because I’m rather new at PHP anyway so having to learn Symphony’s architecture, PHP and figuring out where it all should go is rather confusing.

Because of the way most extensions are stored on GitHub, we always have to manually rename the folder when downloaded. I can’t count the times I’ve seen someone reporting on this forum that they can’t activate an extension, and the answer being to rename the folder. It’s a bad way of coding doing it this way.

Agreed. This could also be solved by using a installer for extensions. (choose the zip file and everything gets taken care of, for the starting user?) It’s the installing part that gives problems, not the naming scheme (in my eyes).

Nice to hear a lot of different views on this!

Speaking of extension best practices, does anyone have any thoughts on addressing name collisions, anything that might need to be in the core? I know its not really an issue yet, but hopefully someday soon it will be. If it could mesh with the eventual use of native PHP namespaces, all the better.

I’m not a really big fan of namespaces (yet ;)).

In my experience, they usually do more harm than good (let alone if they are misused). I do feel we should have a stricter seperation of core classes and custom classes. (something like the zend framework, but less extreme?)

How would you use the namespaces in symohony’s case?

does anyone have any thoughts on addressing name collisions, anything that might need to be in the core?

Options:

1. Simply have a table available with all current and active extension class names in the API docs. This could be updated whenever a new extension is submitted.
2. Craig and Allen proposed community working groups at Symposium for each aspect of Symphony’s architecture, therefore there would be an extensions working group where a developer could have his/her extension submitted for approval (like Apple App Store) where name conflicts and best practices could be proposed.

I believe the second option is more ‘Symphony’, and after all, the community is here to help each other.

Namespaces (which I know nothing about) seems a little complicated and not for a noob like me.

therefore there would be an extensions working group where a developer could have his/her extension submitted for approval (like Apple App Store)

No, that’s not really the idea. Symphony is an open platform; Apple is quite the opposite. I would fight against any move in that direction. If there were an Extensions API working group, its focus would be about standardizing and enhancing the API throughout the core (delegates available, etc). But I’m not fully convinced there needs to be one.

I think all we’re talking about here is establishing guidelines. They are not yet established, but conversations like these will help us move forward in that regard.

Community-supported guidelines and best-practices are the way to go, in my opinion. Apple’s system is an answer to a problem that Symphony doesn’t have.

Though—and this may be a discussion for a new topic—the ability to rate extensions would not go amis as I often have no idea which extensions are best, even when they all do the same thing.

Ok, naive idea there, but definately a set of guidelines and docs, understandable that the core team is busy though ;)

What about a wiki then? At least to start with?

There definitely needs to be something like API docs to explain the delegates, as I really want to start developing extensions now my PHP knowledge is getting better, yet I have no idea where to start.

I definitely will have to start developing extensions with a large corporate project I have on…

This is a bit on the trivial side, but I noticed that a delegate in class.devkit.php is called DevKiAppendtMenuItem. “Append” is in the middle of “Kit”. It’s not a bug because it’s used that way everywhere.

No, that’s not really the idea. Symphony is an open platform; Apple is quite the opposite. I would fight against any move in that direction.

Thanks for this statement, Craig! I think it is really important to never control which extensions are being made available for Symphony.

One thing that would be nice is an official “batch” for extension the team thinks are recommended for use or that are highlights in the list of extensions (something like “staff picks”). But this can be easily done in the features area of the current website: http://getsymphony.com/download/extensions/featured/

If there were an Extensions API working group, its focus would be about standardizing and enhancing the API throughout the core (delegates available, etc). But I’m not fully convinced there needs to be one.

As I said at the Symposium, I’m not sure if we need all the working groups you mentioned in London. The most important step is estabilishing guidelines and best practices. Thinking as an extension developer there are only a few really important questions:

• How do I build an extension (naming conventions, folder names)?
• Which delegates or functions should be used (adding assets, calling the configuration etc.)?
• Which delegates are available?
• How should I organize my code (spaces, breaks, general layout)?
• How should I document my code and extension?
• How should I take care of localisation?
• What are Symphony’s UI guidelines?

As Symphony 3 really pushes the use of extensions forward all these questions apply to the core, too. So I think the working groups will have to find answers to these questions for the core and will thereby establish the guidelines for the extension developers on the fly. So I see four main groups:

• Coding guidelines (for PHP and JavaScript)
• JavaScript library*
• User Interface guidelines
• Documentation

* I don’t see a need for a PHP/core working group in this context as this seems to be the main working area of the Symphony team. We need a documented API but I think we don’t need a task force for the API itself: most of the needed changes or adjustments will be pointed out by the other working groups while they are establishing their guidelines. If the current API is consistent and logically built, will get obvious while creating its documentation.

Thanks Nils. Yeah that’s fairly close to what I’m thinking now too. I want to keep this all as simple as possible.

I aim to have a proposal put together early this week.

I get an Internal Server Error on Joyent shared with the following in error log:

[Mon Jun 21 17:02:53 2010] [error] [client 24.128.41.227] malformed header from script. Bad header=Content-Type: index.php
[Mon Jun 21 17:02:53 2010] [debug] mod_headers.c(768): headers: ap_headers_error_filter()
[Mon Jun 21 17:02:53 2010] [debug] mod_deflate.c(602): [client 24.128.41.227] Zlib: Compressed 538 to 324 : URL /install/index.php

Yeah, we’ve had that one before. A possible fix is currently being discussed.

Mark, I had to work around this by installing locally, then copying and modifying the config file and the local database to the Joyent Shared Accelerator. It does work on Joyent once you get past the install.

These changes to symphony/lib/class.htmldocument.php should fix it (don’t mind the one to symphony/lib/class.documentheaders.php, I was just messing around not knowing what I was doing).

@Doug: It contained too many deep structural changes to be just a point release. So what one was 2.1 has evolved into 3.0. A blog post will follow soon.

ha, sounds like 1.7 going to 1.8 then going straight to 2.0! haven’t opened up 3.0, but from the responses, i’m sure this release will be amazing as well!

Thanks, phoque. I can confirm that your change to class.htmldocument.php fixed the issue with Joyent. (I just noticed they’re calling them Joyent SmartMachines now, Lewis).

@wtdtan: You’re in NYC right? I’d be happy to do an in-person demo of 3.0 for you (and anyone else in the area). Would be a nice opportunity to meet fellow Symphonyheads.

Since we have changed “Pages” to “Views”, does it make sense to change the parameters $root-page and $current-page to $root-view and $current-view, respectively? Or are we keeping these parameter names the same for the sake of backward compatibility? I could see some confusion going forward if we are going to use “view” and “page” interchangeably.

I’ve created a Symphony 3.0 ensemble that will be an experiment in bleeding edge web standards called Symbiosis. Here’s my take on the HTML5 template.

I’ve figured out how to get indenting to work for XSLT and HTML5.

(Note: create the workspace/events directory manually for now, since Git doesn’t save the empty directory. Trying to navigate to events will result in an error until this directory has been created.)