Table of Contents generated with DocToc
Demo/Prototype: JavascriptClassCreator
An Extensible Software Environment for Improvement and Adaptation (ESEIA) is a web-based tool, that allows novice developers to tweak software without digging very deep into libraries and code of the project.
The objectiv of an ESEIA approach is, that large groups of people are able to modify a software according to their needs.
An ESEIA tool like a prototype JavascriptClassCreator exports the code in a certain programming languages or syntax (here HTML and Javascript), so that also deep alterations are still possible and these improvement can be added to the templates for code generation. The structure alterations of software done be programmers with less time or knowledge in the programming language, can be exported with the new templates. So structural rough alterations and improvements in the logic can be exported with the improvement ESEIA templates. This concept is well-known for Content Management Systems like Typo3, Joomla at. al., where LAYOUT and CONTENT are separated working levels. On technical level CSS does that for HTML layout. JavascriptClassCreator is a ESEIA prototype to extend this principle on the software development level, placed in between UML and grass roots programming of functions, classes, data structures, ...
The vision for certain OpenSource projects is, that a software release X1 has a ESEIA tool as well, that allow quick and simple alterations X1 into X2.
(Medium Skill) Example 1: A Web-App X1 is regarded useful for another area of domain.
(Low Skill) Example 2: If the software Y1 can be configured by a config file, the ESEIA tool can be just a web-based interface, that allows to exports the config file and has an menu driven graphical user interface (GUI) to create JSON file (e.g. create a Software Menu and the Menu items a mapper to certain call of the underlying Y1. Publishing the software with a new config file support developer in rapid alterations of new releases without diving too deep into the code.
Web-based Javascript Class Creator that
JavascriptClassCreator facilitates the export of UML-diagrams with the libraries of the OpenSource JointJS repository:
Attributes of Classes: UML editing of Attrubutes of Classes
Methods of Classes: UML editing of Attrubutes of Classes
Inheritance from Classes: JSCC allows to edit the SuperClass of Classes, visualized in UML-diagram.
Associations between objects (Associations can be created and destroy during runtime)
Aggregation of child instances/objects by a parent instance/object
Interfaces allows inheritance the method headers that determine the call of methods. This is implemented in the JavascriptClassCreator (JSCC), but not in the Javascript itsself. When you determine a class of the type Interface, that JSCC checks if all method headers (i.e. the way a method will be called with parameters) are properly defined and existing. If not, JSCC will create the method header for you without creating a link for inheritance in Javascript. Attributes of the interface class are available in class as well.
Abstract In contrast to an Interface an abstract class has real defined bodies of methods that can be inherited. For those methods that do not contain a body (i.e. MethodCode is empty) the method code is handle like methods defined in an interface. This means that JSCC creates method header for you by inheritance from the abstract class, that will overwritten/defined in the child class.
IDE vs ESEIA: An Integrated Development Enviroment is very rich of features. The art of ESEIA development is to eliminate features of IDE (cover feature) and tailor the remaining features for the area of application of the software release. On the other end - in contrast to a pure front-end for software the ESEIA concept allows to touch certain areas of the code on the grass roots level of programming. The existing code elements guide programmers with creating new versions or branches by templating the syntactic workflow for the previous versions. UML export of code provides insight in the software design. High levels of documentation for comprehension of the semantics of code are augemented with code compressors, when the exported code is executed by an interpreter (and not compiled).
You might know from other implementations of JavaScript repositories (e.g. [JQuery](), MathJAX), that there are existing two versions of the JavaScript implementation. 1) the minimise/compressed code for higher performance in web browsers and NodeJS, 2) documented code for further software development and comprehension of the previous development by new members of a team
UglifyJS is used for compressing the code and generate higher performance for the web-applications. The Developer Mihai Bazon created UglifyJS, that has even the option to parse Javascript Code, which is necessary to create equivalent minified the Javascript code (see Source Code of UglifyJS)). JSCC uses mainly the wrapper for UglifyJS is written Dan Wolff. His UglifyJS-Online example is called in a seperate window to minify/compress the exported Javascript code for generated JS Classes. The original version of his UglifyJS-Wrapper can be accessed and forked at GitHub.
Future application of UglifyJS will allow cross compilation of generation of generic XML-Code for code generation that is highly independent of a specific programming language (see XML2Code as a proposal). UglifyJS can take Javascript code as input and create an Abstract Syntax Tree (AST). When the AST in UglifyJS is generated, you can send a AST walker over all nodes of the abstract syntax tree and perform a Cross Compilation from Javascript for example to PHP. For the code compressor in UglifyJS the AST is e.g. used to replace var vMyLongVariable = 0 by var v=0. The walker for the code compressor reduces (among other tasks) the length of variable name. This makes the code less readable for developers, but creates less loading for web browsers. For JSCC the removal of comments has the highest impact on the size of the code.
(JSCC) is the main JSON file, that contains the JSCC project of the software development
Example: The web-based software DisApp is used in the online version as project of JSCC. Furthermore DisApp is used as example for the following sections too.
(FileList) Parent: (JSCC) is an JS Object of all HTML-files, used in the project. The key to access the JSON definition of the file is just the filename itself.
Remark: Using a filename as a key has the advantage that the you do not have to handle a the mapping of the filename to the key of the hash FileList. But approach has the disadvantage, that you cannot access the appropriate object in a JSON tree by the dot-notation of an tree.
vJSCC_DB["FileList"] is equivalent to vJSCC_DB.FileList butvJSCC_DB["FileList"]["app.html"] or vJSCC_DB.FileList["app.html"] is the only way to address the JSON object of the file app.html correctly. vJSCC_DB.FileList.app.html addresses a html-object as suboject of the app-object, and this object does not exist in the JSON tree in general.Example: The web-based software DisApp contains two HTML-files:
JSCC_DB.FileList["index.html"] ).JSCC_DB.FileList["app.html"]).JSCC_DB.FileList["submit.html"]).In traditional software development HTML pages can be regarded as windows with a certain content, that are opened and closed within the software. The HTML file defines the Graphical User Interface (GUI) of the app in these windows.
(Templates) Parent: (JSCC) is an JS Object of all Templates, used for the project. The templates can be edited and exported form JSCC to you own harddrive for sharing these templates with others. Templates are not stored in the project.json file because a developer wants to replace the templates for Javascript code generation and for the exported HTML-files by templates that match with the cooperate identity of an institution or agency. So if institutions or developing teams collaborate for creating or maintaining a certain WebApp then the share the project.json and keep their templates.
Example: The web-based software DisApp contains two HTML-files:
Both files use the same HTML template for all main HTML file used for DisApp (e.g. JSCC.vDOM_TPL["tMainHTML"]). The export of the main template is stored in tpl/Default.html. Alter this file and load that into JSCC to create your own look and feel for the WebApp. If you generate new HTML files in JSCC and add this file to the project.json, then this new file will be generated with the same basic template too. E.g. a new HTML page submit.html will share the same look and feel of app.html and index.html, because they share the same HTML template.
For this demo of JSCC the following main template is based on the following themes and icons:
In traditional software development HTML pages can be regarded as windows with a certain content, that are opened up and closed within the software. The HTML page defines the Graphical User Interface (GUI) of these windows.
The classes in the project define the behaviour of the WebApp, the methods of the Javascript classes are called from GUI elements.
When we consider the object oriented programming concept we have classes in instances of the classes (objects). Similar to this concept we create HTML files as templates, that contain certain markers, that are replaced by user-defined content.
The markers three preceding underscores before and after the identifier. An identifier itself consists of uppercase characters only with 3 underscores before and after the uppercase name of the identifier. Only uppercase characters and single separating underscores are allowed as identifiers. An example of a marker will look like thislook like this:
Examples Marker: The marker
___MYMARKER___ or ___MY_MARKER___in the template for an identifier with the name ___MYMARKER___ or ___MY_MARKER___ that will be replaced by a defined content for a specific instance of the template. E.g.
___PAGE_ID___will be replaced by a unique ID of the page, e.g. ___page12___ for the 12th generated page of one template. The number will be incremented after
any new page generation of a certain HTML template (PageType). Similar to this approach the marker
___PAGE_TITLE___will be replaced by the title of the HTML page. In general markers that are replaced by content from a hash (Object), are stored in the project JSON file ___vJSCC_DB___ with the ID in uppercase characters (e.g. PAGE_TITLE) and the definition of page title.
"PAGE_TITLE": "My Title of the Page",The notation with 3 underscores before an after the uppercase identifier is used, because it creates less conflict with other programming languages and the programming infrastructure of the JavaScriptClassCreator can be extended to other languages as well.
Refactoring: HandleBars will be used as new template engine.
Pages are sections in HTML files that are shown separately with JQuery in the WebApp. In general the user will perceive switching from page to an other page like following from one HTML page to an other HTML page. From the programming site we have to distinguish pages and html-files because the browser will not leave the HTML-page, when an other pages is displayed. For pages the previous page is hidden and the new page is shown by application of JQuery. Pages must have a unique ID PAGE_ID, so that single pages can be addressed by JQuery via hide() and show().
For pages the standard markers are
___HEADER_BUTTON1___ first button of the header of a page (usually left button)___HEADER_BUTTON2___ second button of the header of a page (usually right button)
Header buttons can just link to another page (e.g. Show Page: home)A page contains elements. These elements could be a
HTML_TITLE) are replaced in all page contents of all HTML files. This leads to the fact, that definition of DOM elements in layout, wording and event handling can be defined accross HTML files of the web app.Also language dependencies for header buttons can be handle by Elements, because the elements are globally replaced in the HTML page.
A FileHTML (e.g. app.html or login.html) is generated from a template (e.g. DefaultTPLHTML). In a HTML file their are two main identifiers, that are replaced by a specific page content.
LIBRARIES will be replaced by all imported Javascript libraries and JSON databases.PAGES will be replaced by all defined pages, that are used in the HTML file. For all HTML-files, pages can be defined separately. HTML files can exchange actions settings via the parameters of the URL, starting with a "?". Main parameters are:database=mydata.db)action=dothis)index.html loads a file tpl/index.html replaces the markers and the file should be stored in the downloaded subfolder /app_LSAC/ as /app_LSAC/index.html. The folder /app_LSAC/ can be retrieved if you download the repository of JavaScriptClassCreator from GitHub.With the following enumeration the purpose of the folders is explained. JSCC-folders are necessary for the JavascriptClassCreator. JSCC uses serveral other OpenSource projects mentioned in the section Acknowledgements. If you want to replace the libraries with new versions of the OpenSource software it is much easier to replace that, when the versions are kept in separate folders. The used OpenSource packages are not updated automatically, so that JSCC as a whole could fail all of a sudden, due to unresolved dependencies.
/ace contains the source of the ACE code editor used in iFrames for JavascriptClassCreator (JSCC)/app_LSAC is the directory in which you can store the generate sources for a specific WebApp. LSAC is an abbreviation for Local Storage and App Cache./css contains the Stype Sheets for JavascriptClassCreator (JSCC)/plugins/exporter4code is a template driven code generator that is pure HTML/JS and independent of a specific syntax of an programming languages (not necessary for JSCC)/plugins/java2javascipt allows the import of Java-Classes into JSCC, it parses attributes and method headers of the Java Class (not necessary for JSCC)/plugins/javascipt2htmlcreator contains older framework for WebApps based on frames (not necessary for JSCC)/plugins/jquery contains the JQuery libraries and images for JSCC/plugins/uglify contain the code compressor./plugins/uml contains the UML diagram generation, called from JSCC based on JointJS./js contains the Javascript libraries for JSCC/prog contains the JSON files for the programming project/srv contains the HTML files that emulate and server and the server response to a client requestSoftware in currently in Beta-Phase. It is a proof of concept. Refactoring of JavascriptClassCreator code in an object-oriented style
JavascriptClassCreator (JSCC) is currently designed to develop software for Javascript. Even if it is not a perfect solutions for this web-based approach Javascript is regarded as sink for programming code. By using the parser UglifyJS, Javascript code will be parsed and crosscompile in other programming languages (e.g. PHP, C++, Java,... ). Source code optimizations can be performed in the exported programming language.
If you start the JavascriptClassCreator JSCC with docs/index.html in your browser then JSCC loads the following definitions:
Save Local Storage button in JSCC.JSCC never stored the alterations of the code in Local Storage of the browser. Then the predefined databases in the hash vDataJSON are used. Accessing a specific JSON database works as usual by vDataJSON["myjson"]. If these databases are changed, it is necessary to store the alterations in local storage. Now the local storages does contain a JSON file and new reload in the browser will load data from the local storage.The collected data of the App is stored in the LocalStorage of the browser by default. The application of LocalStorage from the browser does not require any connectivity to the Server. This assures that data collection can be done if the mobile device is offline.
Cross site scripting is a security risk for users, so the WebApp must be stored on the webserver, where the server backend is installed, e.g.:
If it is necessary to submit the collected data to a remote server it is necessary to use the FORM tag in HTML. The following workflow can be applied:
sid for the user uid that is valid for a certain period of time. Then the app is started with those parameters
https://www.example.com/myapp/app.html?uid=...&sid=...&...pkey (e.g. pkey=637). If a certain record was not submitted to the server the client assigns the submitted attribute in the offline database as false (e.g. record with pkey=637 submitted=false). The in the HTML-page of app.html the client submits data to the remote server via PHP-scriptapp.html the client submits data to the remote server via PHP-script
https://www.remote.srv/backend/myapp/submit.php?uid=...&sid=...&pkey=637&...&https://www.remote.srv to the clients url. HTML-file can access the query string of the call of the HTML file. The server calls the app.html as callback e.g. with the following parameters:
https://www.example.com/myapp/app.html?uid=...&pkey=637&action=submitted
So the client knows that the record was sucessfully submitted. This leads to alteration of the submitted flag in the LocalStorage of the browser (e.g. record with pkey=637 submitted=true).JSCC is HTML/Javascript application and the templates of JSCC are stored in textareas or input elements of HTML pages itsself. All template elements have a unique ID in the HTML-tag and the function getValueDOM("tTplHTML") reads e.g. the content of the input element. Javascript Code is generated on the Code of JSCC and the underlying HTML pages for the App are generated on the HTML tab of JSCC.
You can view the content elements used for code generation by scrolling down the JSCC page and press on the blue Button Code Templates. You can play around with these templates and explore how these templates affect code generation for Classes and HTML file changes these value without any concerns and check impact on code generation. Just by reload of the JSCC-HTML page docs/index.html the old settings of the code templates are restored.
Scroll down the JSCC page in docs/index.html and press on the blue Button Code Templates at the bottom of the page. Now you can edit or replace the content elements that determine the code generation of classes.
Save Local Storage in JSCC and the template setting is stored in your own browser (not alteration of templates are submitted to a server). Next reload with the same browser will restore you settings.Export Templates with the downloaded template file code_templates.json you can send the file to other developers and the import the templates in Code tab of JSCC.JSCC infrastructure on you own computer and then replace the template file code_templates.js in folder docs/tpl. The difference between the extension .js and .json is a simple prefix in front of the JSON file, that converts the JSON-file into JavaScript-file. The prefix defines, where the JSON content is stored.{"color":"blue","setting" : "is ok", "header" : "this is my header"}vMyJSON = {"color":"blue","setting" : "is ok", "header" : "this is my header"}vDataJSON["myjson"] = {"color":"blue","setting" : "is ok", "header" : "this is my header"}
With this approach you can access the JSON file in the hash vDataJSON with the ID myjson. This has the advantage, that you can load and access several JSON file through the hash vDataJSON without contamination the root name space of the App/HTML file to much.vDataJSON is global hash (Javascript Object), that stores all the loaded JSON data. A single variable is used to store all the JSON data, so that the global name space in the document is not "contaminated" with many JSON database names.
A single JSON file can be loaded without any Javascript workaround by assigning the JSON data to a key in
vDataJSON["my_data"]={....} assigns a hash (Javascript Object) to the key "my_data" in vDataJSON.If the first letter is uppercase, then the key is reserved for classes of JSON databases. One example is the "SurveyJS"-key in vDataJSON. An app could handle more than one survey (e.g. a mobile health app could provide a questionnaire for blood pressure with the JSON name blood_pressure_ and another questionnaire about food and weight with the JSON name food). The format of the questionnaire for SurveyJS is
vDataJSON["SurveyJS"]["blood_pressure"] (Blood Pressure questionnaire)vDataJSON["SurveyJS"]["food"] (Food and Weight questionnaire)A JSON file is stored in the Local Storage of the browser (limit 5MB for some browsers)
for programming and export function just use JSON.stringify(...) to generate a string that defines the data structure. E.g. for the JSON data in vMyJSON the call of JSON.stringify(vMyData) generates the JSON definition as a string. Store the generated string in a textarea of your HTML file or view the result in the console by console.log(JSON.stringify(vMyData)).
The generated string by JSON.stringify(...) can be stored in the Local Storage as well.
var vDataString = JSON.stringify(vMyData);
localStorage.setItem("mydata",vDataString);Databases from vDataJSON can be exported in the same way.
var vData = vDataJSON["SurveyJS"]["food"];
var vDataString = JSON.stringify(vMyData);
localStorage.setItem("food",vDataString);Databases in JSCC have a root attribute called init_type. With this attribute JSCC determines the type of JSON structure provided with the JSON file. In general we can not expect a classification of JSON file with that attribute. So programming should determine the type JSON manually.
a web app runs in browser which has no write permission to your harddrive. To provide the feature to save a file to the harddrive of the user the FileSaver.js library can be used (see acknowledgements). The function
function saveFile2HDD(pFilename,pContent) {
var file = new File([pContent], {type: "text/plain;charset=utf-8"});
saveAs(file,pFilename);
}
defines a function to save a file by using the download feature of browsers to store a file in the Download-folder of the browser. Importing blob.js and filesaver.js provides this functionality to browsers.
An WebApp following the LSAC (el-sack) concept is designed with the following objectives in mind.
An LSAC app can collect data for the user store the data without the need to submit the data to any server by default. Data is collected for mobile device user and stored in the browser and NOT submitted COMPANY (transparently or hidden). This is especially relevant for e.g. health related data collected by fitness apps or address book content that apps want to access to. To accomplish these goals, the Local Storage of the browser is used.
Local Storage is used, so that the App can store the collected data in the browser without the submitting the data to any server by default.
The [AppCache]-Cache is used to give your application four advantages (see Beginner Guide - AppCache):
JSCC produces a WebApp that needs the generation of the AppCache-Manifest offline.appcache as a list of files. A Perl-script runs over all files in the directory /app_LSAC and creates a AppCache-Manifest offline.appcache with all files of the WebApp. There is a pitfall with the automated scanning of a directory. The AppCache-Manifest itself is part of the directory /app_LSAC and this file offline.appcache may not be listed in the AppCache-Manifest itsself.
Databases contain data for your WebApp. The collected data is stored in these predefined databases. A JSON schema defines the structure of a JSON database. In the plugins/dbedit folder. The code is adapted code of the JSON-Editor by Jeremy Dorn. As a parameter the plugin/dbedit/dbedit.html takes
schema=myschemadb=mydata, where to store the database.
With the example mentioned above JSCC calls the JSON Editor by plugins/dbedit.html?schema=myschema&db=mydata.
JSCC opens a windows with JSON Editor. The schema is defined by file in folder plugins/dbedit/schema/ e.g. for the exampleplugins/dbedit/schema/myschema.jsBackBoneJS gives structure to web applications that otherwise need a lot of JavaScript, keep the data in HTML form or in general in Document Object Model (DOM) of your HTML file in sync with a JSON database. Your data is hosted in a JSON file (e.g. stored in the Local Storage of your browser or on a server). BackBoneJS supports free you from syncing and tying your data to the DOM. More technically BackBoneJS. See demo of a Local Storage ToDo-List by Jérôme Gravel-Niquet and the annotated code of this ToDo-app written with BackBoneJS. You might want to consider BackBoneJS for developing you WebApp and integrate these concepts as global libraries to your WebApp (e.g. app_LSAC). Especially the LocalStorage concept is already implemented in BackBoneJS models.
SurveyJS for generating a questionnaire for data collection in the webapp. Consider SurveyJS as an option, if you want to do a questionnaire with your webapp. Instead of write an entire new app with JSCC you might want to consider OpenDataKit.
Hamburger Side Menu for generating a header menu that works for mobile and desktop applications. Can be used to design the navigation of the WebApp. This might help you to replace the iOS-inpired JQuery theme used as default in JSCC.
MorrisJS for visualisation of results for data collections performed with the WebApp. Integrate this as global libraries.
Geolocation When you use you WebApp for attaching digital content (e.g. comments, videos, snapshot, ...) to a geolocation you might want to retrieve the geolcation. The link shows how to used that in you WepApp.
QRCode Scanner Javascript JavaScript QRCode reader for HTML5 enabled browser by
2011 Lazar Laszlo. Try Online-Demo of QRCode Scanner to see the Javascript QR-Code scanner in action. Use the scanner to retrieve content from QR code in your app. If you want to use the QR-Code scanner in you WebApp app_LSAC add the libraries on the GitHub-Page in the given order to your WebApp.
If you want to add map feature to your WebApp OpenLayers makes it easy to put a dynamic map in any web page, especially mobile applications. OpenLayers can display map tiles, vector data and markers loaded from any source. See OpenLayers examples to experience, what OpenLayers can be used for in you web development. For this application see (see JQuery Mobile example with OpenLayers). This could be one page of you WebApp.
Special thanks to the following individual developers and teams of OpenSource JavaScript projects:
JSCC. The schemes of the JSON subtree are stored in the folder /tpl of the JavascriptClassCreator. The full potential of the JSON-Editor was not used in JSCC. This can be approved in the future.
The JSON-Editor of Jeremy Dorn has full support for JSON Schema version 3 and 4 and can integrate with several popular CSS frameworks (bootstrap, foundation, and jQueryUI). This would lead to major code reduction of JSCC. Refactoring of JSCC would make more use of the JSON-Editor features. Check out an interactive demo (demo.html): http://jeremydorn.com/json-editor/FileSaver.js that is used to store created JSCC files to the local filesystem. JSCC uses the same mechanism of browsers, that allows a Save as... in the context menu of a web pages or image. So not uncontrolled write access to your file system is implemented, because users have to select the locations in which the user whats to store the file (e.g. JSON, Javascript or HTML).app_LSAC OpenClipArt arrows are used. Special thanks to Jakub Jankiewicz (kuba) for providing this icons under a Creative Commons license on OpenClipArt.