1
mercibe
Module Development Framework suggestions
  • 2004/2/26 21:01

  • mercibe

  • Just popping in

  • Posts: 55

  • Since: 2003/6/12


Today there are a lot of great modules for Xoops2. Overall quality may vary from one to another, but they all solve reallife problems pretty well. The XOOPS core modules and classes are well designed and deserve recognition.

When a module developer starts coding, he has little documentation on how to develop his module and what are the best way to access the database, manage user permissions, store files, use notification system,... So he often starts from an existing module "similar" to the one he wants to develop. This is a good way to propagate best practices but also the worst ones...

Beside the propagation problem mentionned above, a lot of modules are doing identical things in different ways (file storage, image management, etc.). This is a huge waste of time for module developers and an error prone process. Furthermore it prevents the development of common behaviors between different modules or any kind of loose-coupled interoperability between modules.

In order to bring XOOPS to the next step, lets say the enterprise one, XOOPS needs a strong module development framework that will allow the construction of robust, extensible and interoperable modules. This implies at least 3 things:

- fully document the current core XOOPS framework
- identify common core module components
- develop, document and promote these new additions

I think the current organisation of the XOOPS team is perfect for supporting this. The Core or module team for development, the Documentation team for documenting the framework classes and the Quality Control team could ensure that new modules are "Xoops standard compliant".

IMHO, here are the most important things that the module developement framework should deal with.

1. Authentication
2. File management
3. Database abstraction
4. Simple Workflow engine

A new "team workspace" module could be developed in parallel to test and implement the framework under construction.

1. Database abstraction layer

Even if MySQL is and should stay the default database for Xoops, a database abstraction layer might be useful. The small performance cost of adding this abstraction layer ("never write a SQL statement anymore") should be nothing compared to potential architectural advantages. What about if MySQL guys introduce new way of writing queries, optimizing it or improving search mechanisms ? Let's the XOOPS user decide the database he wants to use. Just implement the MySQL classes. What about fulltext search in MySQL that is almost unique ? The interface should provide a search method. MySQL implementation will be easy to write and other database implementations will use proprietary mechanisms to achieve the same results. But this is not the XOOPS problem (see pear or ADO)

2. Authentication abstraction layer

The process of authenticating a user should be completely externalized and pluggable. We should be able to select the implementation that best suits our needs. A good way to follow is PAM or JAAS (an implementation of PAM in Java). A chain of loginModules implementation is the core of such a system. We should not have to hack core files anymore to adapt the authentication mechanism...

3. Filsesystem abstraction layer

The framework should provide an abstraction layer to store and retrieve files (either in the hosting filesystem or in the database). Every users and modules should receive a dedicated (private) space through this interface. The access rights should be based on the standard user/group XOOPS security classes. This would allow to build, for instance, common GUI components to store and retrieve files reusable throughout all modules or a Personal Web Folder to store and organise private files. All direct access to the filesystem should be prohibited. This could become the core of a real Document Content Management system: you could add metadata support, indexing, trigger workflows/indexing/process/etc., etc.

4. Simple workflow engine

Every objects have a lifecycle. Lifecycles may be very simple or very complex. They may need to be persisted or are just volatile. Let's imagine: when needed, you define a UML State diagram for your "stateful" object with your favorite tools. You export it to XMI and load it into your XOOPS Workflow engine. Don't forget to tell the engine if you need to persist the object states or not. That's all. You have completely externalize the workflow of your application. When you want to get/set the state of an object just send the approriate event to the Workflow engine... Am I dreaming ? This is already done by some frameworks... This kind of engine could greatly help in building more complex document approval flow (ex. FAQ, news, Articles, etc.) and open a lot of new doors for modules developers. Workflow engine is perhaps the most difficult part of the framework to design but it might be its greatest strongness.

5. OK, I won't talk to you about asynchronous messaging (MoM) ... today !

I am convinced that many things have already been done in the Free and Open Source world to help XOOPS building such a framework in a reasonnable timeframe.

