App Editor

CloudWall has built-in IDE, which is intended for authoring and testing apps of jquerymy structure. 

App Editor opens docs of type manifest — they can be standalone apps, doc editors or app components. All CloudWall interfaces and apps (including App editor itself) were authored inside App editor.

Screenshot of Inliner app source code, opened in App editor. 

Click to zoom or open it in CloudWall demo.

App components

CloudWall apps are jQuery.my manifests, so they are json docs and are just trees of nodes. Each row of left column points to a resulting app branch. When app is saved, branches are merged according to their order.

Button adds new branch. To change branch order just drag rows.

Button shows popup with compiled app, warnings and global vars used. Merging — superimposing branches — acts like this:

So you can decompose your app into several branches, 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, branch .HTML of above example is written as an expression.

Each tab in App editor remembers its own undo history until app is closed. Tab title is dot notation of a path it should be mounted to.

Ephemeral branches

Each branch has Settings, called by clicking button at the top right corner of code editor. You can set Preview only checkbox to exclude the branch from finalized manifest, only putting it into manifest during preview.

App settings

App settings popup, resulting app is an editor

App settings popup, resulting app is an editor

Button  opens manifest settings popup. It edits app display name, icon, IdName and version, preferred widths, editable doc types (for editors) and so on.

What is IdName?

IdName input defines app/manifest internal id (not DB doc _id property). It’s a string used by system to reference app or manifest within app cache.

Those ids are much like row titles of App Editor, but on more global 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. You can see Inliner app decoupled in that way, all plugins are external manifests.

Type and modes

Each manifest doc can be utilized by system in three different modes — app, editor or manifest. Mode is set at the right aside panel.

App. 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. 

Editor. Sort of app, 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. Editor apps have extended set of props.

Manifest. When this mode is selected, doc edited is usually a component of another app. Since it never runs standalone, no timeout or masks required.

Beta. It’s not a mode per se, beta selector can be set in addition. While manifest/app is marked as beta, other users (not authors) won’t be able to run it.

Title node

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.

State mask

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 {"filed1":true, "field2":true}.

Widths

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.

Preview run

Button runs edited app in fullscreen or popup. Preview mode is defined in Settings dialog. Preview mode environment is not equal, but very similar to native CloudWall runtime.

Errors during preview start are put to browser console.

Preview version of an app has all ephemeral branches mount. This approach allows testing with various data, supplied directly by preview environment.

 

© 2017 ermouth. CloudWall is MIT-licensed.