Purpose of module root categories/sections

[Alexander Obuhovich]

In-Portal is a modular CMS. Each module can have it's own top/root category/section defined

These root categories were used for permission setting and all other stuff, but today in 5.x versions of In-Portal I have doubts, that they ever are needed.

I'm ok with keeping Directory/News/Forums/Products categories, but I want to get rid of "module root" category term and setting.


Please tell me how you use that "module root categories" and if there is ability to do the same without them and it won't be affecting any core aspects of In-Portal functionality, then it will be good for all of us.

This discussion is related to http://groups.google.com/group/in-portal-dev/browse_thread/thread/a646e79c4c6834f6

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

Based on my latest way of using In-Portal, I use module settings, but module root isn't used anymore.
For instance, I needed to manage different type of news in more than one top category, and as we discussed before, we can use modules functions from anywhere in structure.

I'll have a question about module dependant functions: we have items that summarize and count items, and actually, wether I use them in a top category or another, it display the total of all categories for given type if items (news). Am I wrong?

2010/10/8 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

You are talking about ItemCount and alike tags? If so, then yes, they could total items visible to average user (not looking into user permissions). Module root category isn't taken into affect in this case.

I didn't look into a code about how module root is used for now, but I suppose that it's removal won't be affecting ModRewrite, since:

• each category item's url (filename) is stored in common CategoryItems table
  
• each category path (filename) is stored in Category table
• what template to show for individual item/category is stored in that same Category table plus CategoryCustomData table
  

Also module root categories were used to print out list of category items in module, e.g.

<inp2:p_ListProducts render_as="product_element" parent_cat_id="Root" module="In-Commerce"/>

That can be a problem, since without module root category we don't know ID of category with products. We also can't hardcode ID of Products category in "advanced" theme, since based on In-Commerce (or any other module) installation order that ID can be changed.


Maybe we could minimize impact of module root categories on the system, but because of such weird usage it can't eliminated completely. I really need to inspect all module root usage aspects to tell for sure.

[Phil -- wbtc.fr --]

about printlist, you are right, but can't we use it as "list from actual category, recusively"?

this would solve this part

2010/10/8 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

This will work this way already, when "parent_cat_id" parameter isn't specified.

But, when you need to display most popular products on home page of the site, where current category is 0, and not "Products".

[Phil -- wbtc.fr --]

We shouldn't orient our functionnalities just for the need of our example template.

If we want to display popular product on homepage, wouldn't it search recursively in all caterogies?

2010/10/8 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

You are right actually. We'll get products from all categories and will filter them based on required conditions.

No need for pseudo category name "Root" in PrintList tag then.

On Oct 8, 2010 12:30 PM, "Phil -- wbtc.fr --" <ph...@wbtc.fr> wrote:
> We shouldn't orient our functionnalities just for the need of our example
> template.
>
> If we want to display popular product on homepage, wouldn't it search
> recursively in all caterogies?
>
>
> 2010/10/8 Alexander Obuhovich <aik....@gmail.com>
>
>> This will work this way already, when "parent_cat_id" parameter isn't
>> specified.
>>
>> But, when you need to display most popular products on home page of the
>> site, where current category is 0, and not "Products".
>>
>>
>> On Fri, Oct 8, 2010 at 11:55 AM, Phil -- wbtc.fr -- <ph...@wbtc.fr> wrote:
>>
>>> about printlist, you are right, but can't we use it as "list from actual
>>> category, recusively"?
>>>
>>> this would solve this part
>>>
>>>
>>>
>>> 2010/10/8 Alexander Obuhovich <aik....@gmail.com>
>>>

>>>> You are talking about *ItemCount* and alike tags? If so, then yes, they

>>>> could total items visible to average user (not looking into user
>>>> permissions). Module root category isn't taken into affect in this case.
>>>>
>>>> I didn't look into a code about how module root is used for now, but I
>>>> suppose that it's removal won't be affecting ModRewrite, since:
>>>>

>>>> - each category item's url (filename) is stored in common
>>>> CategoryItems table
>>>> - each category path (filename) is stored in Category table
>>>> - what template to show for individual item/category is stored in

>>>> that same Category table plus CategoryCustomData table
>>>>
>>>>
>>>> Also module root categories were used to print out list of category items
>>>> in module, e.g.
>>>>

>>>> *<inp2:p_ListProducts render_as="product_element" parent_cat_id="Root"
>>>> module="In-Commerce"/>*

[Phil -- wbtc.fr --]

yup, that's better this way.

[Alexander Obuhovich]

Here are all places, based on code, where "RootCat" word is used. I must admit, that some of them are pretty weird and most probably were traveling from one release to another without being noticed.

1. SuggestItemLink tag - when shown on index page, then actually allows to suggest into module root category - I haven't seen suggest link on index page :))
   
2. IsModuleHome tag - used to display different content of category in case if that's module root category (used in In-Commerce in in-commerce/designs/section.tpl) - used for mixed themes (e.g. where in-link and in-commerce are together used). I won't be recommending such themes to be created. I vote for create e-shop themes independent from in-link themes and so on. Or at least display all top/hot and so on items on main site index page, not to each module have it's own.
   
