Last post we looked into all of the folders for config files, and we found the script that describes where the Jaxer process should look for initialization. Today we dive into the ironically described framework folder. Ironic might not be the right term as the server-side framework is indeed located in the framework folder, but the framework folder also contains the configuration files that describes on each Jaxer process is supposed to run, and then the actual framework is stashed away in the src folder.

In terms of organization it would make more sense for the configuration files to be in the confs folder, and then for the framework source to be directly in the framework folder. Maybe we can address that level of organization once we have a better idea of how the files arranged and come up with an approach for how we want the files to sorted. For now we’ll look directly at the files are now and make a note of what each one does.

JSLib.js 
api_sdoc.js
clientFramework.js
config.js 
configApps.js 
configLog.js
serverFramework.js

The above listed seven files are the Javascript files directly stored in the framework folder. We’ll go through and try to make notes of what each one does, and make a side note of if it makes sense to be there or not.

jsLib.js
First file is jsLib.js which looks like it’s a file that the defines the namespace for working with xpcom. This definitely looks like a required file, but it might make more sense to pop this over into the components directory since it kind of fits into the category of aptEventHandler.js that provides some of the base functionality of the Jaxer process. So we might need to track down where this file is referenced so we can move it there.

api_sdoc.js
Next file is api_sdoc.js and this file looks like it sets up the namespace for modules that will later be populated once the server framework is loaded. This is a pretty wonky file and it’s hard to think of how to treat it, so I guess I’ll leave it alone for now. The only thing that sticks out about this file is that it seems to have a lot of checking if Jaxer is on the server or on the client. We’ve separated the two frameworks so all the client framework does is call the server framework. So the server framework should always assuming Jaxer.isOnServer equates to true. Tempted to also move this to the components folder.

clientframework.js
This one is easy, it’s the client framework that gets loaded into the page when Jaxer serves a page that is marked with a script that is set to run at server proxy. We’ve completely re-written this framework to only make XMLHttpRequests to the Jaxer process on the server. The only consideration is if this file needs to be included in the framework folder. And while it is technically framework, it’s more of a static file that gets included as an alias. So it might make more sense to put this file in the content folder to keep it separate from the server framework.

config.js
We finally get to config.js. There are two obvious points about config.js that stand out. The first point being that to cut down on the file size we should probably remove some of the disabled options. And the second point is that this file should really be in the confs folder. It looks like this file has the reference to jsLib.js, so we might put that files in the confs folder as well.

configApps.js
Next we come to configApps.js which is an functionality that is pretty unique to Jaxer. The idea behind it was a single Jaxer instance could host multiple ‘Apps’. Since this is pre-Apple AppStore, what they meant by App is that you could basically set a different database path, or define global functions in a given application based on the url being requested.

So for instance if you had a web-application running at my-awesome-service.com. You could define a different ‘App’ for admin.my-awesome-service.com , or client.my-awesome-service.com. Or even as a leaf with my-awesome-service.com/admin/ or my-awesome-service.com/client/.

In general this seems like something that is good in theory, but not necessarily in practice. Since it’s pretty easy to set up Linux servers, it seems a lot easier to host one application per instance. And if you do need to include functionality like changing databases, or defining different utility scripts, these can be included with run-at server scripts. So while it’s not the issue for deciding if this functionality needs to stay or go, but I think it makes more sense to remove this functionality if given the chance to further simplify.

configLog.js
This is a short file that only includes the following lines.

(function() {
	
	Log.minLevelForStackTrace = Log.ERROR;
	
	Log.setAllModuleLevels(Log.INFO);
	
	Log.CLIENT_SIDE_CONSOLE_SUPPORT = false;
			
})();

Not sure if this is useful or not. But we can leave it in for now and move the file to the confs folder.

serverFramework.js
Last we come to the poorly named serverFramework.js, as this file is not the server framework, but the file for loading the server framework. The file includes the following lines for each of the server framework source files:

	coreTraceMethods.TRACE('Loading fragment: Utilities.js');
	Jaxer.lastLoadedFragment = 'Utilities.js';
	include('resource:///framework/src/Utilities.js')

Which means that if we move all of the framework/src/*.js into framework/*.js then we can change the include arguments for all of these files. And remove the scripts for any of the server-side framework scripts that we’re able to remove.

Summary

So in summary it looks like we can or maybe should move all of the framework/*.js files into the confs directory as that seems like a better place to keep them. And then we can move all of the framework files into the framework folder. I don’t know if that would make too much sense or not. So right now it looks like there might not be too much change. As mostly it looks like we need to change components/aptEventHandler.js to look into confs instead of framework for the config files. And then change serverFramework.js to load from framework/ directly instead of framework/src. And then I think that would round out the most of the obvious file-organization for the /etc/emrajs directory. And from there we could get into looking at what can can be done to simply the server framework.