List of topics we can discuss.

[Danayel]

I am looking to hear from you all on a set of standards we can start
out with.

Given that all of us have different areas of expertise, it will be
helpful I feel to have several options so that we can choose to
contribute in areas that fit our expertise.

I think these could be a few useful topics to start with if there is
interest:

*********
** A common set of icons that we can use in the admin and front end.
*********

For Example:

- Generic icons for "category" "user" "options" etc.
- Smilies also for those that need them - comments, forums etc.
- Icons for templates to use in alert styles

This one will probably be ongoing, much like the tango project, as new
icons could be added almost indefinitely as needs change.

This may require a slight sacrifice in just how much personal
creativity we have for icon choice, but I feel it is a worthy
sacrifice in order to be able to have an icon set which everyone
recognizes, and knows immediately what a particular icon represents.

As a result I suggest we avoid icons that have a strong style or
particular color scheme to limit the impact of the icons on design.

*********
** HTML standards for extensions, and generic reusable classes that
Template clubs can style for and Extension developers can use.
*********

For Example:

- module h3s are currently styled by pretty much every template, but
it would be nice to have other semantic classes purposed for use in
extensions.
- a variety of "button" classes that can be used instead of styling
every button ourselves. e.g. we often use readon on links as most
templates style that class

*********
** Javascript library usage standards to stop multiple extensions
loading mootools, Jquery etc. multiple times on the same page.
*********

- a common library and plugin that all of us can ship with our
extensions to ensure that things are only loaded once.

*********
** class interface standards for extensions to allow for common reused
processes to be performed easily
*********

- e.g. a get user function to get user info from community extensions
- but all use the same properties for general things like avatar,
signature etc.
- a plugin system to allow components to load things like comments
forms without actually knowing anything about which comment form is
the default
- parameter elements that we can all share and reuse

*********
** PHP standards for extensions, with general rules of "bad behavior"
that can break other extensions and "good behavior" that helps other
extensions interact.
*********

Bad behavior examples:

- accessing things like the database or file functions directly
instead of going via the Joomla API
- system plugins loading their JS and CSS on every single page,
regardless of it is needed or not
- system plugins that skip the api for loading js and css and Force
their way into page loads, breaking ajax, tmpl=component, and
format=feed etc on other extensions

Good behavior :

- using the api whenever possible
- allow for libraries or css to be disabled in extension parameters

[Anthony Olsen]

This looks great Daniel and thanks for putting together the list.

Here is my quick two cents ....

Loading jQuery

** Javascript library usage standards to stop multiple extensions
loading mootools, Jquery etc. multiple times on the same page.

I think as I've mentioned I use our JB LIbrary plugin to load jQuery for our templates and extensions. We also bundle effects like lazy load, ie6 warning etc with it.

So I guess I would love a way to bring jQuery in to Joomla in a uniform way but I would be reluctant to make my users install another plugin to do this. 

eg install the jquery plugin plus all of the other effects

I have been thinking about including the extra effects inside the framework so this may be a moot point but its worth considering (for me at least)

This sort of thing really needs to be added to the core.

Common Styles across front end templates

- module h3s are currently styled by pretty much every template, but
it would be nice to have other semantic classes purposed for use in
extensions.

- a variety of "button" classes that can be used instead of styling
every button ourselves. e.g. we often use readon on links as most
templates style that class

This is a great idea. I think it probably exists to a degree anyway in terms of output from the core. So we probably just need to create a styleguide for extension devs to follow that the template makers can pick up on.

[Nicholas K. Dionysopoulos]

Hello all,

I'll coin in my two cents on creating a "plugin" ecosystem for Joomla!. This is actually what is required to achieve most of the items on that list, including loading of Javascript libraries, abstracting things such as comment form loading, implementing overridable/replaceable UI elements, centralized system for managing loading of CSS and JS files and even avoiding bad programming habits. Why plugins? Because plugins can be used as the building code blocks of our sites, are easy to manage and can be triggered on custom events. Alternatively, we could use a custom library but installing it automatically would be hard unless we focus on Joomla! 1.6+ only.

