(→Non overridable parameter)
(→Accessing the parameters - frontend: new section)
|Line 96:||Line 96:|
--[[User:UsagiYojimbo|UsagiYojimbo]] 15:24, 20 October 2009 (UTC)
--[[User:UsagiYojimbo|UsagiYojimbo]] 15:24, 20 October 2009 (UTC)
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.
Snellcode, good point. Tbh, I think the whole parameters subject is a little difficult to get hold of - my main reason for writing this was so that I could get everything straight in my own head. The way it should work is that the
COMPONENT_NAME.xml installation file creates the parameters in the database, so that the component defaults are already set. If this is not done, then you are right - it is necessary to open the 'parameters' window, choose the values, and save, so that the parameters are created. The wrong way to do things, which may be what is going on, is to try to combine both steps (ignoring the installation file) and give the
<param /> elements in the
default values. These will show up in the parameters window, but do not appear in the database until they are saved. The article does kind of refer to this, but I will think about how to make it more explicit.
You could try point the 3PDs to this article, or simply vote with your feet and use a different extension! Mike 21:36, 17 February 2009 (UTC)
I have deleted Jmgonet's paragraph about adding a reference to the install file, as I think it is outside the scope of this article (which tbh is already complicated enough!) The article is aimed at those developing components, who should be aware of the need to ensure that all necessary files are installed (covered adequately elsewhere). In any case, the best option is to use a
<folder /> tag in the install file, rather than lots of
<filename /> tags; that way, there is no need to list every single file, and less risk of a file being missed. Hope that's ok! Mike 21:54, 17 February 2009 (UTC)
I am trying to understand all of what has been said on this page. I have a background in php but haven't programmed for years.
It would really help me if a example component was made and offered up as a zip file. Something just VERY simple, it wouldn't even need to fulfill a any kind of function. Just show me a working example without all the other stuff. It would not even need to show everything talked about on the page, just the common stuff. After people have the basics, I am sure they could understand your article without an working example.
One more note about the install.
I now understand by reading the discussion, but it would be nice somewhere in the article if it said that loading the settings was not NECESSARY in the install. It was unclear to me when the install was mentioned if I had to include it in the install, and go through a install for any of what was being said to work.
I know these might be very basic concepts. But thats where I am right now. You have to start somewhere.
In an MVC structure, this code would be placed in the view.html.php file for the particular view required.
Assuming that the item parameters are stored in the params field, and that the particular item has been loaded into the $row object by the method, you would then add in the item parameters to the $params object using:
Please give an example of this. Don't know what you are talking about. I don't see the an example of how to load the $row ether.
I have been able to get global preferences set, but don't have enough info override the globals with page specific ones.
Drsassafras 20:16, 21 March 2009 (UTC)
There is an issue with using the XML installer file to set params field values in jos_component. See: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=17767
Including the following code in the XML install file has no affect - db field params remains empty until users saves config in view. <install> .. <params>
<param name="foo" default="bar" />
</params> .. </install>
Exps1 12:54, 16 October 2009 (UTC)
I need to create a global parameter that is not overridable.
A component parameter would do, but is overridable at menu item level. (I do not use articles, so article level does not concern me.)
Is there a way to create such a parameter?
--UsagiYojimbo 15:24, 20 October 2009 (UTC)
Is the first code snippet correct? If I read the text correctly, it claims that JComponentHelper::getParams() merges in the menu item specific parameters with the component-wide default parameters. When I read the code for the latest 1.5 version, I don't see that. It appears to me that the application's getParams() method does this (such as JSite::getParams()).