Component clone
I would ask here for any ideas of reusing one and the same component many times on a web site. It can be done for the modules, but as one component has one and the same tables, this is not very useful there.
What is the question?
Imagine a extension with dozens of classes and functions that are called by it or by its modules, so renaming the extension and its tables to have a second copy of it is not exactly what I am looking for as if all classes and functions are renamed this will make future upgrades quite hard.
What are you doing, when wanting to use the same component twice (but with different purpose)?
Views: 100
-
Comment by Klas on March 10, 2010 at 3:58am -
Depends on what would you like to do - using the same component in different way is normally a matter of creating another menu with different parameters and / or linking to different categories (e.g. in photogallery).
Otherwise inability to create component instances is one of the major Joomla architectural flaws. IMHO modules and components should be unified in something that would take the best of both worlds (instances + full MVC)
-
Comment by Ivo Apostolov on March 10, 2010 at 4:02am -
Lets say it that way, an extension like SOBI2 or Mosets Tree - what is necessary is two instances, as the custom fields, templates and generally everything should be in very different way in the two sections, also both should have different advanced search views etc.
So each section is possible to be built with any of these two extensions, however the issue is that I want to use only one of them twice, that is the problem there.
-
Comment by Ewout Wierda on March 10, 2010 at 5:13am -
Can't you make different content types for different sections with a CCK? Or perhaps you can make a main site with two sub-sites put into a wrapper on the main site?
-
Comment by Ivo Apostolov on March 10, 2010 at 5:16am
-
1. Neither SOBI2 or Mosets Tree offer different content types.
2. Other options (jseblod, flexicontent) are unacceptable as these use com_content.
3. K2 does not have advanced search and is used for other stuff on the same site, so it can not be considered.
4. Main site with two sub-sites in wrapper is not an option as that way there will be need for accounts in each site and the global search will not be able to find items in the subsites.
-
Comment by Klas on March 10, 2010 at 6:04am
-
@Ivo: it would be interesting to hear why you think that using com_content in CCK is unacceptable ?
Otherwise creating component duplicate with different folder,name and tables might be your only option in current J architecture - you don't need to rename classes/functions. Not too hard with search & replace...
-
Comment by Ivo Apostolov on March 10, 2010 at 6:09am
-
As I mentioned before in other thread:
1. Upgrading Joomla! may affect these extensions. Remember the escaping of the author name? It caused all authorlink types of plugins to not function. So if in J1.5.16 something is changed, all these CCKs might stop function. And my experience says it is quite probable to happen.
2. What if I want custom content types without the main text? Or without the option to have readmore? These can not be disabled in the Joomla! content.
About the classes and functions - it is necessary as component1 module (which appears on the pages of component2) calls the same classes and functions and basically it gives a PHP error.
-
Comment by Klas on March 10, 2010 at 6:35am
-
You should actually look into those 2 extensions sometimes :) It works ok, with text, without text, readmore or not. Content field of com_content is one thing that is least likely to change in Joomla - JSeblod uses text codes in exactly the same way as other content plugins. So until plugins work, JSeblod will work too. In my view it is much wiser decision than K2's, which is replacing com_content instead of extending it - this means that any content plugin must be redone to work with k2. E.g. with JSeblod you can insert CCKfields where you use editor inside any component and so one - there are numerous advantages - basicaly it is much, much more flexible. Only real disadvantage is little performance drop - at the end it all depends on what you need.
-
Comment by Ivo Apostolov on March 10, 2010 at 6:46am
-
Klas, I have looked at both seblod and flexi. I don't like them, both are end user unfriendly and bring the com_content dogma. For the people I pay to enter the content these are absolute mess and user unfriendly. With K2 it is much easier within its scope.
But it is not the idea here. I am researching for an easy way to clone a component, without making future updates much pain (there will be some, I know). Now it doesn't matter if it is a cck type of extension or it is any other type.
-
Comment by Klas on March 10, 2010 at 7:22am
-
Would be happy if anyone proves me wrong, but I'm afraid that there is no easy way..
-
Comment by Paul Delbar on March 10, 2010 at 7:29am -
There is a way if you use a meta-component which is developed to work with a number of content types in a generic way. This is why we have built one|content - to avoid coding components altogether, because custom coding components is usually overkill for relatively simple content navigation purposes, such as product to manufacturer to other product to category to promotion to user review ... else, you're stuck with building / finding a component which takes its database table name from a menu item parameter or from an URL parameter.
So IMO, do not clone - because you will clone N times for N types of content. In addition, you need to find a way to manage relationships between content types (cf. above).
© 2012 Created by Amy Stephen.
You need to be a member of All Together, As A Whole to add comments!
Join All Together, As A Whole