Symphony.

I too am interested. A few of my extensions use tabs, so I’m tempted to make a tab UI plugin to unify their markup, styling and behaviour across extensions.

Nils, I don’t think there are any guidelines from the team at present. I’d start by asking Rowan for direction, since it looks like we can follow his lead on the “interface” repository.

Developing a full Symphony.UI suite of plugins is going to take time, and close collaboration.

A few of my extensions use tabs, so I’m tempted to make a tab UI plugin to unify their markup, styling and behaviour across extensions.

It would be great to create plugins little by little that can be adapted by other extension developers. I like to unify the concepts of the Mediathek and Date and Time fields and I’m thinking about a multiple upload field that would benefit of this as well. My starting point are the visual layout of the Date and Time field and the behaviour of Mediathek. I’d be happy to get some feedback during the development concerning either design or coding standards.

Developing a full Symphony.UI suite of plugins is going to take time, and close collaboration.

Yes, of course. I think there are some interesting UI concept besides those present in the core. Some of them are good and simple (like the tabs), others are a bit (too) complex and need polishment (like the entire Mediathek setup).

There are two things I really like to have or achieve:

1. Coding conventions so that it’s easier to understand code of different developers.
2. Visual consistency or at least compatibility troughout the system.

While it would be good to have some guidelines by the core team for the first point, the second can only be achieved by reviewing the different concepts and talking about the different approaches.

I’ve been hoping to put together an article on “Symphony Coding Conventions,” but since I’m still fairly new to programming myself, it’s taking me a while just to understand what the right kinds of questions are… This conversation you’ve sparked is certainly helpful.

For coding conventions, do you think following the Zend standards is a good start?

For coding conventions, do you think following the Zend standards is a good start?

That would be great! Also inline documentation which follows the “phpDocumentor“ format. Very useful for automatic API-Doc creation and for a quick help in IDEs like PDT, Netbeans etc.

A build script with PHP_CodeSniffer can check the conventions.

I’ve been hoping to put together an article on “Symphony Coding Conventions,” but since I’m still fairly new to programming myself, it’s taking me a while just to understand what the right kinds of questions are… This conversation you’ve sparked is certainly helpful.

I was thinking of something similar to the jQuery UI API Developer Guide or the Syntax and Coding Style Conventions for Mootools.

@Nils; Do you think symhpony itself should be adapted to follow a coding standard, or should symphony (and all its extensions) follow a custom built symphony standard?

Ofcourse, changing symphony to match a pattern is really a waste of time (no bugs are fixed, nothing is changed but the appearance of the files). But on the other hand, for new developers it will make a lot more sense to see symphony follow the path that other frameworks (with big names) have thought out..

For instance: I really dislike the filenames where the classname gets prefixed by a class. prefix. If I wanted to quickly find a file in the windows finder, I can’t just press ‘D’ and be taken to the first class that starts with a D, as all filenames start with class…

@Nils; Do you think symhpony itself should be adapted to follow a coding standard, or should symphony (and all its extensions) follow a custom built symphony standard?

Either way, it’s up to the Symphony team to decide which way to take. If we want to collaborate and like to contribute to this open source project we need defined standards to keep things consistent and understandable. Symphony has been closed source for a long time. This has changed with version 2.0 but it has not resulted in coding guidelines for the community yet.

For instance: I really dislike the filenames where the classname gets prefixed by a class. prefix. If I wanted to quickly find a file in the windows finder, I can’t just press ‘D’ and be taken to the first class that starts with a D, as all filenames start with class…

I disagree. Prefixes does make sense for me and It’s a Symphony standard. There are prefixes like event, data, lang and content. Cut these prefixes out isn’t a good idea.

I disagree. Prefixes does make sense for me and It’s a Symphony standard. There are prefixes like event, data, lang and content. Cut these prefixes out isn’t a good idea.

What I was trying to say is that I don’t like the position of the prefix. I would have made it something like: classname.class.php, classname.data.php etc. Maybe even do the Zend way; putting it in a event folder if it’s an event, putting it in a data folder if it’s a datasource etc.

Either way, it’s up to the Symphony team to decide which way to take. If we want to collaborate and like to contribute to this open source project we need defined standards to keep things consistent and understandable.

Agreed. Although I’m not saying I don’t enjoy coding for symphony right now without the guidelines!

We’re talking specifically about JavaScipt here. While Rowan’s comments may not be to everyone’s taste, I think the style of commenting at this stage is incidental. A style will emerge. What’s more important is consistency in the object structure. Thankfully Rowan has adopted a jQuery plugin approach which is well understood and promotes a sensible object structure.

So long as we follow his lead, I think things will be consistent and collaboration will be possible.

Oh sorry, I thought the symphony coding conventions were about the entire platform (php and javascript alike)

So long as we follow his lead, I think things will be consistent and collaboration will be possible.

Well, of course, it will work somehow. But with Symphony growing I think it is definitely time for the team to publish some guidelines now. Uncontrolled growth might be good for some things but I’d prefer “parental guidance” in this context ;)

I thought the symphony coding conventions were about the entire platform

They will be, but I think not all of it is relevant to this conversation.

I’ve seen a lot of work on GitHub lately that seems to move Symphony towards version 2.1. Craig announced a few fundamental changes in one of the last blog post so I think it’s time two ask a few questions:

Coding guidelines and documentation

A while ago we have been talking about coding standards and about documenting code (using PHPDocumentor). So 2.1 will be the next step: will it follow a consistent standard for both the code and its documentation?

JavaScript

I have spent some time with admin.js while implementing the new localisation features. This file is a mess. The Symphony object isn’t consistent in what it does and how it does things. The whole JavaScript file is a mixture of “core library” and “apply things to the backend”. Wouldn’t it be a good idea to rework it while preparing Symphony 2.1?

As far as I can see all the basic Symphony functionalities (duplicate, collapse, etc.) will be separated into separate file containing jQuery plugins. This is a great start. What about separating the core Symphony behaviour from the Symphony object as well. This might be a good moment to rethink the Symphony object, reorganising it and adding some context information to it. It could be bundled in a file called symphony.js while admin.js would only contain the parts of the JavaScript needed to apply things to the backend. I think this would really simplify and streamline the system.

So 2.1 will be the next step: will it follow a consistent standard for both the code and its documentation?

Yes, this is underway now. I’m not 100% sure the core will be totally cleaned up and documented by 2.1 final, but we’ll certainly have started. A coding style guide is in the works as well…

Wouldn’t it be a good idea to rework [admin.js] while preparing Symphony 2.1?

That sounds like a good idea to me. Will discuss with the team and report back.