On Feb 13, 2010, at 4:05 PM, Kristian wrote:
Some ambitious ideas for a new Rails 3 - Sproutcore framework.
Pink Palm framework
-------------------
Client - Sproutcore
Server - Rails 3
Client - Sproutcore
-------------------
Use Statecharts (Sproutcore) to handle state transitions in the
client, see Evin Grano.
Have a Ruby DSL to define/generate the Statecharts code. Each state
has a call to a javascript function with relevant parameters which
handles
the state transition! Generate Statechart graph from DSL using
Graphviz. Somehow the Graph generator should handle splitting a chart
up in multiple pieces. This could be assisted from the code side, by
naming state groups and then have the generator create a new graph for
each such state group.
The first hit I got when looking for statecharts linked them to UML,
which triggered my "DO NOT WANT" reflex. :) Further digging turned up
the Sproutcore implementation, which bears a striking resemblance to
the way GUI apps have been in the past. I'd be interested in learning
more, but the sproutcore-statechart repo referenced in several posts
appears to be gone...
Define the view using Sproutcore Views. Community creates custom
Sproutcore views that can be used with themes.
Integrates various nice javascript widgets as Views, fx from jQuery UI
etc. See SCUI (SproutCore UI) project.
Again, SCUI looks interesting - but I've got apps to develop *today*,
not in 6 months!
Server - Rails 3
----------------
Pink Palm app. generator.
Rails templates for applying addons
Rails generators for adding Mongo models etc.
Rails app.
- Model: Mongo DB with MongoMapper/Mongoid
- Controllers: Rails 3 RESTful (Base)
- Routes: Rails 3
- Testing
- RSpec
- Cucumber
- Capybara (replaces webrat)
- Shoulda (optional)
- Factorygirl/Mocha
Scaffold server app from YAML file:
Model, RESTful resource Routes, Controllers, Validations, Indexes and
Scopes (new Searchlogic gem?).
Have 2-way sync between YAML config and app code.
Once again, an interesting idea - but why would I want to fool around
trying to say things in YAML that are better said in Ruby? Barring
massive intervention like grokking S-expressions into YAML arrays,
there's just too much that isn't expressible there: for instance, give
me a YAML representation of a named_scope with a lambda (which is all
of them, in Rails 3).
A few points in summary:
- the whole idea of configuring an app via a giant YAML file is
revolting. It smells way to Enterprise-Javay for my tastes.
- Sproutcore is definitely something to watch, but there are some
serious barriers to using it in many apps:
-- you end up repeating everything twice, once on the client side and
once on the server. The YAML configuration envisioned above appears to
be an attempt to address that, but there's still going to end up being
bits that aren't covered and have to be maintained twice as a result.
-- as a corollary, the majority of business logic in the app is on the
client. If you ever wanted to watch C-level execs clench their
buttholes really fast, mention this. Rightly or not, there's still
some paranoia about competitors "stealing the app".
-- the biggest issue facing JS client-side apps: IE6. It's still out
there, and will continue to irritate decent web developers for at
least the next few years. Between an incompatible and flaky DOM and
the 15x slower JS, it's a serious issue.
-- the second biggest issue: the *back* button. No matter how many
times you tell users, "don't click back", they'll do it. HTML5
promises some relief for this with better state tracking, but see the
preceding point and add IE7's lack of support for HTML5 to the mess...
----
In summary, I'd agree with the idea that richer, client-powered apps
are likely the future. Unfortunately, 90% of the businesses and
nonprofits out there aren't even running on *today*; big chunks of the
world are still being held together by Access DBs, giant cross-linked
Excel files and Word documents CCed to everyone in a department.
(Seriously - I just set up a Dropbox account for a small professional
association who was actually doing the CCed Word docs thing!)
Anyways, I look forward to seeing what you come up with - despite the
rest of this post, *somebody's* got to get away from the PHP fumes
long enough to actually build the next wave of frameworks. :)
--Matt Jones
--
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
