1.0 Beta - Definition Files

[tmurdock]

Hello,

For the 1.0 Beta version I have been updating qWikiOffice to use definitions for modules, libraries and privileges.

A definition is simply JSON data that defines the particular module, library or privilege. I was thinking to support the ability to have the definitions in files located in a protected directory (definitions/), or in a database table (qo_definitions).

Below are some sample definitions that I am currently using. I am curious for any feedback.

Edit:
Definitions are only meant to be used server side.
The only definition data that is also passed to the client is the privilege data that the member's group has assigned to it. The isAllowedTo() function of the App (App.js) uses it.

A module definition

Code: Select all

{
   "defines": "module",

   "id": "mod-qopreferences",

   "data": {
      "type": "system/preferences",

      "about": {
         "author": "Todd Murdock",
         "description": "Allows users to set and save their desktop preferences",
         "name": "Preferences",
         "url": "www.qwikioffice.com",
         "version": "1.0"
      },

      "dependencies": [
         { "id": "lib-colorpicker" },
         { "id": "lib-explorerview" }
      ],

      "locale": {
         "class": "QoDesk.QoPreferences.Locale",
         "directory": "qwiki/preferences/client/locale/",
         "languages": [ "en" ]
      },

      "client": {
         "class": "QoDesk.QoPreferences",
         "css": [
            {
               "directory": "qwiki/preferences/client/resources/",
               "files": [ "styles.css" ]
            }
         ],
         "javascript": [
            {
               "directory": "qwiki/preferences/client/",
               "files": [ "QoPreferences.js" ]
            },
            {
               "directory": "qwiki/preferences/client/lib/",
               "files": [ "Appearance.js", "AutoRun.js", "Background.js", "Grid.js", "Nav.js", "Quickstart.js", "Shortcuts.js" ]
            }
         ],
         "launcher": {
            "config": {
               "iconCls": "pref-icon",
               "shortcutIconCls": "pref-shortcut-icon",
               "text": "Preferences",
               "tooltip": "<b>Preferences</b><br />Allows you to modify your desktop"
            },
            "paths": {
               "toolmenu": "/"
            }
         }
      },

      "server": {
         "actions": [
            { "id": "saveAppearance", "description": "Allow member to save appearance" },
            { "id": "saveAutorun", "description": "Allow member to save which modules run at start up" },
            { "id": "saveBackground", "description": "Allow member to save a wallpaper as the background" },
            { "id": "saveQuickstart", "description": "Allow member to save which modules appear in the Quick Start panel" },
            { "id": "saveShortcut", "description": "Allow member to save which modules appear as a Shortcut" },
            { "id": "viewThemes", "description": "Allow member to view the available themes" },
            { "id": "viewWallpapers", "description": "Allow member to view the available wallpapers" }
         ],
         "class": "QoPreferences",
         "file": "qwiki/preferences/server/QoPreferences.php"
      }
   }
}


A library definition. A library is a widget, package, etc. that can be shared among modules.

Code: Select all

{
   "defines": "library",

   "id": "lib-colorpicker",

   "data": {
      "dependencies": [
         { "id": "lib-hexfield" }
      ],

      "client": {
         "css": [
            {
              "directory": "color-picker/resources/",
              "files": [ "styles.css" ]
            }
         ],
         "javascript": [
            {
               "directory": "color-picker/",
               "files": [ "Ext.ux.ColorPicker.js" ]
            }
         ]
      }
   }
}


A privilege definition. The data consists of module ids the member has access to load. The module id child items are the server methods that can be called. They can a value of 0 or 1 (meaning disallow or allow).

Code: Select all

{
   "defines": "privilege",

   "id": "prv-demo",

   "description": "Demo member.  Has limited access.  Can not Add, Edit or Delete.",

   "data": {
      "mod-qwikimail": {
         "addMemberFolder": 0,
         "loadMemberFolders": 1
      },
      "mod-qopreferences": {
         "saveAppearance": 0,
         "saveAutorun": 0,
         "saveBackground": 0,
         "saveQuickstart": 0,
         "saveShortcut": 0,
         "viewThemes": 1,
         "viewWallpapers": 1
      },
      "mod-demolayout": 1,
      "mod-demogrid": 1,
      "mod-demobogus": 1,
      "mod-demotabs": 1,
      "mod-demoacc": 1
   }
}


[Relexx]

Todd,

To more this could create more issues that it is solving. On the face of it it is a complex set of files, one character missing and nothing works.

Even if you go with this as a method of definition, you should store it in the DB. Having multiple configuration points will most likely induce confusion amongst developers, especially those who don't read documentation.

Regards

Relexx

[tmurdock]

Todd,

To more this could create more issues that it is solving. On the face of it it is a complex set of files, one character missing and nothing works.

Even if you go with this as a method of definition, you should store it in the DB. Having multiple configuration points will most likely induce confusion amongst developers, especially those who don't read documentation.

Regards

Relexx

I found myself wanting to use definition files/data for 2 reasons.

1. The privilege system used many tables and was confusing for many (plus I found it to be a pain to work with).
2. A definition file (so to speak) is needed anyway in order to do an install of modules, libraries, etc.

Since a definition is needed for the install and it contains any needed data (in easy to encode/decode JSON) for the module, I thought why even bother to break up the data and store it in many tables.

I am leaning toward storage of definition data in the database. For one... it loads faster.

[mjlecomte]

