Page 1 of 1

[12]Improvements to JParameter

Posted: Fri Feb 15, 2008 9:07 pm
by Hackwar
1. Introduction
1.1 Scope
The scope of this document is a first draft of improvements to the JParameter class introduced in Joomla! 1.5.
1.2 Objective of the document
The objective is to give a basis for a discussion about an extension of the JParameter class for Joomla! 1.6.
1.3 General remarks
This proposal is based on the functionality of JParameter in the Joomla! 1.5 stable version.
1.4 Definitions
1.5 License
2. What is the current functionality of JParameter
JParameter is a class to handle configurationsettings. While it has huge functionality, this draft only concentrates on the rendering of the configurationoptions and the underlying description of the configurationoptions in the used XML files. For every <param>-tag in the XML file you get one configurational option, whose behaviour, allowed values, etc. are controlled by the „type“-parameter and the underlying definitions.
3. What are the proposed improvements?
3.1 Conditional parameters
Currently always all options are shown. In some cases it would be more usefull to activate some options only when other options are activated. For example an alternative readmore text is only applicable when the readmore is going to be shown. Another example would be a component which uses different locating methods like google maps, map24 or mapandguide with different configurational options for the different services.
JParameter should be extended to render the parameters so that optional settings are only shown when the higher ranking option has been activated.
3.2 Dynamic loading of XML definitions
Currently the options for a layout are fixed by the single XML file in the layout folder of the view. For extensions like commenting plugins it would be very helpfull to be able to extend the parameter set automatically. For this, JParameter should get a function to load all XML files in a given folder. This allows for a super flexibel parameter system which is extensible by every extension without hacking core files.
4. Technical realisation
4.1 Conditional parameters
The optional parameters are controlled by a new set of tags and XML-parameters in addition to the existing ones.

<conditionalParameters>: This opens a new block of conditional parameters, which are later then inserted at the position where they are in the XML-file.
„name“: This defines the parameter the conditional parameters should react upon.
„design“: This defines the template that should be used for the rendering of the parameter set, similar to the module chrome. This is an optional parameter.

<conditionalParameter>: This opens a new block for a conditional parameter set. Inside this block you can find the additional parameters.
„value“: This defines on which value of the higher ranking parameter this set of parameters should appear.

It should be possible to nest these sets into each other indefinitely.

For rendering, the mootools library should be used to hide the inactive parameters.
4.2 Dynamic loading of XML definitions
This function should use JFile to get a list of all files with .xml extension in a folder, put a filter on it to filter out some unwanted files and then read the XML files into the JParameter object with the allready available function from JRegistry.
Additionally, a folder naming convention should be created to spread this feature over to other extensions. A possibility would be a similar convention to jimport, just starting from the root of Joomla and not from a specific folder, where the last string after the dot is extended with "param", where the additional XML files are stored.
5. Intention
In Joomla! 1.5 we have a very powerfull parameter system, however it always shows the complete list of parameters of a group, even when some of those parameters are not working without others being switched on. With this change, a lot of confusions could be solved on the users side and the interface would be a lot cleaner.
Although being extendable when developing the settings with own parameter types, the final settings are fixed and can not be changed by an extension without „hacking the core“ e.g. overwriting the XML file. With this again, we would potentially overwrite the settings of another extension. With the dynamic loading of XML definitions we would have a way to extend the settings without changing one line of code and thus bring the settings of a plugin down to the content items level. With these changes a commenting system could be switched on and off on an article basis and the advanced settings for the plugin would only be visible when the system is switched on. Furthermore, layout overrides could implement their own options, templates could use completely their own sets of settings.
6. Effects on...
6.1 Users
There should be no negative effect on the users.
6.2 3P extensions
These changes should have no negative effect on third party extensions.
6.3 Performance
Both additions will have a small impact on performance, but the code would only be executed in the core components when something is edited, not on a normal page load. Thus the performance hit will most likely be neglectable.

Re: Improvements to JParameter

Posted: Tue Feb 19, 2008 9:14 am
by Hackwar
I have given the "read all XMLs from a directory"-function a bit more thought and want to remove it from this proposal. Instead of it, I will propose another solution in the next days. There have been some difficulties with my approach... :)

Re: Improvements to JParameter

Posted: Tue Feb 19, 2008 6:29 pm
by pollen8
Love the idea of having one parameter activate or deactive a set of corresponding parameters.

This is probably out of the scope of this whitepaper - but Ive found that in Fabrik I often need to duplicate sets of parameters as well. An example of this might be this:

fabrik 2.0 has a section in the administration called "visualizations" - these are specific views which look at x tables of data and collate the data in a visualization (think plotting points on a google map, dates on a a calendar, etc).

Each visualization can connect to x tables to get this data so you need an interface :

Code: Select all

