Difference between revisions of "WebIssues/Web Client"
(→RPC) |
(→Objects) |
||
| Line 15: | Line 15: | ||
===Objects=== | ===Objects=== | ||
| − | Everything (almost) needs to be an object. Were using the php5 methods of | + | Everything (almost) needs to be an object. Were using the php5 methods of [http://www.php.net/manual/en/language.oop5.overloading.php __set() and __get()] to maintain persistance. |
| − | + | It is worth while to have a look at <code>class.wi_Core.php</code> which which needs to be extended for each instance. | |
A quick introduction to the the technique is with the following psuedo code | A quick introduction to the the technique is with the following psuedo code | ||
| − | class | + | class wi_Comment extends wi_Core |
{ | { | ||
| − | + | public function __construct($id){ | |
| − | + | //* call to parent class which set up all variables etc | |
| + | //* The first var is the ID, and the second is the name of primary key | ||
| + | parent::__construct($id, 'comment_id'); | ||
| + | if($this->_id > 0){ | ||
| + | $sql = 'select * from comment where comment_id=?' | ||
| + | $this->_data = $this->db->getRow($sql, array($this->_id)); | ||
| + | } | ||
| + | } | ||
} | } | ||
| − | smarty | + | =smarty= |
| + | We might not need it - apart from maybe some spoolng and email formatting. | ||
=javascript= | =javascript= | ||
Revision as of 00:37, 25 February 2008
Here the overall idea of the web design, and as usual this document is subject to change.
The target web client is based on the following components being available.
apache
database
php
JSON
The webclient will favour only php5, and at that preferably php5.2 or greater which has mod_json built in. The config.main.php file detects if mod_json is available and if its not, then load the libs/JSON.php script.
RPC
the rpc/ directory contains all the ajax requests. These are broken into either a fetch or an action. For example getting a list of users is a fetch and updating an user would be an action.
Objects
Everything (almost) needs to be an object. Were using the php5 methods of __set() and __get() to maintain persistance.
It is worth while to have a look at class.wi_Core.php which which needs to be extended for each instance.
A quick introduction to the the technique is with the following psuedo code
class wi_Comment extends wi_Core
{
public function __construct($id){
//* call to parent class which set up all variables etc
//* The first var is the ID, and the second is the name of primary key
parent::__construct($id, 'comment_id');
if($this->_id > 0){
$sql = 'select * from comment where comment_id=?'
$this->_data = $this->db->getRow($sql, array($this->_id));
}
}
}
smarty
We might not need it - apart from maybe some spoolng and email formatting.
javascript
The front end will be mainly driven by Ext.js. Its worth taking some time to check out the samples and the extensive API's. The system works more like XUL, Gnome, Qt etc where components are packed into an area so some experience in this area is useful. There's hardly any HTML in there.
As the web client will really heavily on javascript, then we need to be pretty careful about name space, and Ext comes with its own "namespace manager" etc.This is currently being researched.
All JavaScript needs to pass the jslint test, which means that global variables need to be declared at the top of any js file with /*global Foo, Bar */<code> - note no space /*g
$JS_LIBS
There is a <code>$JS_LIBS variable in the config.local.php file and points to the "js" subdirectory of the webissues directory.
One optimization trick is to locate the JavaScript libraries/style sheets on another domain. For example a http://libs_sub.domain.com can be optimized with compression and caching enabled. The rationale is that normally a browser out of courtesy will only make around five concurrent connections to a server, so having some material on another domain, even serving from the same machine really does speed things up.
