On Mon, Aug 29, 2011 at 05:39, Daniel Bryan <danbr...@gmail.com> wrote:
> Woah, that sounds pretty cool. Are you using RubyParser or Ripper? > > Neither. I'm using sourcify ( > http://rubydoc.info/gems/sourcify/0.5.0/frames ) to convert blocks into an > S Expression, and then my own library to parse that and spit out equivalent > JavaScript syntax. I've made no attempt to deal with Ruby syntax that has no > direct JS equivalent (like block arguments to function calls), nor to > capture operations that would be illegal in JavaScript - > https://github.com/cerales/ShyRubyJS > Very interesting! > > What if you introduce the concept of *contexts*? So all CouchDocument are > automatically one context (that only include one type of document), but you > can also introduce your own contexts. So you can have a CookingUser-context, > which describes a User and what he can do with Receipes. In your controller > you can say `CookingUser.new(current_user).untried_recepies`. Or maybe a > UserReceipes which has an "untried"-view. > > So contexts are just a lightweight class where you can place your views. > The developer has to decide what the context should be called and how they > should work. The point is that the contexts should mirror the use-cases of > the data, and as there might be many ways to look at the same data, you > can't have an automatic way of saying where the view belongs. It all depends > on the point-of-view. > > > I like this! > > The way I'm interpreting this is that contexts could be a really light > layer on top of the anonymous views. So it'd have your abstract view > specification - a map block and a view block - and then a couple of little > links specifying, for example, which model classes / "kinds" it's associated > with, for the sake of the developer's sanity. > > When I started development on this concept, I put a lot of thought into how > models would be written, to the point that they became effectively a schema. > I realised that that was absurd - anything heavier than the optional "needs" > and "suggests" concepts is throwing away the agility, convenience and > forgiveness of a NoSQL approach. > > So that's out the window, but there's still a challenge here - model > schemas, as well as being a concession to the brutality of SQL and its > greedy demands, are a very useful tool for keeping track of and > self-documenting your application. It seems there needs to be some kind of > tool to replace that if your'e doing something like this. > The truth is that there is no such thing as "schema-less". There will always be a schema. The question is if it will be enforced in the database, at insert-time in code (each document has a strict schema) or at runtime in code (it works just as a Hash). > > So what I'm thinking might be useful is some kind of optional admin > interface that will look at your Models and your Views and your Contexts, > and try to visualise or contextualise them in some way. Like the django > admin interface, with all the power of introspection, but somehow groovy. > > Of course, it's so _easy_ to work with data when it's just JSON documents > that there's no reason you couldn't, with a little thought, build a super > user-friendly interface where you build your MapReduce views just by being > given a graphical view of your document Kinds and dragging and dropping > things into the fields for what you want to emit, what you want to filter, > etc. It's probably not the best idea philosophically, but for giving people > the tools to really easily write a dynamic web app it seems like it could be > useful. > I've been thinking about the exact same concept, but a more general solution based on relational algebra. My idea was that you defined your schema, relationships and queries in an admin-panel thingie (inspired from Yahoo! Pipes) in a database-agnostic way (relational model), and then later defined the mapping from the database (which could be CouchDB, MongoDB, MySQL, Redis) to the conceptual schema. I'd say your project is more limited, but way more feasible than my "big plan". So I think you should definitely go for it and make a kick-ass CouchDB platform :-)
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
