Crazy / Dumb Feature Request?

Hi Thyon,

I thought of something that I just wanted to get your thoughts on before clogging your feature request system with ridiculous ideas (I'd rather clog your message board with those :)). It seems like a cool idea, but my gut says there are a 100 reasons that make this impossible/unfeasible/stupid/etc. that I am just unaware of.

As I read others forum posts, I notice people use the Catalog for more and more diverse and interesting things as time goes on and more features are added. It seems like it's not just a method for creating databases of items anymore -- it's really evolving into a method for delivering ANY type of template-driven content -- in essence catalogs are being used as a way to create custom backend modules without having to write code.

So I was wondering if it was possible to take this one step further -- what if, when you defined a catalog, you had the option (a checkbox that was obviously off by default) to show that catalog as a backend module -- in essence making it appear in the left column of the backend navigation -- where other custom modules reside when installed.

How I would envision something like this working is -- in addition to the checkbox, you'd have a text field to create the label that appears in the navigation, and finally another checkbox for "single-instance mode" -- so if you wanted your "module" to act as a single page of custom settings, rather than a listing of multiple records, you'd have the option to. When checked, clicking the catalog or "module" would take you directly to the single record.

Then, in user groups, where you already have the options to define access to catalogs, you would have an additional set of permissions that define what catalog "modules" appear to what users (not sure if this can be worked in to the regular module access settings). So you could uncheck a catalog but tick it as a module, in which case the catalog is hidden in the real "catalog" module, but still appears as its own "module".

The main benefit I would see is usability/simplicity for the client or end user. Most of the time going to the catalog first makes sense in context. But -- like others who are adapting the catalog for their needs -- I'm completing a project now for a client that uses the catalog module to update rainout status for baseball fields, list/manage a board of directors, and update baseball teams' league standings -- three completely unrelated applications that are still perfectly suited for the Catalog.

From the point-of-view of the user with no knowledge of the inner workings of the system -- who sees "articles, news, events, etc." all separate and top-level, to have other site areas seemingly arbitrarily grouped under this mysterious "catalog" section is a bit less intuitive FOR THEM (although it makes perfect sense to us). I admit it isn't a huge deal, but it would help simplify things, and greatly heighten the feeling of having a "custom" solution in their minds.

I realize this isn't your original intention for the Catalog, but in my opinion, adding this functionality, if possible, would be an ABSOLUTE GAME CHANGER for designers and developers!!!

Would the core even allow something like this? Is it a crazy idea? Unfeasible? Please bring me back down to earth! :) (I know, I need to pick up some more PHP and learn how to make my own modules -- I get that...)

Thanks for you time -- know you're busy...

Oh dear - NOT CRAZY IDEA - Of course we have thought of this (both s.c.a.r.e. and myself), but it will require a completely new way to write the code, so its starting from scratch.

The basic idea is to make a BE module creator and then a FE Template Field View Editor, to allow you to do exactly that. If I had enough time, I could tackle this project, but I need to keep my energy focussed on my day to day living, so this project does tend to take a back seat.

So yes, your idea has been thought of, in fact I started coding it already at some point. The main problem with it is that you will have to COMPILE your code, as we would need to write out module code to make the various BE modules work. There are tons of checks and balances to ensure that 1 tickbox doesn't end up with an unusable system, therefore for now, wrapping it into a Catalog module is very safe.

Wow! That was fast -- thanks for the response.

As I was afraid of -- there's a lot more to it than I realize -- (i.e. you can't just manually add an item to an array of BE module navigation items that links to a specific catalog, in other words).

There was a little known feature in DC_Catalog.php:

Code:

---

if (preg_match('/^catalog(\d+)$/', $this->Input->get('do'), $matches))
{
    $this->redirect($this->addToUrl('do=catalog&table=tl_catalog_items&id='.$matches[1]));
}

---

It in fact allowed you to create new module in your localconfig.php like this:

Code:

---

$GLOBALS['BE_MOD']['content']['catalog15'] = array
(
    'tables'      => array('tl_catalog_items'),
    'icon'        => 'html/...',
);

---

The important thing here is to use your catalog id (15 in this case) in your new module id $GLOBALS['BE_MOD']['content']['catalog15']

Maybe we could add it to DC_DynamicTable.php too - it is more of a hack, but could do for now.

Couldn't we rather do it using a HOOK, e.g.

We check the new catalog configuration area for a hook setup and then intercept the do= as you have done in the preg_match, but now instead of catalogXXX, we check for the existance of the items in the HOOK array instead. This leaves a bit more flexibility than just catalogXXX. Rest can be the same.

What about the permissions, if they just click on the BE module, won't it just redirect them to the catalog, instead of showing it inside the "module" icon? I'm not sure how the redirect will affect the BE display.

Yes, a hook is much better idea.

I'm not sure about permissions, but checking for permissions can be part of hook processing, if it doesn't work out of box (I don't use permissions at all, so I need to look at it)

Wow, thanks much for taking a look at this -- should I create a feature request for it?

SCARE, I tried your idea by installing the latest version of Extended Catalog on a Fresh TL 2.75 installation. I added the following to my localconfig.php file (my catalog ID in this case was obviously 1, and also I ignored the icon for now):

Code:

---

$GLOBALS['BE_MOD']['content']['catalog1'] = array
(
    'tables'      => array('tl_catalog_items'),
    'icon'        => 'html/...',
);

---

The item appeared in my menu as "catalog1", but when clicked I received the following error message:

Quote:

---

Fatal error: Could not load data container configuration in {sic}/system/drivers/DC_Table.php on line 140

---

You need to add followig lines to system/drivers/DC_DynamicTable.php:

Code:

---

if (preg_match('/^catalog(\d+)$/', $this->Input->get('do'), $matches))
{
    $this->redirect($this->addToUrl('do=catalog&table=tl_catalog_items&id='.$matches[1]));
}

---

add it to start of __construct method.

And yes, please create a feature request for it.

Edit: I now think it is better to put the code to system/modules/catalog/Catalog.php at the beginning of initializeCatalogItems method, as DC_DynamicTable.php is used not only by catalog but others extensions too, so it does not make much sense to put it there.

I need the same feature, but I can't find initializeCatalogItems method inside system/modules/catalog/Catalog.php

Thx for the help

What version do you use? You need version 2.0, downloadable from http://code.google.com/p/typolight-catalog/ - still alpha

Thx!!!!