split

[Herby Vojčík]

Hello,

I have thought about a split I envisioned in GH-21 but when combined
with thought of iOS/Mac as needed because of iOS part, I came to wider
view, which would enable using calatrava out of iOS as well.

This view (maybe, maybe not) contradicts a little from @gga's reply to
GH-21 in which he said calatrava should be external library referred
from an app (at which point, it effectively ceases to have any opinion
about building process). I don't know which way is better.

What I saw was that, being a bridge between two worlds of (shared) Model
and (optionally shell-reusing but native) View, both part could be
"pluginized" enough so that calatrava itself is just the basic bridging
support plus project setting up helper, and both sides could be made
pluggable.

For the moment (since it is a gem), let's say calatrava gem itself does
very little beyond having a bridging plus a setup helpers there. Other
part could be different gems (calatrava-xxx) which could be used when
detected.

From the side of views (that is, native platforms), each platform (ios,
android, web) could have their own plugin/gem. Thus, when I create a
project (or later, I want to add/remove a platform), I would just user
`calatrava on projectname platform add/remove platformname`. This is not
as hard as it seems - it just creates (in case of add) an appropriate
directory from the template and sets it up. It can look for shell and
automatically add shell-wrapper page* for each existing page.

From the side of model, now it has hardcoded the .coffee/.haml/.scss
triplet. But main idea of calatrava, mainly bridging JavaScript app
logic with HTML/CSS shell to native UIs, is orthogonal to these. I would
like to use ECMAScript 6 (via traceur) instead of .coffee, for example.
I even envisioned interesting possibility to provide code and pages in
Smalltalk (pages in seaside-like code) and compile them to JavaScript
using Amber (a Smalltalk for web clients compiled to JavaScript).

So, on the app-logic side, there are also plugins for selecting which
"translator" to use to get form sources to JavaScript/HTML/CSS.

Those are hard to change during project (but why to prohibit it, one may
change opinions after project already exists), but there could be
something like `calatrava on projectname select technologyname` to add a
translator to the stack.

Thoughts?

Herby

P.S.: Dreaming on, it went even further. I was able to imagine the
repository of pages (as in scratch.mit.edu, with visual presentation,
download/remix/upload ability), where you can select a page and download
it for your project (possibly renaming it is case of nameclash), like
`calatrava on project pagecopy SimpleCheckList@repo CheckList` (pagecopy
is good enough to allow making copy of your own page under different
name and making tweaks, also for uploading, maybe; also for copying
between your projects).
*In this case, when adding new platform later-on and the page was in
fact loaded from repo (that is, it is a package of app-logic code and
native UIs for known platforms), calatrava could add native UI for that
page, not just the shell-wrapper.