Symphony.

Right now I am experimenting with the Stage library written by Nils. This is an excellent starting point for a lot of my extensions, but there is one (big) problem: since the library is bundled with each extension, I always tend to get a Fatal error: Cannot redeclare class Stage error.

Ofcourse, this could be partially fixed by checking if the class exists before including the library. But, it feels a lot cleaner to have all library files in one place (so include_once and require_once do all the heavy lifting).

Do you think there should be a seperate place for external libraries to be stored within symphony? A lib dir in the root folder, perhaps?

And, something related, but quite different, do we have naming conventions for classnames? For instance, for the email template manager extension I created a class called (surprise!) EmailTemplate. However, when installing it next to the master branch of the members extension, I noticed the members extension also has an EmailTemplate class, resulting in a conflict and a fatal error.

How should we prevent this? Should all classes bundled by an extension use a namespace (only available in php > 5.3.0) or should the classname be prefixed (etmEmailTemplate and mbrsEmailTemplate?)

Nils also brought this up in Throw an exception if submodule is missing.

Do you think there should be a seperate place for external libraries to be stored within symphony? A lib dir in the root folder, perhaps?

I don't think that would be the right approach, because how would extensions add files to this folder while remaining sandboxed in the /extensions folder? Personally I think the easiest and most common approach is to use a try/catch to see if a class exists or a file dependency exists.

An alternative might be for Symphony to load files in lib folders of extensions first? Not sure if that would have any dodgy side effects.

should the classname be prefixed

This would be the easiest approach. We've started to adopt the convention that assets bundled with extensions are named after the extension and the area in which they are used (e.g. myextension.backend_area.js. There's no convention or suggestion yet about JavaScript object naming, but since they are usually named after the extensions this hasn't been a problem. So if your extension bundles its own classes, I think it would be responsible to name these appropriately.

etmEmailTemplate and mbrsEmailTemplate

I think we should be verbose — we are everywhere else. Abbreviations don't feature at all in Symphony conventions. So EmailTemplateFilter_EmailTemplate and Members_EmailTemplate would make sense to me.

If you're following Symphony naming conventions then it would really be:

Extension_{ExtensionName}_{ClassName}

for example:

Extension_Entry_Versions_VersionManager

Namespaces would be a neat way of handling this moving forward, but given that Symphony's minimum requirements are still 5.2 and probably will be for some time, any extension requiring 5.3 should have obvious warning messages.

Nils also brought this up in Throw an exception if submodule is missing.

Oops, I missed that one..

I don't think that would be the right approach, because how would extensions add files to this folder while remaining sandboxed in the /extensions folder?

You're right, maybe a seperate lib folder outside of the extensions dir isn't the best way. But what about a lib directory inside the extensions directory? If that folder is writeable by extensions, it could be inside the installation process. That might solve some problems, but it will also give a few other problems (uninstalling -> delete file?).

So, yes, checking if the class exists before including the file is the easiest way at this point. (If a proper LibraryFileManager is ever written this might change :) )

If you're following Symphony naming conventions then it would really be:

Extension_{ExtensionName}_{ClassName}

for example:

Extension_Entry_Versions_VersionManager

Ah, yes, agreed (on this and namespaces). I will update my extensions accordingly to prevent any issues.

Thanks for the swift reply (as always ;))

You're welcome! Might be worth seeing what the more hardcore PHP nerds say, as I've never used PHP namespaces before.

This is quite similar to the JavaScript Libraries discussion where we pondered having an asset loader, so that extensions could request (JavaScript) libraries to be added to the page to avoid duplicate libraries being loaded. It never came to anything as we settled on jQuery in the backend, and we tend to avoid bundling big libraries (which we can;t change the names of) with extensions.

That is not to say that it won't be a problem in the future.

Might be worth seeing what the more hardcore PHP nerds say, as I've never used PHP namespaces before.

Well, they are designed to solve exactly this problem. I found that the concepts are quite easy to understand if you are familiar with namespaces in XML, but the proper way of coding using namespaces is tricky (when to use a new namespace, what namespaces to create, not overdoing the nesting, etc). Reading them is a lot easier than designing/creating them correctly..

That said, I think we should wait with namespaces until symphony is only supported on 5.3 (which will be a long time, since many hosts still only support 5.2) if we are ever going to use them, at all. In my experience, not many people know how to handle them, so they might only raise the barrier for new extension developers that aren't php wizards.

Simply renaming your classes is a lot more developer-friendly if you're not that much into php.

You're right, maybe a seperate lib folder outside of the extensions dir isn't the best way. But what about a lib directory inside the extensions directory? If that folder is writeable by extensions, it could be inside the installation process. That might solve some problems, but it will also give a few other problems (uninstalling -> delete file?).

What about renaming the extension folder as "library.extension-name"? That would be simple and, at the same time, a bit Symphony-ish. Just thinking aloud :)