1
GadgetMn
Concept: Sub-Modules
  • 2004/1/15 21:54

  • GadgetMn

  • Just popping in

  • Posts: 55

  • Since: 2003/7/15


I was intrigued when I used the related contents module. Here is a module that apart from a block has no actual usable application. It is a supporting module.

This then got me thinking about how to extend other modules without forking them. That's where sub-modules come in. The idea is to create a module that interfaces with an existing module and extends its capabilities through new blocks or additional sub-menu options.

This would obviously serve better as a core feature and could be published as part of the module API - allowing cross module communication.

Would this be something others would be interested in?

GadgetMn

2
carnuke
Re: Concept: Sub-Modules
  • 2004/1/15 22:14

  • carnuke

  • Home away from home

  • Posts: 1955

  • Since: 2003/11/5


Modules that reprocess data from other modules, building modifying or generating higher levels of content etc. Yes, there already are some modules that do this. You already mentioned related contents. 'Bopcomments' is another module that collates recent events from various other modules and displays a summary of site activity. can you think of other applications along these lines?

Richard

3
GadgetMn
Re: Concept: Sub-Modules
  • 2004/1/15 22:23

  • GadgetMn

  • Just popping in

  • Posts: 55

  • Since: 2003/7/15


The reason for raising this is because a friend of mine wants to develop a booking system that can manage a varying range of "events" from resource scheduling to advertising space. What he needs at the core is a well developed calendar and there are already a few out there.

Now if you could develop away of extending a modules capability without modifying the core of that module you could extend modules (and Xoops) far beyond where they are today. I believe this would be inheritence in troe oops terms

It would be better if there was a documented API that would allow modules to talk to each other which developers would either choose to respond to or not...

GadgetMn

4
Mithrandir
Re: Concept: Sub-Modules

We in the modules dev team are talking about a kind of a "plugin" structure of modules, which would make e.g. the waiting contest block automatically list waiting news/downloads etc.

The same could be the case for the other way around, where a "trigger"-function in e.g. Agenda-X allowed for other modules to insert data into the calendar by using this function.

I'm thinking a line like this
include '../agendax/plugin/functions.php';
addEvent($date$subject$poster, ..., ... ,..);


or maybe
xoops_plugin_function('agendax_addevent'$date$subject$poster);
where the xoops_plugin_function() could check if the agendax_addevent() function was installed and if it was, it would run with the added parameters. That way, we could perhaps have the plugin functions specified in the xoops_version.php with a
$modversion['plugin']['name'] = 'functionname';
$modversion['plugin']['file'] = 'filename';


Integrating too many things in the core is something XOOPS is going away from, only adding things, which are REALLY basic - like user management, permissions, mailer, smarty, form classes - that kind of thing.

5
Mithrandir
Re: Concept: Sub-Modules

Would also be useful for automatically creating a forum thread when adding news Would love that

6
GadgetMn
Re: Concept: Sub-Modules
  • 2004/1/17 8:48

  • GadgetMn

  • Just popping in

  • Posts: 55

  • Since: 2003/7/15


Quote:

Mithrandir wrote:
Integrating too many things in the core is something XOOPS is going away from, only adding things, which are REALLY basic - like user management, permissions, mailer, smarty, form classes - that kind of thing.


I totally agree. A rock solid core with everything else being modularised. I even think you should break out the System Admin module in to seperate "System Modules".

There are instances where I would like to tie the user administration in to the O/S user management or an LDAP system so I can provide integrated web mail for example.

There are also 101 different ways of managing content and e-mailing users. By having a system module layer, these could be replaced as long as they support the system API calls.

All modules would retreive data/information via defined triggers from the module.

$modversion['trigger']['name'] = 'functionname';
$modversion['trigger']['file'] = 'filename';


Or via a class definition if that's more efficient.

It would be down to the developer of the replacement module to encapsulate that call. It would have made SPAW integration easier for all modules or replace content management completely with a true CMS with content types, workflow, etc.

Cheers,

GadgetMn

7
stefan88
Re: Concept: Sub-Modules
  • 2006/11/22 12:13

  • stefan88

  • Community Support Member

  • Posts: 1086

  • Since: 2004/9/20


A great idea found in January 2004 post ...

Is it a future in 2006 xoops?
..

8
Herko
Re: Concept: Sub-Modules
  • 2006/11/22 12:16

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


it is always a future

But yes, 2.3 will incorporate module 'hooks'. There's some posts about this on the sf.net developers forum.

Good to see tho that the module I had developed by Bunny for XOOPS 2.0.3 at the time, was considered usefull

Herko

Login

Who's Online

236 user(s) are online (172 user(s) are browsing Support Forums)


Members: 0


Guests: 236


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits