Helma - Javascript Web Application Framework: Application Modules

Application Modules

DEPRECATED - see Repository Interface Implementation

Lets skip the advantages and what modules should provide, straight to the facts and what is already done.

What we already have:

homeDir/apps
homeDir/logs
...

Modules are stored in subdirectories of homeDir/modules. The name of the subdirectory is the name of the module.

homeDir/modules/modpdf
homeDir/modules/telnet

Well, how to activate these modules?

app.properties:

modules.order = modpdf,telnet
modules.load = first

The load property is to define if module code should overwrite application code or vice versa. Therefore first means that all modules are loaded first, then the application code which overwrites module code. The opposite is obviously last.

app.properties:

modules.order = telnet,modpdf
modules.load = first

Modules itself are loaded in the order they are specified in the app.properties file.

The above example tells the application first of all to load its own code, then extend (possible overwrite functions / actions / etc.) it with telnet's code and finally extend it with modpdf's code.

What can be overridden? Well, it should be possibly to ovveride / extend everything like above, action files, function files, type.properties files and so on.

By the way, you do need to restart an application to activate changed settings in your app.properties files concerning modules.

Little disclaimer (-;
type.properties, function and action files are tested and **do** work, but I didn't test skin and template files so far...

ZIP files do work as before.

Attached is a current patch (diff files for 3 classes, 1 new class and the diffing source files as well for testing simplicity).
[HopMacro error in file: java.lang.RuntimeException: Error retrieving Node: java.sql.SQLException: General error message from server: "Can't open file: 'AV_FILE.MYI' (errno: 145)"]

Up: Requests For Comments (RFCs)
Previous: Logging interface (2nd run)	Next: Repository Interface Implementation

... comment

Page last modified on 2004-09-02 21:15 by daniel

stefanp, Thursday, 8. January 2004, 23:16

An objection: Why does homeDir/modules have to be a fixed directory? Nearly every file location in Helma can be configured. I'd rather propose a solution like the cron-config in app.properties:
module.MODULENAME.location = /usr/local/helmalibs/XXXX
module.MODULENAME.final = ...

This would solve several problems:

I'm strongly against using global modules for the whole server. It's enough nuisance updating the snapshot of a helma installation that runs several applications maintained by different people. According to your proposal this would extend to updating one of the global libraries.

A second problem is that in the proposal the load-before/after option can only be configured for all modules used in an application - which is unnecessary in that it restricts us to using only one type of module within an application.

Even if the proposal is ok intuitive in that concern I don't like the options "first"/"last" as values of the "load" property. As it is just a switch I'd prefer naming the property in a way that the options are only "true"/"false", e.g. "module.XX.final = true" (to stick to java conventions) or module.XXX.loadAsBase or something like that.

A minor thing: changed module settings should be activated immediately - this is not the most pressing issue and you probably meant it more as a notice than as an actual proposal. But I just want to make sure that it's helma policy to have things configurable on the fly wherever possible.

lg,
Stefan

... link

daniel, Monday, 12. January 2004, 19:25

will try...

right now I am trying to implement something really cool and innovative using all your comments and feedbacks. I will try to post some results something within this week...