The main problem arising is different extensions requiring or distributing different versions of the plugins/library used. I currently have this issue with extensions based on Nooku. For instance, Lifestream requires and installs an old snapshot of Nooku 0.7, whereas Ninjaboard requires and installs an almost up-to-date trunk snapshot of Nooku. These two are incompatible with each other. I had to choose which one to use and which one to let go. I had to ditch Lifestream, which came with the cost of having to provide an alternative solution. Imagine what would happen if each template, component, module and plugin tried to install a different version of the abstraction API plugins/libraries we are discussing here. It'd be nothing sort of a Babel tower.

So, in order to be successful, we need to ensure the following prerequisites are met by our plugins/libraries:

• Future-proof. The exposed API should be immutable, or provide backwards compatibility whenever it's updated. We should do it like Microsoft did in the transition from Windows 3.1 to Win32s to Windows 95 to Windows XP to Windows Vista. By providing a backwards compatible API, applications written for Windows 3.1 were easily ported to Windows Vista with minimal changes (only about the parts which had to go away). Diametrically opposite to this approach is Joomla! 1.0 to 1.5 to 1.6. Each of those version changes completely screwed up our code and we had to make extensive changes. IMHO, only the 1.0 to 1.5 upgrade was justified for breaking the site. The 1.5 to 1.6 was a blunder. APIs changed for no reason and caused a lot of grief. Let's not do that.
• Dependency tracking. We need a method to track down dependencies. For instance, my extension should indicate that it depends on jQuery and jQuery UI. If they are not available they should be installed, transparently. This is similar to a Linux distribution's package management system. I have proposed a possible structure for such a component as a Nooku Incubator proposal.
• Warn and roll-back. Continuing from the previous point, if an extension installation is bound to cause an issue - e.g. it requires and supports only older versions of, say, jQuery than other parts of the system - the user should be warned that this may cause his site to break. While at it, it should also make sure that a backup of the changed files is kept and, if hell breaks loose, the user should be able to roll back to it. Think of this as the Windows' System Restore Points idea brought to the web. Considering that the site may be bricked, it would also be a good idea to provide an off-Joomla! way to restore those system restore points, much like booting with your Windows installation DVD allows you to run System Restore and roll back to a last known good state.

To sum it up, we have three problems to solve:

1. The Library. The core of what we are discussing.
2. The Installer. Because Joomla!'s own installer can't handle dependency tracking and roll-back.
3. Adoption. Just because we build it, it doesn't mean they will come. We will need big projects and clubs migrating to our solution and eventually having Joomla! itself adopt this solution. The former is difficult, but doable. The latter is less likely to happen than a snow storm in Sahara, pigs learning to fly or hell freezing over.

Feel free to comment on my rants :)

Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.con
Web: www.AkeebaBackup.com
Blog: www.Dionysopoulos.me

[TJ Baker]

Brilliant points all!

I really like the plugins points presented by Nicholas.  That, coupled with CSS 'best practices / guidelines' and I think we're well on our way to a 'Recommended Joomla Extensions Best Practices' that will benefit not only the end user, but all of our community of developers.

While I am not the best prepared to offer input for 'coding', re, plugin / library adoption etc I do feel strongly that we can get such guidelines adopted by most if not all of the 'big players' in the Joomlasphere, and I would be more than happy to help lead on that front.

I think the other smaller / hobbyist programmers / developers will follow along, especially when they see the benefits they will get by doing so (see our yet to be created 'why do this' info on our yet to be created site) and when they see all the 'big time' companies doing so ... 

Just my tuppence... 

tj

[Danayel]

Thanks for all the feedback guys.

It's all great material, but, I think Anthony and Nick's comments
should go into another thread about the topic of implementation. I
would like to keep this thread as a place to store topic ideas. i.e.
Suggesting that we raise the topic of how to implement is fine, but
lets try to keep the discussion of it in it's own thread so that we
can keep things clean and easy to follow.