3. CategorySelector tag - shows child category structure based on module root category for suggest/edit link/article page - since it don't know what category is a top, them "Home" category will be used and that will display In-News categories on In-Link suggest page
   
4. c_CheckModuleRoot tag - ensures that module root category is always displayed using given template (used in onlinestore theme) - never used in advanced theme, so I propose to remove it at all
   
5. c_CategoryLink tag - builds link to module root category - just won't be doing that anymore
   
6. PrintList - lists category items from module root category recursively - just will be printing from "Home" category and deeper
   
7. c_NavigationBar - renders module root category using separate block - that I don't know how to handle; maybe there is no need for special handling, since you could do the same by specifying different section design for category acting as module root (if any)
   
8. Item rendering template detection, when category not passed - get from root category of module associated with given prefix (don't recall if it even was required by someone)
9. u:OnResetPassword event redirects to thank you page with In-Commerce root category hardcoded :) - works even, when In-Commerce isn't installed, needs to be removed
   
10. Various places getting top product category (In-Auction, In-Commerce) - could scan all db instead

All output related usages could use Home category instead and will get same behavior.

My most concern is about CategorySelector tag.

[Phil -- wbtc.fr --]

Great list!

If we can use CategorySelector (and other ones we decide to keep) by specifying category ID, then it'll be perfect: without any category ID passed, it'll work from home, which would be the most common behavior needed. Your opinion?

2010/10/8 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Then tags "c_CheckModuleRoot" and "IsModuleHome" should be deleted, since they rely on module root categories only. Other places will get category as follows:

• when not passed, then Home category used
• when passed will use passed category
• when 0 passed, then actual ID of Home category will be used
  

[Phil -- wbtc.fr --]

what's the difference between 1 & 3? Sorry I don't get it, but whole thing seems good to me anyway :-)

2010/10/9 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

For example, when you don't know actual ID of Home category and want to print popular products from all categories, while viewing contents of some category located deeper. Without specifying category id you will print only popular products from current category.

[Alexander Obuhovich]

However I must admit, that you can specify "any", e.g. <inp2:l_PrintList render_as="link_element" parent_cat_id="any"/>. That will work faster, then when parent_cat_id="0" since it simply doesn't apply any category filter.

[Phil -- wbtc.fr --]

what if we don't give any parent cat? inp can't kow catalogue's root?

2010/10/9 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

If we don't give any, the it will list from current category as for now.

[Phil -- wbtc.fr --]

then we can keep "category id" and use given id or "all" (sounds easier to understand than "any", no?)

2010/10/9 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

parent_cat_id - is ONE category. Parameter, that expects ONE category ID to be given, can't logically understand multiple IDs referred by "all" (all parents) word. However "any" means "any ONE of them", so it fits here. That's why such "any" word was chosen in first place.

[Phil -- wbtc.fr --]

then I agree, nothing to add here !

2010/10/9 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Ping to Dmitry.

What we'll with this one. Get rid of module root categories or not. If we do we can remove interface for changing module root category (useful for websites who do an upgrade to keep what they have) and we set Home as root category for all modules during new installations. We can keep "RootCat" column in Modules table for backwards compatibility, but don't rely on it internally.

P.S.

Dmitry, you haven't posted in this discussion at all, so I advise to read all previous posts in it to get idea about the subject.

[Dmitry A.]

Thanks for revisiting this Alex.

I did read complete conversation and here is what I think:

Your main concern is some code (rarely used) plus interfaces for selecting Module Root Category, but we should look from In-Portal architecture point on this and not just code usage.

I have 2 concerns at this point:

1. We are VERY attached to the Categories table since starting In-Portal 5 we've our Website Structure connected to even more than before.

2. We are considering on minimizing / breaking CORE into smaller independent modules and some of them my rely on Categories one way or another as well. 

To summarize the above, I believe we should wait until we finalize CORE minimization and get our heads around what's really going to happen from architecture point and then revisit this topic otherwise we can just remove something we potentially need at the time of minimization.

Make sense?

DA

[Alexander Obuhovich]

It doesn't actually :)

We minimize what we have. If we remove something before doing minimization, then it's not needed anyway.

Main reason to remove concept of module root categories is to prevent any "magic code" from doing specific things in a category just because it's specified as module root. It's not a rare case, when In-Portal users place items from all modules (e.g. links, articles) in same categories and create really interesting websites using it.

Category permission system allows to set permissions from multiple In-Portal Modules to a single category and all work as before.

Main code I want to get rid of is code, that detects unit config prefix based on category we're located at. For example it's used during mod-rewrite url parsing. Because of this detection we can't really place items from different modules into a same category and create direct links to them.

[Dmitry A.]

Okay, if you are saying Module Category Root is not helping us - I say we remove it.

Let's create a task for 5.3.0 (icebox) then.

DA

[Alexander Obuhovich]

Here is a task: http://tracker.in-portal.org/view.php?id=1368