I have lost track of this project a bit. But for whatever it's worth, this smells of tightening the coupling even further. I say smells, because I don't know. As it stands now I believe rewrites are required to use this without a DB, and I read other threads that required some hacks to use it without logging in.

So I'll just throw out the sanity check comment as a reminder if that's the direction you want to go or not. Also recognize that some may want to use a different auth system, so to impose a mandatory privileges system would be further coupling.

[johnz]

Hi Todd,

I think it is a good idea to have definition files for modules and libiraries. This way we could construct a package which contains all the data needed for installation of a module. An installer module could read the data to construct the needed database records.

For the user-definition I think it's not a good idea. Correct me if I'm wrong, but should we update all user-files when a new module is installed? That way a lot of files need to be updated.

Maybe it is a good idea to restrict the privilege system to user-groups. When creating a new user, the administrator can put him in a group. The module-privilege file would contain privilege-data for the group. If the group is not existing, the installer should create it. After that the administrator can add users to the group.

It is possible to generate the user-definition from the database. A PHP script could read out the database and generate the JSON data at login-time.

You might also want to consider a multi-tenancy environment, which is a hot topic at the moment in cloud-systems.

John

[tmurdock]

Hi Todd,
...

Maybe it is a good idea to restrict the privilege system to user-groups. When creating a new user, the administrator can put him in a group. The module-privilege file would contain privilege-data for the group. If the group is not existing, the installer should create it. After that the administrator can add users to the group.

It is possible to generate the user-definition from the database. A PHP script could read out the database and generate the JSON data at login-time.

...
John

The privilege system is group based.

[EthraZa]

I like more the idea of privilege for groups not for users!
And the possibility to choose between file or DB is perfect. If the DB holds the json file, if not I think it can get too much complex to store multidimensional json arrays.

My 2 cents:
In the definition file you are setting 0 for disabled and 1 for enabled, maybe you can think the possibility to extend the idea to a linux file system permission alike, where you have read, write and execute/enter as hex, so 0=disabled, 4=read, 6=+write, 7=+exec/enter, 2=write only, 1=exec/enter only and 3=write+exec/enter.
This keep the compatibility when you do the simple test if(permission){ do; } but if you want more control in a module you can test to know if the user will have the button save enabled or not for example.

[michaelc]

I don't understand some items.

Code: Select all

      "server": {
         "actions": [


Whats going on here ?

I think basic definition does seem logical in a file, but the access control seems far more logical in the DB, as you will want to grant that out to an administrator and does not need to be done by a developer, just my thought.

One thing I don't like is an either or for location of information, this creates confusion unless it controlled by a single control file for all functionality within the application.

I would have some concern in how much you tie your backend ( PHP ) with your frontend ( EXTjs ) as extjs is a moving target get to coupled and your version locked, with 3.0 due out in April(ish) this could be an issue.

Just my 2 cents.

[tmurdock]

I don't understand some items.

Code: Select all

      "server": {
         "actions": [


Whats going on here ?

I think basic definition does seem logical in a file, but the access control seems far more logical in the DB, as you will want to grant that out to an administrator and does not need to be done by a developer, just my thought.

A module can consist of client and server components. The client can call its server component's methods (passing any needed data). The module's server component is a PHP (or other) class that is instantiated and then its public method ran.

This part of a module definition is only meant to allow the developer to declare what method calls can be made on his server class. The 'actions' are the method names that can be called. This is needed so the administrator can see what methods are available to grant privileges to, nothing more. I will be renaming 'actions' to be 'methods', which is what they are, the public methods of the module's server component.

One thing I don't like is an either or for location of information, this creates confusion unless it controlled by a single control file for all functionality within the application.

I have decided to only store the definition data in the database.

I would have some concern in how much you tie your backend ( PHP ) with your frontend ( EXTjs ) as extjs is a moving target get to coupled and your version locked, with 3.0 due out in April(ish) this could be an issue.

Just my 2 cents.

If you know a better way to do this I'd like to here it. But keep in mind, from your questions listed here, I don't think you understand all that I am trying to do.

[cobnet]

RE: server, actions

Very interesting topic! Should a module show all available actions/methods to a user/group? or should it only show what actions/methods are available to this user/group? This could go either way as far as I can see it.

Benefits to client side: If action/method is available, enable buttons for action/method, if not available, disable buttons for action/method. However I think it might be better to not show actions/methods that are not available to the user/group, simply makes a more secure app. I lose the enable/disable options, but security should rule?

Server side: RULES!!!!!

Just thoughts from an interested user, I don't think we can please everyone, but we should definitely apply as much security as possible.

MORE THOUGHTS: A module definition: What to include?

VIEW/ADD/EDIT/DELETE options/actions/methods.

When loading a module client-side, should a script include all options/actons/methods and then enable/disable options/actions/methods as they are available, or should a script only enable available options/actions/methods?

ADDED: As for ExtJS 3, who knows, I just installed ExtJS 2.1.1 and had no issues with qwiki 1.0 Alpha! This is nice. As long as we follow ExtJS on the client side, I don't think we can go wrong. The server side will always be a question, but with simple php classes, is should not be too hard to convert to whatever you use.

As for database vs file storage. This could be very easily be made for both. I can see an option for a call from a client-side module to the server which simply checks to see if a file exists, if not goto the database, create the file then continue on. The file is now available for future calls. On updates, simply delete the file, the next call will re-create the file. This enables cache options and makes less strain on the database and should be faster if the file storage is in JSON format?

Don't you just love development!