Why Components AND Modules ? (Instead of just Modules.)

[jalil]

Right, so on to the questions now....why do we need a Component ?

Why is it that a component can do that a module cannot ?

Observing from outside, Joomla's structure is rather complicated. I can understand given the history of Joomla, but when 1.5 came out and this structure is still used, i got worried.

*Lots* of people get confused betwee modules and components, and one need to be *educated* abut it, meaning it isn't intuitive. There is something wrong there.

My question is this. Things can be done with one component, which is the joomla control center component if you like, and with ALL the rest being done by modules. The plug ins are quite alright as they can be use for minor adjustments to each module, (though the bots are now quite independed without a mother.)

So a simple structure like the one below would suffice...no ?

Joomla Control Component ( or Frontpage Component )

:::    Module A | Module B | Module C | Module D| Module E | Modules F |
.............|...............|
Module A Plugins......|
Module A Plugins......|
.............................|
..................Module B Plugins
..................Module B Plugins

If it can be done this way, joomla i can explain to a newbie that joomla has a modular structure using modules, and has plugins.
As joomla get a bigger and wider usage, it's complicated structure may not be advantages at all.

Now i'm forced to say to the newbie Joomla user that Joomla has components/modules/mambot/plugins. and you have to learn all that.

Can i rework my joomla completely ?

[bascherz]

Components, modules, and plug-ins (which replace mambots in J!1.5) are unique in what each does.

A content plug-in, for instance, essentially gets called by the core code when articles are displayed and has the opportunity to search for special text strings processed specifically by that plug-in and replace them with other text. For example, a plugin might process the string {avatar} and insert the avatar uploaded or selected by a user on a site equipped with Community Builder or replace {video=path-to-video} with streamed video content. An editor plug-in can completely define or extend an existing content text editor (e.g., JCE).

A module is simply something that can be inserted into your site template and appear on your pages. Modules can be instantiated, often multiple times each, and each instance can be placed at a specific position on the page. Positions can be made to appear only when certain menu items are selected. Some example modules are login, online users, visit counter, and Newsflash.

The admin interface for modules and plug-ins is completely coded in XML, so there is no dynamic element to it and no real way to customize the look and feel of the parameter input part.

A component is the most elaborate and complex type of J! extension. It can have both front end (user) and back end (admin) capabilities, and can be made to do many different things. Components can have one or more ways to have capabilities inserted as items in site menus, and the admin interface can be as elaborate as the author chooses it to be. Some examples include photo galleries, discussion forums, and guest books.

Rules of thumb:

Modules - data already exists and you just want a new way to present it on your site
Plug-ins - data, content, or custom functions replace information in articles or functions extend core features
Components - add custom functions to your site that can be selected from menus

[jalil]

Rules of thumb:
Modules - data already exists and you just want a new way to present it on your site
Plug-ins - data, content, or custom functions replace information in articles or functions extend core features
Components - add custom functions to your site that can be selected from menus

thank you. this is good for 101 designers interested in jumping in straight to do joomla! extensions.

my study is into making the joomla design itself it a lot simpler, removing the complexity, and your answer provided a most
valuable insight into how i can do this. i will go away with cup of coffee and hopefully be back with some good news in the near future.

[jalil]

am i right in saying that, for a bot or plugin of a type search for example, that each and every one has to be called by the core component, it order to do a complete site wide search ?

would it be better to enhance the built in search to do that, rather than to make it necessary for each developer to make their own search function ?

i think this is core 'duty' hence the search function has to be encompassing. this would allow developers to just develop and not worry about search function or about users searches not including their particular extension database.

what do you think ?

[bascherz]

I believe a plug-in can also be an extension of the core search function. I have seen a number of search extensions for Joomla, but I don't know if they all search content in the database. For example, a Google-type search would try to expand and spider the entire site and search the rendered HTML. A search bot that could automatically adapt to search all database tables whose names begin with "jos_" (or whatever the chosen prefix is) would be an interesting project, particularly since some content isn't necessarily published and some might be archived (and thus inaccessible via the site front end).

I think the built-in Joomla search function searches only the meta data entered for articles and perhaps the article text itself. After all, that's really the only content Joomla proper manages. Other content is managed by extensions. What would seem to make sense (and is probably what you are trying to describe) is to define an API for the Joomla core search function to call agent functions within extensions that want to be searchable. Now THAT would be an interesting project, but IMHO well beyond what this particular group could tackle. It would really be a project for the core team if it doesn't already exist. I have not looked into it. This could work much the same way as a Community Builder (CB) event handler (something I DO have experience with), wherein the extension registers with the CB core code and is called when the registered CB event occurs. CB passes all relevant information to the handler in an object. There is a good example of this technique on joomlander.net in the CB Profile Notifier Plug-in.

