I find the terms "frontend" and "backend" confusing when applied in this context.
also, links to the standard parameter types would be extremely useful. http://docs.joomla.org/Standard_parameter_types
Overall, I found the article extremely useful.
Commercemeister, thanks for your comments. Could you please explain what you find confusing about frontend and backend? They are commonly used to refer to the main site and the administration parts of a Joomla! website, respectively. It would be helpful to know how you think they should be clarified (or you could even just do it yourself - that's the beauty of a wiki!). Thanks too for the note about parameter types - the article did originally link to a page with this information, but then that page was changed. I will update it.
One final point - please sign your comments using the four tildes at the end (~~~~). Thanks, Mike 16:18, 3 September 2008 (EDT)
I'm confused about the differences between the types of parameters. So you've got Parameters (Basic), (Advanced), (Component) and (System).
Now what kind of parameters would you put in (basic) and what in (component) if both can be overriden in the menu you create for the component ? I just don't see the distinction between the two... Alfred 14:12, 25 September 2008 (EDT)
Alfred, 'Basic' and 'Advanced' parameters are just 'article-specific' parameters - the only difference between 'basic' and 'advanced' is in how they are displayed in the back end. 'Article-specific' parameters are those that are only ever going to apply to that article, whereas 'Component' parameters are set for the component as a whole. As you point out, both types can be overridden for a particular menu link; administrators using your component will thank you if such overrides are the exception rather than the rule!
So, in the screenshot shown, there is the basic parameter 'Description text' field which (IIRC) provides a description of the article. It would make no sense to have this as a component parameter, since you would need to override it almost every time you use it. Note that there is no 'right' or 'wrong' here, just common sense. If a parameter is likely to be the same across the site (e.g. choosing whether or not to display the name of the author, which is likely to be fixed to maintain a consistent feel to a site), then put it in the component params. If it's likely to change in each case, make it an article param. If both would be useful, then use both. (Just make sure that you give the article param a 'Use global' (i.e. empty string) option as default, so that the component parameter works as expected.) Mike 18:23, 28 October 2008 (EDT)
I've seen this effect in several extensions, and it was very confusing and not obvious at first. Perhaps a note can be added. The issue is that the default params for the component, usually accessed by "Preferences" may not have been actually entered into the database.
It would be nice to just have a note, especially in the overrides section, that you need to make sure the component params are actually saved. It would also be nice if 3rd party components that use these config params either place a notice to the user that params must be saved, or make sure that the default params are entered into the database during the installation process, if these params do not yet exist.
Hope this makes some sense. I'm not really sure the best solution to this problem, but more documentation about this potential pitfall I'm sure would be helpful.