{parameter}database connection{/parameter}
{link}add table{/link}
{parameter}table drop down{/parameter}
{parameter}table drop down{/parameter}    {link}delete{/link}
{parameter}table drop down{/parameter}    {link}delete{/link}
Im currently hacking around with an override to the parameters class which will work with the following xml:

Code: Select all

<param name="calendar_conenction" type="fabrikconnection" />	
<params group="fields" repeat="1">
    <param name="calendar_table[]" type="fabriktables" observe="calendar_connection" label="Table"/>
Id be interested to know if Im the only crazy who needs this type of stuff - or if its something that could be generally useful??


Re: Improvements to JParameter

Posted: Wed Feb 20, 2008 2:36 pm
by Jick

I think our whitepapers match a lot so instead of posting my own topic I'll add it to yours.

Please have a look and see where we can put two and two together on this issue.


I tried to attach .doc or .pdf but both are not allowed so posting the text here.

Designer/builder param control

Designer/builder = The people that build the site, in most cases front-end designers and programmers.

With the template overrides a lot more power is available for the people building the technical part of a website which is great.
An addition to this and a very powerful one to make it possible for Joomla! sitebuilders to create sites that are different and more flexible than the general Joomla! design and standard right now.

Make it possible to override and extend the xml params.

Example 1:
I have a page where I want to load a special view.
To accomplish this I would want to have a param in the menu params list where I can set “review” for example. This is a param I can check against with a plugin or in the template itself.

Example 2:
I want to add color classes to single menu items to create colorful menus.
In the override xml I create a param dropdown for color eg blue, red, green. I alter the mainmenu override template and add that param to the <li class so that it will be rendered and I’m able to style it.

Example 3:
I create a site with general settings that are used throughout the whole site for article presentation. These setting are set in the article general config.
To make things more simple for users I remove all or some of the param options from the create article and menu params list.
Users won’t get the option to choose whether a print-icon should be shown for each article or menu because the site style for this is defined in the general article config.

This would also mean you could change the default params for a specific site, if you want the page title to always be hidden you can set it in the xml overrides.

And so on.

These extended params aren’t for the hobby user probably but for builders on a professional level they mean lots of flexible power.

Dir structure:

Your template
---- html
---- com_content
---- article
| ---- default.php
| ---- form.php
---- xml
| ---- params-basic.xml
| ---- params-advanced.xml
| ---- params-component.xml
| ---- params-system.xml
| ---- params-custom.xml

If found in the overrides dir use that else use the one in the component.

Admin Usability:
Implementing this will also mean a round of proper testing and reconsidering params which may help reducing them where there are to many options in to many places right now for most users to understand.

- Extreme powerful params/extended forms
- More power to the developer that needs to go beyond a standard Joomla! site
- A way to create standards for certain sites based on what’s needed for that site to make life of the content manager more easy. (default and hidden params)
- People that don’t need them don’t have to bother (if else)

Re: Improvements to JParameter

Posted: Wed Feb 20, 2008 4:50 pm
by Hackwar
Hey Arno,
I thought about this, too, and I didn't want to override the parameters, but merely extend them. My problem with overrides would be, that a commenting system could override the parameters of com_content and then a template overrides the parameters of the commenting system when initially trying to override the com_content parameters. Thats why I wanted to initially propose the ability to load a bunch of XML files into one JParameter object, rendering that, etc. (The saving and using of the parameters would not be affected through this)
However, I think this solution would pose quite a strain on performance, so we would be better of with your proposal performance wise, which then again creates the problem described above.

I'm still working on my newest proposal concerning extended parameters. This aims at creating a component that can read an existing XML file, insert some nodes or in this case parameters and then saves the whole new XML shebang as a new XML file. Together with a source= attribute, this could allow us to create not only extendable parameters, but together with a rendering chrome, extendable user-informations, contact forms, etc.
I'm still thinking this through and looking at the plausibility etc., but it would be a huge gain, even if we at first only allow extensions to install their parameters in other XML files. As long as it is used only in creating the parameter forms, which are then saved and used in the same manner as now, there should be no performance loss either.

As I said, still forming this idea. ;)


Re: Improvements to JParameter

Posted: Wed Mar 05, 2008 3:07 pm
by Hackwar
I looked into the dynamic loading of XML files again for JParameter. Here is the working patch, that does all what I wanted to have. :)

Re: [12]Improvements to JParameter

Posted: Mon Apr 21, 2008 6:11 am
by Koichi
Hackwar, hello there!
How to apply your patch?
Will it let me create a new type of parameters?
I'm trying to extend com_content so that it supports item's images field, which is a multiple set of images which we had supported with Joomla 1.0.x

Koichi Senada, Russia

Re: [12]Improvements to JParameter

Posted: Tue Feb 03, 2009 10:52 am
by webamoeba
Talking of enhancements to JParameter, I think there is an issue with the render method.