[jlleblanc]

I think the built-in Joomla search function searches only the meta data entered for articles and perhaps the article text itself. After all, that's really the only content Joomla proper manages. Other content is managed by extensions. What would seem to make sense (and is probably what you are trying to describe) is to define an API for the Joomla core search function to call agent functions within extensions that want to be searchable. Now THAT would be an interesting project, but IMHO well beyond what this particular group could tackle. It would really be a project for the core team if it doesn't already exist. I have not looked into it. This could work much the same way as a Community Builder (CB) event handler (something I DO have experience with), wherein the extension registers with the CB core code and is called when the registered CB event occurs. CB passes all relevant information to the handler in an object. There is a good example of this technique on joomlander.net in the CB Profile Notifier Plug-in.

Joomla! already has this through search plugins. You create a search plugin to go along with your component and you define what gets returned in the results when a search is performed.

[bascherz]

Well, there ya go then. Perfect. Thanks.

[jalil]

Joomla! already has this through search plugins. You create a search plugin to go along with your component and you define what gets returned in the results when a search is performed.

hi and thanks..

the reason i ask i that i don't want to have to create a search plug in to go with my component/module and is what i meant as core 'duty', not necessaily in the core itself, but the core search function calls on this 'global search' function to perform its search and display results.

this global search function does a sitewide database search and indexing so that all articles pertaining to user search and created by whatever extension in joomla is being marked and displayed (or whatever).

kinda like the google sitewide search described by #bascherz above, but not google. joomla!'s own.
the present system is fine. i'm just only too lazy to have to make my own search functions and to remind my users not 'not forget to upload the search bot'. i think it's a simple solution, most useful to the extension writers.

what's your opinion on this ?

also, coming back to the topic, i understand the differece betwen components and modules, but can't they be merged to become one ?
then call it just component or just module ?.

the present system can co-exist, but in future one would write say just components and plug ins.
this cuts down the thought process into two, instead of three and make it slightly lighter on the head if you know what i mean.



pleased to meet you btw, your tutorials are very popular!

[jlleblanc]

Joomla! already has this through search plugins. You create a search plugin to go along with your component and you define what gets returned in the results when a search is performed.

hi and thanks..

the reason i ask i that i don't want to have to create a search plug in to go with my component/module and is what i meant as core 'duty', not necessaily in the core itself, but the core search function calls on this 'global search' function to perform its search and display results.

this global search function does a sitewide database search and indexing so that all articles pertaining to user search and created by whatever extension in joomla is being marked and displayed (or whatever).

kinda like the google sitewide search described by #bascherz above, but not google. joomla!'s own.
the present system is fine. i'm just only too lazy to have to make my own search functions and to remind my users not 'not forget to upload the search bot'. i think it's a simple solution, most useful to the extension writers.

what's your opinion on this ?

The bigger issue is that many of the more useful Joomla! projects out there tend to use more than one type of extension (such as the Podcast Suite, which uses a component, module, and plugin). There has been efforts in the past to make it possible for developers to bundle multiple extensions within one file, but this hasn't been explored recently, IIRC.

As for just adding a search function to your component and having the core search component find it (am I understanding your desire correctly here?), this might not be a bad idea, but not having it isn't a deal breaker IMO. You might want to bring this up to the core team for consideration.

also, coming back to the topic, i understand the differece betwen components and modules, but can't they be merged to become one ?
then call it just component or just module ?.

the present system can co-exist, but in future one would write say just components and plug ins.
this cuts down the thought process into two, instead of three and make it slightly lighter on the head if you know what i mean.

Every CMS I've run across has this concept of "blocks" (which we call modules) that are separate from the "main part" of the page. I think that merging them up could potentially cause more confusion.

pleased to meet you btw, your tutorials are very popular!

And you as well

[jalil]

The bigger issue is that many of the more useful Joomla! projects out there tend to use more than one type of extension (such as the Podcast Suite, which uses a component, module, and plugin). There has been efforts in the past to make it possible for developers to bundle multiple extensions within one file, but this hasn't been explored recently, IIRC.

As for just adding a search function to your component and having the core search component find it (am I understanding your desire correctly here?), this might not be a bad idea, but not having it isn't a deal breaker IMO. You might want to bring this up to the core team for consideration.

