Project pages:

ISF :: List : Javascript extension for HTML tables.



What is ISF?

ISF is the (Open Source) Information System Framework. ISF is a RIA web server and client framework designed to manage and organise information in a flexible and scalable manner.
In most aspects ISF will try to remain neutral to any particular technology, language or framework. A primary goal is to design in a layered interface approach; To allow anyone to pull out the layer they may not like or be able to use, and replace it with their own. I hope to keep the application of ISF as broad as possible. Please have a perusal through the rough block diagram below to see what is planned to be in ISF.

Why?

The web is developing fast. It's steadily starting to dominate the application domain. Now there doesn't yet exist a truly free and scalable RIA framework that aims to satisfy the operational layer of RIA. We aim to provide highly functional information tools to manage your application data. Best of all its free.

How?

The current core is being primarily developed in PHP. This, being an RIA, will be easily portable to our own flavour of language be it Python, JSP, Ruby etc. A fundamental design goal is to provide clear, coherent interfaces and documentation in order to facilitate the port to other langauges.

For more information contact Pat [isf at b22222 dot com].

Information System Framework

System General

System Objects

The system will be made of system objects. System objects define the structure of a database table, serverside class, the object serialization and the forms and grid schema that will run all of the aforementioned.

Per System Object...

1 Database Table

Many Lists to Sort and Search through data

Many Frontends or Interfaces to edit data

Data Management Services

Grid

Column Visibility

Users should be able to choose what fields from the database they want to view, and what horizontal order to view them in.

Sorting

Users should be able to sort their view of the information on any field, in either direction.

Pagination

Provide a mechanism to page through large datasets.

Filtering

It is planned to provide the average user the ability to search and filter for information in an easy and effective means. Above that, provide more advanced users the ability to tailor filters to a highly flexible degree. This has been proved to highly reduce the need for custom reports being designed at a cost by system designers.

Simple Filters

A single input field search should be provided per field viewed by the user. An option to AND or OR the filters is a planned feature.

Advanced Filtering

It is planned to allow a high degree of filtering on all data types and fields viewable by the user. The system will provide a recursive-tree like interface for users to build highly specific filters for themselves.

Template

Allow a user to save their current view of information into a template. This template will save everything from column visibility to pagesize.

Manage Data Delivery Mechanisms

It is through the grid system that the user will have the option to setup data push and pull devices.

Push / Pull Data ServicesWhen setting up data delivery services the user should accept some terms and conditions on information sharing and disclosure.

Email / IM (Push)

Users should be able to setup schedules to have data delivered to their email (or IM) account. Provide an interface to setup multiple schedules on any (permisssions allowing..) grid in the system. Users will select a datasource(grid) and a template, then choose an interval to have that information delivered to them. The option to select only new data is a planned feature.

Feed (Pull)

Users will be able to setup a feed (most likely RSS) against grid templates. When new records emerge in the template the Users feed reader should pick them up.

Multi-Source Structure

Users can publish multiple feeds; Feeds can be made up of multiple sources. A user can name and describe a feed the ndecide what that feed publish's. Users will be able to manage their feeds seperately from the Grid system, but is placed here as it is most heavily relient on the grid system for data.

Tracking

The system will keep track of all requests on pull services. This data will then be heuristically analysed to detect abuse (sharing with illigetimate third parties) and the user will be able to track how popular their feed is.

High Level Interfaces (Push & Pull)

It is planned to setup a high level text based API to allow advanced users to pull data (perhaps even push back) from the system. This API could be used by third party systems, or even just a user sitting behind an instant messenger for instance.

Publishing

A strong focus should be kept on the ability to publish information out of the system, in any number of technical means currently available on the web.

Graphing / VisualizationAn interface will be provided to translate any grid of data into a graph.

Group by Column

Users should be able to choose how to group data and which information to show. Options to apply aggregate functions ahould be available.

Graph Look & Feel Customization

