JS Designer Project
Optional DB interaction:
If you own application needs to interact with a relational DB, the
system used in the designer can be re-used, just copy and adapt
db.js, and query.js.php.
The same principles can also be used for any online, no-reload
interaction between your appli. and the server.
Don't forget then to include the following in your main window
template: "<script id="dbscript" language="javascript"
src="/includes/designer_query.js.php"></script>".
Your application:
Your application, with all interfaces present but hidden, except those your JS code wants to show.
As
there are usually lots of things to load (big HTML, big CSS & lots
of JS lines of code), the application will usually take a second or two
to load & start, but after that, as it remains totally client-side,
the reactivity has nothing to do with traditional web-based
applications.
Static Javascript:
All the code of your application that isn't linked directly to an event goes in static ".js" files.
These
".js" files are refered from the main window, by adding the
corresponding "<script src=..." in the main window template.
Ina long term view, these files should eventually dissapear, as the goal is to have everything in the DB.
show_widgets.js.php:
This is the PHP script that builds a .JS file containing the javascript functions for all events you coded.
A function is automatically created for each event, and event
registration is added in an initialization function called by the
onload event.
Nice little detail : functions are coded in such a way that the "this" keyword, refering to the calling widget, can be used.
window_templates Table:
This DB table contains for each main window the template used by
"show_widgets.php" to build the HTML page. If you need to add several
static ".js" calls, or insert Java applets, or anything else embed in
your HTML, here's the place to add it !
subwindows Table:
To gather several interfaces,
designed independently, into one single application, you just define
these interfaces as subwindows of the main application window.
Besides the names of the window itself, and the one of it's parent, you
need to give the name of the top-most widget. In other words, the
widget of your interface containing all other widgets of this
interface. This is used by the show_widget script to know
from which widget to start exploring childrens.
select_source Table:
Use it when you need to fill a selector (drop-down list) with the (partial) content of a table.
Displayed item and its corresponding value can be different, and you can add a WHERE and ORDER clause.
widgets Table:
The most important table : contains all widgets, for all "windows" (interfaces), and all their properties.
The "parent_id" tells when a widget is the child (in the DOM) of another (only DIV are valid parents !).
getxt Table:
When a widget has text , you'll find it in there, for each language needed.
Useless for radio, checkboxes and selectors, corresponds to the "value" attribute for <input> widgets.
If the widget is a div, the text is inserted directly after the opening tag, before any children.
If the widget is an image, the text is used as alternate text (ALT="...).
In
this table the id is not simply the widget number (as in other tables),
but it's complete name (thus preceeded with "wid_"). It is made that
way so that any other "static" elements, not included in the DB (but
rather in the window template for example) could also use this getxt
system.
actions Table:
Contains Javascript code for each event of each widget.
Everything in the "function" field (the js code) is escaped to avoid problems when going thru JS,PHP and SQL.
JS Designer frontend:
This is where it all starts:
There is no "SAVE" as all modifications are triggering immediate updates in the DB.
show_widgets.php:
This is the PHP script that builds
your application's HTML page from the data colelcted in the DB. It also
inserts CSS data directly in the HTML tags.
CSS must be embed this way so that you JS could read current style properties.
The scripts replaces the special tags "_#FORM_SCRIPTS#_" and "_#FORM_CONTENT#_".
The designer's page is constructed much the same way as for you own
application (see below), except that this particular "show_widgets.php"
script doesn't take care of subwindows (unlike the one below), doesn't
use window templates, and of course, only "static" javascript is loaded.
query.js.php:
This is the second half of the little trick that makes direct Javascript DB interaction possible.
Here the PHP is used (as the script name suggests) to generate a ".js"
file. The SQL query is received in the URL, is executed, and the
results are sent back as javascript code.
This JS code is merely the assignation of four main variables :
- nbresults: Number of results from the SELECT
- tab: Array containing all results from the SELECT
- inserted_id: Value of the autoinc in the last INSERTed record.
- response_arrived: Used by db.js to know when the query results are available.
db.js:
This is the first half of the little trick that makes direct Javascript DB interaction possible.
To make an SQL query, the designer (or your app.) just calls the
do_query() functions, with as parameters the query, the action to be
performed when the result arrives (we're working asynchronously!), and
the DB name.
"db.js" does all the rest, including queueing so you can start several
queries successively, without risking any mix ((asynchronous, remember
!).
The heart of the trick is simply the ability for a js to change the
source and force the reload of a <scriptsrc=...> tag IF and only
IF done thru the dom tree.
After benchmarking, it seems most browsers can run at least two threads
to load ".js" files, thus I'm working on a multi-threaded version of
this thing...
dynatable.js:
Small library to manipulate tables. It
was written mainly for the label editor, but it was improved and is now
very useable in many circumstances in you own applications.
It has only two functions : add_tbl_lines and del_tbl_lines.
The first one can be user to add one or several rows in an existing
table, at the end of it, in the midle of it, or replacing it
(with/without keeping the header).
The second one just deletes the row you asked.
Take a look at the comments in the script itself for parameters syntax.
dragdrop.js:
This is the heart of the designer itself. It contains all the mechanics
to update online and in WYSIWYG your interfaces, doing all the
necessary updates in the DB at the same time.
