Yes, Christian, I am also looking forward to what you come up with. Easier Said Than Done, IMHO. " Boy, when you get to my age you see good ideas die and reappear again. "NoSQL" variable-length, multi-valued engines started with Dick Pick (IBM 360 - 1965, then minicomputers(1973) and then hit the PC world in the 1982 under the name "Revelation". yes, it was a "revelation" to those of us trying to build commercial applications on the lowly PCs of those days.
Hundreds of vertical market apps and thousands of mission-critical apps used these engines. Their strength was is in their rapid development ans prototyping capabilities. No need for data migrations. (That's why I liked Hobo taking care of that for me.) As Matt mentioned, reporting was the big problem. You had to build your own (did that) or transfer to a "standard" database engine (also did that) to satisfy enterprise-level clients. Having said that, MongoDB has a natural synergism with Hobo. (But our government clients are just getting comfortable moving from Oracle to MySQL.) I think this is a healthy discussion to have. Dialectic is good. But who is going to do the experiments? Resources are limited... -Owen On Feb 13, 6:50 pm, Matt Jones <[email protected]> wrote: > 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.