The architecture of an Information System is more important than its source code availability. Even with the source code available some things can be impossible to realize due to a bad initial architecture. A good architecture should ease the participation and collaboration of modules developers. And the XOOPS authors have understood that from the early days. It is time to build a first class developer framework on top of the good core. This framework should also improve data reusibility. New modules and services will follow accordingly. If XOOPS succeed in it, it will really become the best Free CMS based on PHP and will have its place in the enterprise.

Now, let's start the discussion !

Benoit


2
Herko
Re: Module Development Framework suggestions
  • 2004/2/26 22:20

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


We'll get back to you on this. Many of the things you're suggesting are planned already, some even set into motion (as you well know after our talk in Brussels last weekend ) But, they're good and valid points, and I'm glad you shared them with the community!

Herko

3
sudhaker
Re: Module Development Framework suggestions
  • 2004/3/6 23:57

  • sudhaker

  • Not too shy to talk

  • Posts: 117

  • Since: 2003/2/6 2



Thanks mercibe for sharing the stuffs. I can see your vision for Xoops.

XOOPS, The Open Source CMS (Enterprise Edition)

Saw your other posthttps://xoops.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=13171&forum=21

I also faced many problem while trying to use XOOPS for enterprise portal. Mambo can be better choice for that requirement but I like the oops of Xoops, not to mention the cleaner code, greater separation between logic and presentation, caching (thanks Smarty). These factors keeps me bringing back to XOOPS

But hacking XOOPS doen't make me happy By doing that I am making the upgrade complicated.

Apart from mercibe suggestion in other post - I want to see User1 and User2 area in smarty theme.html layout (similar to mambo). This will enable you to make more customized layouts than just Header/Left/Center/Right/Footer layout. IMO, Corporates doesn't like "Nuke" type layout. One reason can be because all sites looks similar

Can I get my XOOPS Enterprise?


4
jurgis
Re: Module Development Framework suggestions
  • 2004/3/12 1:38

  • jurgis

  • Just popping in

  • Posts: 72

  • Since: 2003/3/20


well U can use LCenter and RCenter columns for user1 and user2 - with some imagination U can make an original look .

as with architecture importance - I strongly agree.
still I am not a big expert and try to think practically:
first I would really appreciate to see some xoos UML, like I wrote here

5
ouioui
4. Simple workflow engine
  • 2004/6/23 7:18

  • ouioui

  • Just popping in

  • Posts: 32

  • Since: 2003/7/11


Hi,

I'm really interrest in a workflow engine based on PHP. Worflow have 3 parts : Data, User, Processus.
Xoops is a serious candidat :
- the user group management is well design
- the data access use a class modele where a interface could be used.

But for the processus i'm not really agree with you when you write : "You export it to XMI and load it into your XOOPS Workflow engine". Today there no standard for the modeling of executable business processes but BPML/BPEL4WS will be best candidat. XMI is realy complex and too rich.

A structured idea is to used web service. Web Services is becoming increasingly popular for use as the integration infrastructure.

Best regard
Bruno


6
melkahdor
Re: 4. Simple workflow engine
  • 2004/9/27 17:53

  • melkahdor

  • Just popping in

  • Posts: 10

  • Since: 2002/5/31


Hi all,

It's a great idea, but what's wrong at this time is the existing "foundations" to develop, test & debug , maintain packages.

Using XOOPS on LAMP don't cost anything, except time, work & passion. But on other systems, it will be difficult to do : licenses, matertials. If entreprises had interest to develop sommes xoops'features, they should help, <sponsoring> developpers with sommes servers, licenses, broadband.....

I'm not member of the team, but I know how it's difficult to say "no" for a developer when the idea is good, but not the tools to build it...

(please excuse me all if i make many mistakes in my enlish, I hope you understand my ideas...)

Login

Who's Online

155 user(s) are online (76 user(s) are browsing Support Forums)


Members: 0


Guests: 155


more...

Donat-O-Meter

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

Latest GitHub Commits