JS Designer Project
 
HomeOverviewEditor FeaturesScreenshotsTechnical Features
How it works
Known bugs & To DoBuild your first 'hello world' applicationSF summary pageDownload SourceForge.net Logo

How it works :

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.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 uses the template found in "window_templates", and replaces the special tags "_#FORM_SCRIPTS#_" and "_#FORM_CONTENT#_".
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 :
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.