ok, you didn't actually quite get my point, but it isn't a vital point, merely a convenience.
what i'm saying is that if there is an extensive search module, there is no need for multiple search bots. but never mind, it isn't a big deal.
certainly not worth taking up with the core team, as solutions can be made outside of the core to extend the core functionality.
should the core team decide to incorporate this later on, it is up to them, no urgency here.

Every CMS I've run across has this concept of "blocks" (which we call modules) that are separate from the "main part" of the page. I think that merging them up could potentially cause more confusion.

True, it is desirable to do so. That isn't what i'm on about.
The components can be the blocks. And there can be plug ins for the component.
This Joomla! has three levels of blocks, which is good for some things, but bad for other things, as usual in any design.
The design is fine as it is, i was just looking to simplify it.

Lets leave it at that, i'm quite satisfied with the answers thus far. I'll go look deeper into Joomla.
Maybe make a simple lame clock module

Thanks Much.

[bascherz]

Wouldn't it be easier to just expand the XML schema for the installer so that you could have one XML file install more than one type of extension at a time? That is, why not have a package installer syntax that could install one or more components, modules, and plug-ins during a single admin-initiated installation? The extensions themselves could remain separate entities this way.

[jlleblanc]

Wouldn't it be easier to just expand the XML schema for the installer so that you could have one XML file install more than one type of extension at a time? That is, why not have a package installer syntax that could install one or more components, modules, and plug-ins during a single admin-initiated installation? The extensions themselves could remain separate entities this way.

Yeah, that's the idea, it just hasn't been implemented.

[jalil]

Wouldn't it be easier to just expand the XML schema for the installer so that you could have one XML file install more than one type of extension at a time? That is, why not have a package installer syntax that could install one or more components, modules, and plug-ins during a single admin-initiated installation? The extensions themselves could remain separate entities this way.

true, and i wish to add that it should also install as many extensions as one would like to have and of all types digestable to joomla!.
right now, in a new joomla! install i have to upload 10 times to get my ten popular extensions running.
this is for installation purposes.

my question was more of the architecture of joomla! itself, trying to make it simple as i have problems understanding complex things.

[Rogue4ngel]

There was a discussion in the foundation forum regarding a project to create an installation schema that would allow you to install Joomla with a default set of add-ons select through checkboxes of what you'd like included.

I think we're going to see a lot of things pick up with the final stable release of 1.5

Sorry, getting off topic.

[jalil]

There was a discussion in the foundation forum regarding a project to create an installation schema that would allow you to install Joomla with a default set of add-ons select through checkboxes of what you'd like included.

I think we're going to see a lot of things pick up with the final stable release of 1.5

Sorry, getting off topic.

thats great news, and i now worry about the support for the 1.0.x series.
1.5.x & 1.0.x. It seem these two models will coexist, and if allowed, they would each develop into something new by itself. I hope this is welcomed, and i hope that there isn't any unwritten plan to declare 1.0.x series as obsolete or deprecated. Tha would really be sad.

This is important to coding and learning. And is also off topic, but important nevertheless. heh.

[Chris Davenport]

There will be no changes to functionality in Joomla! 1.5 as it is being driven by Q&T and not the developers.  In other words, the only changes being made to 1.5 are bug fixes which are required to get the code to its stable state.  No features will be added.  When development starts on 1.6 that is the time for new features to come in.  The plan is that 1.6 will happen a lot faster than 1.5 since the major refactoring of the Framework has now been done.

We expect to continue support for the 1.0.x series for 1 year following 1.5 going Stable.

Regards,
Chris.

[jalil]

We expect to continue support for the 1.0.x series for 1 year following 1.5 going Stable.

is the RC1 considered stable ?
and after the 1 year, what would happen to 1.0.x users who do not want to upgrade...they have to seek their own support ?

anyway, back to the topic, i have finally understood the design of Joomla!, and noticed that components and articles are the only part of the framework that is connected to a menu system.
modules and mambots have no menu. and this is by design. hence if i were to write a module, and want to users to have a menu pointed to it, i would have to make a component. alternatively, the user can insert the module into an article, and have a menu for that article.

apart from this reason, i don't see why a module could not function as a component.
another thing i observed is that one cannot unpublish a component ( no switch ) and hence the component itself needs a switch, as was done by some developers. since a component is linkable by a menu, one can just not publish the menu, or not have he menu at all to ignore the component. this however would not work for active components, though i do not know of any or heard of any active component in joomla as yet.

also, i have entirely ignored plugins, as they can exist alone or attached to a component, or to a module, and can thus behave like anything it wants. it hasn't got a display channel, but can always call upon a module or a component for that.

all in all, there is plenty of room to make joomla plenty exiciting as it is. so i'm in for a lot of fun. thanks.

[Chris Davenport]

We expect to continue support for the 1.0.x series for 1 year following 1.5 going Stable.

is the RC1 considered stable ?

Pretty much.  It is in the "stable phase" of the development cycle: http://dev.joomla.org/content/view/39/63/.

To quote from the Development Strategy: http://dev.joomla.org/Joomla!%20Development%20Strategy.v.1.0.pdf

Stable Phase (release candidate)
At this phase code base is considered stable and secure and any final bugs are taken care of as
they come to our attention. It is during this phase of the development cycle that the software is
packaged and released. Most attention goes into promotion and public information.
Control over the code base from the release is delegated from the Development workgroup to
the Quality and Testing workgroup.

A Release Candidate is put out by Q&T when they feel they need it to assist in their efforts to hunt down bugs.  When Q&T are happy with the level of bugs in the tracker then a Stable release will be made.  RC's are a bit like dress rehearsals for that final Stable release.  So we're really, really close now.

and after the 1 year, what would happen to 1.0.x users who do not want to upgrade...they have to seek their own support ?

Depends what you mean by support.  The community will probably continue to provide help and guidance.  But Q&T will stop maintaining the code and putting out maintenance releases.  At the moment 1.0.x is in maintenance mode and the primary driver is security.  If no security flaws of sufficient importance are found in 1.0.13 then there will not be a 1.0.14 and so on.  So releases will be few and far between anyway and will not involve any significant changes in functionality.  According to our development strategy we should be releasing Joomla! 1.8 about the time official support for 1.0.x ceases.    I think that's pretty generous.

also, i have entirely ignored plugins, as they can exist alone or attached to a component, or to a module, and can thus behave like anything it wants. it hasn't got a display channel, but can always call upon a module or a component for that.

It's probably best not to think of plugins as being attached to components, for example.  Plugins are attached to events.  When an event is triggered all the plugins attached to that event are called.  There are different categories of events in the Framework and plugins that attach to those events can be thought of as extending the Framework itself.  However it is also possible for a component or a module to define a new event and have plugins attached to that event.  When the component code raises that event then all the plugins attached to the event are called.  This is probably less common than Framework-level event plugins.  You can read more about plugins here: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,tutorials:plugins/

Hope this helps.

Chris.

[jalil]

It's probably best not to think of plugins as being attached to components, for example.  Plugins are attached to events.  When an event is triggered all the plugins attached to that event are called. 

thanks for correcting me on this, it is a very important point i missed. this means plugins can respond to any event, triggered by any component, module or even another plugin ( event chaining ).

and thanks for clarifying the release policies of joomla. i think i am quite clear of this joomla jungle. its not too big a jungle fortunately.

[ianmac]

It's probably best not to think of plugins as being attached to components, for example.  Plugins are attached to events.  When an event is triggered all the plugins attached to that event are called.  There are different categories of events in the Framework and plugins that attach to those events can be thought of as extending the Framework itself.  However it is also possible for a component or a module to define a new event and have plugins attached to that event.  When the component code raises that event then all the plugins attached to the event are called.  This is probably less common than Framework-level event plugins.  You can read more about plugins here: http://dev.joomla.org/component/option, ... s:plugins/

Although some previously framework level events have been moved to component level events.  The best example of this is the content group.  The content system is making a bit of a transition from being tightly integrated into the core of the system to becoming a component that is interchangeable.  Thus, content plugins are not loaded until the com_content component invokes the command to load them, and then the content component triggers its events at the appropriate times.

As we go into the future, components could define their own plugin groups (and would get their own directories), and can define their own events, in the same way the com_content component does.

Ian

[jalil]

Although some previously framework level events have been moved to component level events.  The best example of this is the content group.  The content system is making a bit of a transition from being tightly integrated into the core of the system to becoming a component that is interchangeable.  Thus, content plugins are not loaded until the com_content component invokes the command to load them, and then the content component triggers its events at the appropriate times.

As we go into the future, components could define their own plugin groups (and would get their own directories), and can define their own events, in the same way the com_content component does.

Ian

making room for a generic management system rather than just content management system. absolutely brilliant.

[bascherz]

I just stumbled upon the following summary explaining the differences between the various types of Joomla! extensions.

http://dev.joomla.org/content/view/45/

Note that there is a reference to Joomla! version 1.1, which of course now is version 1.5.

[Chris Davenport]

Note that there is a reference to Joomla! version 1.1, which of course now is version 1.5.

Fixed.  Thanks for reporting it.

Chris.