Every visual aspect of the graph should customizable. Some defaults and templates should be provided. Users should be able to save templates of graph LAF's and perhaps even be able to publish these themes.

Data Event Tracking and IncorporationA set of functions will be provided to call when data is being saved to the database. These functions will create history data about the data being saved. This history data can then be used to trigger events and provide information about the table and information therein.

Grid functionality

Allow all funcitonality allowed on normal data to be applied to history data.

Data Editing Framework

Extensible Components

Common API

A common set of methods to interact with all components that might be used on a form.

Themable

The components distributed with the core ISF should all remain themable.

Permission Sensitive

Components should be sensitive to the permission schemas laid out per user in the database.

Application of Permissions To Form

The same permissions that determine whether teh user is able to see data in grids should be used to determine whether the user should be able to edit or even see the record they are editing with the current form.

Accessability

All form (and component) design should respect web standards, accessability for disabled, code and layout cleanliness.

State Management

The current state of forms and the data within them should be easily interpretable by the end user. A common mechanism will be employed across all forms to encourage a consistent interaction with the system.

Entrypoint Interface

A clear API or set of rules will be established for programmers to understand how to load and interact with forms.

Windowed / Modal Mode

Forms should be designed with the understanding that they are being loaded in a multi-window environment. Forms must provide the neccassary API to control modality and other such directives.

System Framework

Frontend

Feature Rich Javascript UI

A layered API that allows the implementation of any Javascript Framework to connect to our Information Server. It is important to note here that we will implement a third party JS framework to handle the client application framework. Currently Mootools is the preferred choice.

Windowed / MDI Interface

With the advancement of web client frameworks it is now very feasible to run our internet application in a windowed fashion. The client implementation should provide a switch to only allow 1 window to be viewed at a time (forcefull degrading to a single viewport)

Themable

All aspects of the client should be designed to accomodate themes. Themes should be downloadable and installable into the framework. Themes include all visual aspects and layouts of the system.

Backend

Highly Secure Access Control

All requests for information from the server should be checked against the current users credentials and security profile.

Folder Layout

A smart and clean project folder is a happy project folder.

Loading System Objects should ideally use Clean URLS

project.com/[list|edit]/com/b22222/isf/module/objectName/[default]/[A234SDF324AS]

D/Encryption of Database Pointers

All tables in the database will have an ID field. When passing this ID to and from the web client in requests it is imperitive to encrypt it so that the end user does not know the table nor the record ID to which he is viewing.

Extension of available PHP functions

Extensions and Facilitators of...

Date

Facilitate the seemless use of dates between the database, the server and the client - All of which may reside in seperate timezones.

Communication

Provide a common API to deliver communication using any number of delivery platforms. Focus should be kept on the successfull delivery of information in the end users prefferred format.

Email

Skpe, SIP

AOL, MSN, GTalk

SMS

Facebook

RSS (Readonly)

File / IO

Provide an easy to use API to common disk and IO functions.

String

Common functions used on strings not natively provided by PHP.

Conversion

Common functions used to convert data types, arrays, or parse any other kind of data between two different states.

Decryption / Encryption

Provide an API to formalize an encryption standard to be used throughout the framework.

Database

It is still in debate whether to provide a database API that is dedicated to one database (in all likelyhood MySQL), or to structure the API such that it could easily switch between multiple database platforms.

Connection Management

Create a scheme to smartly manage connections to the system database.

Data Retrieval

Helper functions for retrieving and recursing through resultsets.

Database Management

Provide an API to the aplication designer to facilitate database table/view management.

Debugging Framework

A set of functions and a laer in the framework that persists to easily switch on a debugging mode for select users.

Database

Permissions

It is a primary ISF goal to create a permissions framework in the database that is highly flexible and scalable that can be levereged on from all other aspects in the framework.

Granularity: System-Object, Record, Field

Structures will be setup to permissions at all granular levels in the system.

