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