CloudWall has built-in IDE, that allows you to create, test and deploy apps and their components right in browser tab.
Main IDE component is App editor, all CloudWall apps are created in App Editor.
This app opens docs of
type:"manifest" – they can be standalone apps, editors or app components. All CloudWall interfaces and apps (including App editor itself) were authored inside App editor.
Screenshot of Inliner app opened in App editor.
Click to zoom.
CloudWall apps are jQuery.my manifests – so they are json docs and highly structural. Each tab of App editor interface edits one of json branches. When app is saved, branches are superimposed according to their order (to change order just drag a tab).
Button shows popup with merged manifest, warnings and global vars, that manifest use. Merging – superimposing branches – looks like this:
Click to zoom
So you can decompose your app into several tabs, each more or less compact, in a way that best suits app complexity. Note you can write expressions that are evaluated when manifest is merged.
Each tab in App editor remembers its own undo history. Tab title is dot notation of a path it will be mounted to.
Right panel holds manifest settings. They define app display name, app/manifest id and version, preferrred widths, editable doc types (for editors) and so on.
IdName input defines app/manifest internal id (not doc _id). It’s a string, that system utilize to reference app or manifest within DB.
These ids are much like tab titles but on system level – they can have dot notation, that is used to superimpose components on app start.
For example if you have app with
MyApp IdName, and manifest with IdName
MyApp.SomeComponent, when core app starts, its running code sees latter manifest as
this.SomeComponent. So two (or three, or more) manifests are just glued together right before app starts.
This approach allows to decouple complex apps into several manifest docs for team development.
Each manifest doc can be utilized by system in three different modes – app, editor or manifest. Mode is set at the right aside panel.
Standalone app, is displayed in app panel of DB docs list. You can define several fields of app data that are reflected to browser address bar and tab title. Also you can restrict max app start time – system will kill app that starts too slowly.
Editors are in fact sort of apps, specially intended to edit docs of some type. Their behavior is little bit more complex – system must control if doc edited was saved when app closes, must provide doc to edit when app launches and so on.
For editors you must also define:
When this mode is selected, doc edited is usually a component of another app. Since it never runs standalone, no timeout or masks required.
It’s not a mode per se, this selector can be set in addition. While manifest/app is marked as beta, other users (not authors) won’t be able to run it.
It‘s a dot-notation path in app
data section, where runtime title of app resides (if any). When this property changes, system reflects it to browser tab title and to right pane, that is a list of running apps.
Setting available only for standalone apps, not editors. This app param manages what app
data section members are to be reflected into address bar – and back, if app starts from URL.
It can be just string in dot notation, or json object like
This field enumerates widths in pixels, that are preferrable for your app. Kind of responsive design with restrictions.
It‘s sometimes hard to build UI, that is fully responsive. Set of fixed widths ease up restrictions and allows to focus on UI, not implementation issues.
To be written.