Specific component fields in com_categories
Christophe Demko
The new com_categories is very usefull but after some hours of play
with it, I think it lacks an important feature: the ability to add
fields used by an external component to each category
Imagine, there exist a
administrator/components/com_mycomponent/category.xml file with
definition of form fields in several groups.
When we call administrator/index.php?
option=com_categories&extension=com_mycomponent , we could add a var
request 'group' which indicate that we want to add fields for
categories taken from the group found in the above 'category.xml'
file.
These fields could be displayed in the edit form using a specific
slider (use of the label property of the group) and could be stored in
the params field of the #__categories using JSON
Case:
1. administrator/index.php?
option=com_categories&extension=com_mycomponent without the
category.xml file: do nothing
2. administrator/index.php?
option=com_categories&extension=com_mycomponent with a category.xml
file: use the default group (if it exists in the xml file)
3. administrator/index.php?
option=com_categories&extension=com_mycomponent&group=mygroup: use the
mygroup group (if it exists in the xml file)
This feature will allow inherited field from categories to items and
from categories to categories.
Christophe Demko
using
administrator/index.php?
option=com_categories&extension=com_mycomponent.mysection
where 'mysection' refers to the
administrator/components/com_mycomponent/categories.mysection.xml file
case:
option=com_categories&extension=com_mycomponent without the
category.xml file: do nothing
2. administrator/index.php?
category.xml file: use all groups and fields from category.xml as
additionnal params for each category
3. administrator/index.php?
option=com_categories&extension=com_mycomponent.mysection without the
category.mysection.xml file: do nothing
4. option=com_categories&extension=com_mycomponent.mysection with the
category.mysection.xml file: use all groups and fields from
category.section.xml as additionnal params for each category
This feature will allow:
-inherited field from categories to items and from categories to
categories.
-the use of several categories trees in one extension
Christophe Demko
Mark Dexter
getting at. Would it be possible for you to explain a use case more
from a user point of view? Thanks. Mark
Web Wizard Will
of what a plugin might be and that some new users may not understand
what a plugin does. They may think that a component does what a
module does and a module is something else.
I kinda agree with him but only about the the modules. As people are
used to the terms "Widgets" and "Gadgets" which is largely used. I
think the name structure is fine as is. A plugin seems to describe
itself fine as well as a component. Though I do think for new admins
people may understand modules better when they are described as
something similar to what other entities have called 'Widgets" and
"Gadgets"
It seems to be that the docs refer to components as mini applications
though this could be more provident. This might also be helpful for
new users.
The idea as I see it, is going with the terms that is used widely else
where and easily understood. By using these terms and peoples
understanding of these terms we can help people understand the Joomla
system faster.
Again my vote is the terms/references stay as is, though the
descriptions get tweaked to include these extra terms.
Web Wizard Will
Christophe Demko
* For the user's point of view, it does not change anything
* For the developer's point of view, it is a facilitator for
developing extensions
The com_categories component has been designed in order to allow
developers to set the membership of data managed by their component
using a general component: com_categories
To use com_categories for their component, developers have to do 3 (4)
things:
* create a "Categories" view in the backend which refers to index.php?
option=com_categories&extension=*extension_name*
* add a "catid" field in the table which manage their data
* add a form field of type "category" in their form
(* add rights management to their categories using an access.xml file)
It's a very good component but it can be easily extended allowing more
functionnalities.
1. A developer could have two different types of data in his
component. For the moment, he can use com_categories to set the
membership for only one.
2. A developer could have the need to add attributes to categories
managed by com_categories. For the moment, he cannot.
To allow these 2 functionnalities, I propose a patch for
com_categories
1. com_categories could be called in the backend by an url like
index.php?option=com_categories&extension=*extension_name.section* to
allow different types of categories for data (where *section* could
have several values for one component)
2. developer could define administrator/components/*component_name*/
category(.*section*).xml files in which there will be form fields.
These fields would be added ih the category edit form of their
component (in the right part using sliders).
3. developer could define several rights management in administrator/
components/*component_name*/access.xml using section="category
(.*section*)"
I can propose a patch for these new functionalities.
Andrew Eddie
A few questions.
Are these real fields added to the table or are they extra parameter fields?
Do you have a few use-case examples to help explain why a developer
might want to use this?
Thanks in advance.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/12/11 Christophe Demko <chd...@gmail.com>:
>
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
>
Hannes Papenberg
I'd say this is already possible in com_categories now. There are
basically two ways to extend the fields of categories in com_categories.
The first would be the normal category-parameters, that were introduced
in 1.6. This would add the additional information as a normal parameter
to the category, but it would have the downside of not really being
searchable. The second way would be the way that we do the user profiles
in 1.6 with the plugin attaching to JForm. Yes, its not as easy as
adding a line to an XML file, but I think it would be enough for now. :-)
Hannes
Christophe Demko schrieb:
Karol Čejka
maybe will be helpfull store in DB with category-parameters also
params xml definition, or link to definition file.
Than system can dynamicly show category extra-params (user/component
extra params).
karol
On 13. Dec., 00:01 h., Hannes Papenberg <hackwa...@googlemail.com>
wrote:
Christophe Demko
As Hannes say, these parameters can be easily stored in the JSON
format of 'parameters' field or in an extra table (as
#__user_profiles). This has to be discussed.
1. For adding parameters:
a) as an example, I'm currently trying to write a financial-accounting
component. In these type of application, there is an account hierarchy
(we can use the category hierarchy), but some account can support
operations (usually those which are leaves) and some cannot (usually
those which are in the top of hierarchy). So I need an extra boolean
parameter on each account (category).
I could create a controller/model/table/view tool similar to
com_categories with a specialized edit form, but it would be
reinvented the wheel with respect to com_categories. This is why I
think adding parameters to each category would be a good thing.
b) in a images gallery component, images are usually stored in
categories. There is often some parameters in the categories which can
be inherited from images.
c) in the virtuemart component, there are 'Show x products per row',
'Category Browse Page' and 'Category Flypage' which are extra
parameters to the classical category parameters
2. For having several categories trees in the same component, I think
there will be a lot of component which will need to categorize two
different types of data.
I think there will be applications which will need these
functionnalities. Who knows all the different ways to use a Swiss army
knife?
PS: I was so sorry to not be able to see you in NYC...
Andrew Eddie
I think if we get a good tutorial for how to hijack JForm, we'll be
able to address those issues. For more complex extensions, I would
actually recommend doing you own category view, if not use your own
categories table for the extension.
2009/12/13 Christophe Demko <chd...@gmail.com>:
Christophe Demko
I think I did not well understand your thoughts:
1. Do you think they are important features but actually, we cannot
adress them? (I don't think so, I have proposed to submit a patch)
2. Do you think they are important features but they will be released
in a 1.7 or 1.8 version?
3. Do you think they are not important features?
Christophe
On 13 déc, 20:09, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Christophe
>
> I think if we get a good tutorial for how to hijack JForm, we'll be
> able to address those issues. For more complex extensions, I would
> actually recommend doing you own category view, if not use your own
> categories table for the extension.
>
> Regards,
>
> 2009/12/13 Christophe Demko <chde...@gmail.com>:
Andrew Eddie
I think you will be able to do what you suggest in 1.6 with a plugin
similar to the user profile plugin. All you need to do is listen for
the category JForm and inject a new panel into it.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/12/14 Christophe Demko <chd...@gmail.com>:
Christophe Demko
remain some issues. I will provide a patch for correcting them.
Christophe
On 14 déc, 16:52, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Christophe.
>
> I think you will be able to do what you suggest in 1.6 with a plugin
> similar to the user profile plugin. All you need to do is listen for
> the category JForm and inject a new panel into it.
>
> Regards,
>
> > Hi Andrew,
>
> > I think I did not well understand your thoughts:
>
> > 1. Do you think they are important features but actually, we cannot
> > adress them? (I don't think so, I have proposed to submit a patch)
> > 2. Do you think they are important features but they will be released
> > in a 1.7 or 1.8 version?
> > 3. Do you think they are not important features?
>
> > Christophe
>
> > On 13 déc, 20:09, Andrew Eddie <mambob...@gmail.com> wrote:
> >> Hi Christophe
>
> >> I think if we get a good tutorial for how to hijack JForm, we'll be
> >> able to address those issues. For more complex extensions, I would
> >> actually recommend doing you own category view, if not use your own
> >> categories table for the extension.
>
> >> Regards,
>
> plus de détails »
Andrew Eddie
category.xml. We'd have to change the controllers and models a bit
for the params similar to why I've done in com_modules or com_plugins
(only because JForm can't support nested forms yet - that's something
we need to solve actually).
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/12/15 Christophe Demko <chd...@gmail.com>:
>
>
>
Mark Dexter
Andrew Eddie
Christophe Demko
On 15 déc, 18:22, Andrew Eddie <mambob...@gmail.com> wrote:
> Yes, Mark, it would allow for that.
>
> Regards,
>
> > Andrew, would this allow us to add the com_content parameters at the
> > category level that we discussed a while back. If you recall, we decided not
> > to put them in the category level, since they only applied to articles. If I
> > understand this correctly, this change would allow us to have parameters
> > that only show for article categories. Is that right? If so, should we
> > re-consider that decision? Thanks. Mark
>
>
> >> Actually Christophe, I've changed my mind. Let's add the
> >> category.xml. We'd have to change the controllers and models a bit
> >> for the params similar to why I've done in com_modules or com_plugins
> >> (only because JForm can't support nested forms yet - that's something
> >> we need to solve actually).
>
> >> Regards,
> >> Andrew Eddie
> >> > remain some issues. I will provide a patch for correcting them.
>
> >> > Christophe
>
> >> > On 14 déc, 16:52, Andrew Eddie <mambob...@gmail.com> wrote:
> >> >> Hi Christophe.
>
> >> >> I think you will be able to do what you suggest in 1.6 with a plugin
> >> >> similar to the user profile plugin. All you need to do is listen for
> >> >> the category JForm and inject a new panel into it.
>
> >> >> Regards,
> >> >> developer
>
> >> >> 2009/12/14 Christophe Demko <chde...@gmail.com>:
>
> >> >> > Hi Andrew,
>
> >> >> > I think I did not well understand your thoughts:
>
> >> >> > 1. Do you think they are important features but actually, we cannot
> >> >> > adress them? (I don't think so, I have proposed to submit a patch)
> >> >> > 2. Do you think they are important features but they will be released
> >> >> > in a 1.7 or 1.8 version?
> >> >> > 3. Do you think they are not important features?
>
> >> >> > Christophe
>
> >> >> > On 13 déc, 20:09, Andrew Eddie <mambob...@gmail.com> wrote:
> >> >> >> Hi Christophe
>
> >> >> >> I think if we get a good tutorial for how to hijack JForm, we'll be
> >> >> >> able to address those issues. For more complex extensions, I would
> >> >> >> actually recommend doing you own category view, if not use your own
> >> >> >> categories table for the extension.
>
> >> >> >> Regards,
>
> plus de détails »
Christophe Demko
http://joomlacode.org/svn/joomla/development/branches/chdemko svn
branch as explained in http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=19018
Ch.D
On 16 déc, 09:47, Christophe Demko <chde...@gmail.com> wrote:
> I think I can post a patch this day or tomorrow on the chdemko branch.
>
> On 15 déc, 18:22, Andrew Eddie <mambob...@gmail.com> wrote:
>
> > Yes, Mark, it would allow for that.
>
> > Regards,
>
>
> > > Andrew, would this allow us to add the com_content parameters at the
> > > category level that we discussed a while back. If you recall, we decided not
> > > to put them in the category level, since they only applied to articles. If I
> > > understand this correctly, this change would allow us to have parameters
> > > that only show for article categories. Is that right? If so, should we
> > > re-consider that decision? Thanks. Mark
>
> > > On Tue, Dec 15, 2009 at 8:52 AM, Andrew Eddie <mambob...@gmail.com> wrote:
>
> > >> Actually Christophe, I've changed my mind. Let's add the
> > >> category.xml. We'd have to change the controllers and models a bit
> > >> for the params similar to why I've done in com_modules or com_plugins
> > >> (only because JForm can't support nested forms yet - that's something
> > >> we need to solve actually).
>
> > >> Regards,
> > >> Andrew Eddie
>
> > >> 2009/12/15 Christophe Demko <chde...@gmail.com>:
> > >> > Ok, I understand what you mean (listen to the onPrepareForm) but there
> > >> > remain some issues. I will provide a patch for correcting them.
>
> > >> > Christophe
>
> > >> > On 14 déc, 16:52, Andrew Eddie <mambob...@gmail.com> wrote:
> > >> >> Hi Christophe.
>
> > >> >> I think you will be able to do what you suggest in 1.6 with a plugin
> > >> >> similar to the user profile plugin. All you need to do is listen for
> > >> >> the category JForm and inject a new panel into it.
>
> > >> >> Regards,
> > >> >> developer
>
> > >> >> 2009/12/14 Christophe Demko <chde...@gmail.com>:
>
> > >> >> > Hi Andrew,
>
> > >> >> > I think I did not well understand your thoughts:
>
> > >> >> > 1. Do you think they are important features but actually, we cannot
> > >> >> > adress them? (I don't think so, I have proposed to submit a patch)
> > >> >> > 2. Do you think they are important features but they will be released
> > >> >> > in a 1.7 or 1.8 version?
> > >> >> > 3. Do you think they are not important features?
>
> > >> >> > Christophe
>
> > >> >> > On 13 déc, 20:09, Andrew Eddie <mambob...@gmail.com> wrote:
> > >> >> >> Hi Christophe
>
> > >> >> >> I think if we get a good tutorial for how to hijack JForm, we'll be
> > >> >> >> able to address those issues. For more complex extensions, I would
> > >> >> >> actually recommend doing you own category view, if not use your own
> > >> >> >> categories table for the extension.
>
> > >> >> >> Regards,
>
> plus de détails »
Hannes Papenberg
this is regarding the nested forms issue. I've been looking at this
earlier already, since I think it would be great to have a second level
of grouping for the form elements inside of a form. Let me explain the
use case for this:
The user profile currently consists of basically two parts:
- The basic user information like mailadress, name, skype contact,
hobbys, etc., which show up in a public profile. They are grouped into
different fieldsets.
- Userparameters like "show mailadress", "receive massmailings", "block
user", which don't show up in a public profile, but only for the actual
user. These should be in an accordeon with seperate slides for each
subgroup of parameters. These all have the same form-array in HTML, so
that they are automatically saved in the params field of #__users
Currently we don't have an accordeon slide for the user parameters,
because we are missing the second level of grouping to say which slides
to create in the accordeon. The actual use case in the core would be to
have the additional user parameters, like the configuration for
com_massmail, in the general user edit screen in both front- and
backend. Of course we currently can extend this with a plugin, similar
to the profile plugin currently in the trunk, but to me this is pretty
"complicated" for a quite simple task like adding to the params array of
the form. My idea would be, for these simple cases where the data does
not have to be processed by a plugin before and after, that you can
simply drop a file in a special folder (like
/administrator/assets/user/) and com_user reads all files from there,
adding the new fields to the form automatically visually from this into
the accordeon and programmaticaly into the correct HTML form-array. This
way we could spare us all the extra code for the quadrillion different
user-config-screens in all those different components. Think about a
forum being able to just use com_user in the frontend for the user
parameters and user profile view. All this would be especially
interesting, since for the frontend profile view, you would just have to
drop the accordeon and the result would basically be your user profile. :-)
I've worked with Louis on this already a little bit, but I think I
didn't communicate my idea really well, so his changes were not enough
to implement this. I myself am a bit hesitant to just take a go at it,
since its your work and you have a deeper knowledge about it and the
intentions behind this than I. (My problems also were around the pretty
early validation of data against the form, which meant that values were
dropped, because not all form elements were loaded in the JForm object
at that time.)
Now this is not only for the user parameters, but also for the
parameters in all other extensions. Why not extend the forms the same
way for content, weblinks, etc.? Instead of creating a form plugin that
adds in the one single parameter ("Show comments", "Show social
community badges for this article", "Show author profile for this
article") for a third-party extension, just drop in the XML file and it
automatically appears in the form and can later be accessed by the
frontend plugin as a simple parameter.
I think this has a lot of potential and would make JForm a bit more
flexible. :-) Do you see a possibility to implement something like this
in JForm? I'd help you with making the code changes in all core
extensions once JForm has been modified. ;-)
Hannes
Andrew Eddie schrieb:
> Actually Christophe, I've changed my mind. Let's add the
> category.xml. We'd have to change the controllers and models a bit
> for the params similar to why I've done in com_modules or com_plugins
> (only because JForm can't support nested forms yet - that's something
> we need to solve actually).
>
> Regards,
> Andrew Eddie
> http://www.theartofjoomla.com - the art of becoming a Joomla developer
>
>
>
>
> 2009/12/15 Christophe Demko <chd...@gmail.com>:
>
>> Ok, I understand what you mean (listen to the onPrepareForm) but there
>> remain some issues. I will provide a patch for correcting them.
>>
>> Christophe
>>
>>> plus de d�tails �
Christophe Demko
on the
http://joomlacode.org/svn/joomla/development/branches/chdemko svn
branch as explained in http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=19018
Ch.D
> >http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> > 2009/12/15 Christophe Demko <chde...@gmail.com>:
>
> >> Ok, I understand what you mean (listen to the onPrepareForm) but there
> >> remain some issues. I will provide a patch for correcting them.
>
> >> Christophe
>
> >> On 14 d c, 16:52, Andrew Eddie <mambob...@gmail.com> wrote:
>
> >>> Hi Christophe.
>
> >>> I think you will be able to do what you suggest in 1.6 with a plugin
> >>> similar to the user profile plugin. All you need to do is listen for
> >>> the category JForm and inject a new panel into it.
>
> >>> Regards,
> >>> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer
>
> >>> 2009/12/14 Christophe Demko <chde...@gmail.com>:
>
> >>>> Hi Andrew,
>
> >>>> I think I did not well understand your thoughts:
>
> >>>> 1. Do you think they are important features but actually, we cannot
> >>>> adress them? (I don't think so, I have proposed to submit a patch)
> >>>> 2. Do you think they are important features but they will be released
> >>>> in a 1.7 or 1.8 version?
> >>>> 3. Do you think they are not important features?
>
> >>>> Christophe
>
> >>>> On 13 d c, 20:09, Andrew Eddie <mambob...@gmail.com> wrote:
>
> >>>>> Hi Christophe
>
> >>>>> I think if we get a good tutorial for how to hijack JForm, we'll be
> >>>>> able to address those issues. For more complex extensions, I would
> >>>>> actually recommend doing you own category view, if not use your own
> >>>>> categories table for the extension.
>
> >>>>> Regards,
> >>>>> Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a Joomla developer
> ...
>
> plus de détails »
Andrew Eddie
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/12/26 Christophe Demko <chd...@gmail.com>:
Hannes Papenberg
I looked at your proposal and the code. The idea has its benefits, but I
don't think it fits into 1.6. My biggest concern is, that you would have
to load JForm for every page load at least once to get the data. This
would bring almost every site to a grinding stop in terms of
performance. I think we should revisit this idea again for 1.7. For 1.6
I'd like to keep it the way it is, except for being able to extend the
category parameters with the category.xml that you described, but saving
that in the JSON encoded params array. Everything else can already be
done in 1.6 with the plugins Andrew described earlier.
Hannes
Am 26.12.2009 10:49, schrieb Christophe Demko:
> Just a bump to remember that the new functionalities are ready to test
> on the
> http://joomlacode.org/svn/joomla/development/branches/chdemko svn
> branch as explained in http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=19018
>
> Ch.D
>
Christophe Demko
> don't think it fits into 1.6. My biggest concern is, that you would have
> to load JForm for every page load at least once to get the data.
It's now corrected in the code:
> This
> would bring almost every site to a grinding stop in terms of
> performance. I think we should revisit this idea again for 1.7. For 1.6
> I'd like to keep it the way it is, except for being able to extend the
> category parameters with the category.xml that you described, but saving
> that in the JSON encoded params array. Everything else can already be
> done in 1.6 with the plugins Andrew described earlier.
Yes, but currently, params are stored in an json encoded string and
cannot be used for a sql query. In my branch, you can do that
>
> Hannes
>
> Am 26.12.2009 10:49, schrieb Christophe Demko:
>
> > Just a bump to remember that the new functionalities are ready to test
> > on the
> >http://joomlacode.org/svn/joomla/development/branches/chdemkosvn
> > branch as explained inhttp://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...
> >>>http://www.theartofjoomla.com-the art of becoming a Joomla developer
>
> >>> 2009/12/15 Christophe Demko <chde...@gmail.com>:
>
> >>>> Ok, I understand what you mean (listen to the onPrepareForm) but there
> >>>> remain some issues. I will provide a patch for correcting them.
>
> >>>> Christophe
>
> >>>> On 14 d c, 16:52, Andrew Eddie <mambob...@gmail.com> wrote:
>
> >>>>> Hi Christophe.
>
> >>>>> I think you will be able to do what you suggest in 1.6 with a plugin
> >>>>> similar to the user profile plugin. All you need to do is listen for
> >>>>> the category JForm and inject a new panel into it.
>
> >>>>> Regards,
> >>>>> Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a Joomla developer
>
> >>>>> 2009/12/14 Christophe Demko <chde...@gmail.com>:
>
> >>>>>> Hi Andrew,
>
> >>>>>> I think I did not well understand your thoughts:
>
> >>>>>> 1. Do you think they are important features but actually, we cannot
> >>>>>> adress them? (I don't think so, I have proposed to submit a patch)
> >>>>>> 2. Do you think they are important features but they will be released
> >>>>>> in a 1.7 or 1.8 version?
> >>>>>> 3. Do you think they are not important features?
>
> >>>>>> Christophe
>
> >>>>>> On 13 d c, 20:09, Andrew Eddie <mambob...@gmail.com> wrote:
>
> >>>>>>> Hi Christophe
>
> >>>>>>> I think if we get a good tutorial for how to hijack JForm, we'll be
> >>>>>>> able to address those issues. For more complex extensions, I would
> >>>>>>> actually recommend doing you own category view, if not use your own
> >>>>>>> categories table for the extension.
>
> >>>>>>> Regards,
> >>>>>>> Andrew Eddiehttp://www.theartofjoomla.com-theartof becoming a Joomla developer
> ...
>
> plus de détails »