Actions: Read, Write, Delete

All possible generic actions should be included in the security framework. It is planned to include some kind of extensability here to allow for 'actions' that are not generic to all parts of the system.

Groups -> Users

Users will belong to groups. Permissions will be applicable to each of those types. It is an unclear option yet whether groups will also be made placeable within other groups (Thus allowing permissions to cascade through a permission tree structure).

Registration Details

Public

User is registered

By himself or on his behalf.

Email sent to A[Group/Member/Custom]

Custom should probably be a space to enter a sql statement which must return a set of user id's

[A] confirms / rejects.

Options should be available to specify wether all signatures are required, just one, or a specific amount. Further options should be available to specify failover procedures when someone rejects a registrant and someone else confirms...?

Email sent to new user.

An email will also be sent to the remaining group members to communicate that they do not need to still confirm user.

Examples and Code

System Object Reference (JSON)

{
	name: 'tld.domain.optional.module.objectName', // Unique system name
	version: 1,			// A positive whole number.
	taxa: { 
		title: '', 		// Name of this class
		item: '' 		// Name of an individual instance of this class
	},
	source: '',
	field: [
		{	
			name: '',			// The database field name in the table
			type: 0,			// Constants will be available
			default: null,
			contraint: {
				maxLength: 0, 	// In number of digits or characters
				minLength: 1, 	// In number of digits or characters
				maxSize: 32000, // For numerics only
				minSize: 1,		// For numerics only
				regex: ''		// A regular expression
			},
			event: {
				// See event reference below; 
				// Only server events are applicable.
			}
		}
	],
	
	layout: [
		{
			name: 'default',	// Name of this form layout
			field: [			
				{
					for: 'Parent',		// DB field to link to
					name: 'Parent',		// Display name on form
					description: 'Parent Menu Item',
					type: 'strictlookup', // The component type
					visible: true,		// Physical visibility
					pos: { 				// Absolute positioning by default
						x: 450, 
						y: 20, 
						w: 230, 
						h: 0 
					},
					style: {
						class: '',		// Maps to a CSS class (or java LAF/subclass)
						enabled: true	// duh
					},
					remote: {			// For Ajax or dynamic fields
						uri: '',		// System object that will provide data
						procedure: 'menu', // Which stream of information?
						args: []		// Arguments to filter or direct data
					},
					inherit: {			// Data may be inherited from a parent form
						source: '',		// For web: [Postback or Parent]
						name: ''		// Name of the attribute to inherit
					},
					event: {
						// See event reference below; 
						// Most events are applicable to a form component.
					},
					field: []			// Fields may be heirarchially structured
				}
			]
		}
	],
	
	filter: [	
		// Still to be designed... Different layouts 
		//   may want to only be applied to certain records.
	],
	
	event: {
		// See event reference below; 
		// Most events are applicable to a form.
	},
	
}


/* ------------- Event Reference ------------- 
 * Each event object should have a set of string objects named after the
 *   language they support. 
 */
	event: {
		server: [
			beforeNew: {},
			afterNew: {},
			beforeSave: {},
			afterSave: {},
			beforeLoad: {},
			afterLoad: {},
			beforeDelete: {},
			afterDelete: {},
			beforeRender: {},
			afterRender: {}
		],
		client: [
			beforeInit: {},
			afterInit: {},
			mouseEnter: {},
			mouseExit: {},
			mouseMove: {},
			mouseDown: {},
			mouseUp: {},
			mouseClick: {},
			keyDown: {},
			keyUp: {},
			keyClick: {}
		]
	},


		

An example of a grid/list.

The code (ASP flavour) to design the above grid.

Technologies and Frameworks most likely to be used (developed on).

System Object Notation
JSON
Serverside
PHP
Database
MySQL
Clientside Javascript
Mootools
Additional Clientside Functionality (MDI)
Mocha
Graphing
OpenFlashChart