Idea

I am personally new to rails, let alone ruby. I have much to do to get caught up to speed. I know that the page labeled "wagn_as_a_gem" explained the needs in a different manner. But I think the gem should be installed into a rails app, and the standalone app should be for what it is. 

---

also see deploy Wagn as gem

---

Great inquiry. And very cool that you're already experimenting with a gem.

 

To me the question that really needs fleshing out is what it really should look like to install Wagn into another rails app. It's quite possible that we will want a separate gem to support this use case. But it's undoubtedly true that we will want the wagn gem described in Wagn as a gem.

 

Wagn has a complex and evolving relationship with Rails. At 1.0 it was pretty safe to say "Wagn is an instance of a Rails app". As we approach 2.0, it's more correct to say "Wagn is a platform that makes extensive use of Rails code". The planned gem is designed to simplify installation and customization of wagn apps much in the way that rails gems simplify installation of rails apps.

 

I know that there will be lots of pull in the idea of using Wagn as a Rails add-on, but increasingly that would mean trying to blend two platforms with conflicting approaches. A rails app is an MVC instance; a wagn app is not. A rails app adds structure by adding low level database tables; a wagn app does not. A rails app invites configuring behavior by adding controller methods and treats events/callbacks as hidden and hacky. A wagn app elevates events to a central architectural position and discourages custom controller methods. Rails views are organized by model. Wagn views (which use less and less of the rails views coding/structure) organize views by set.

 

None of this necessarily means there won't be a place in this world for treating wagn cards as one model in a rails ecosystem or some variant of the opposite. But it does mean this is not our primary use case, and therefore it won't be the focus of the primary wagn gem that we (Grass Commons) support.

 

I think my proposal would be that we rename this idea to support wagn as rails add-on and continue to explore the needs (in "issues") and solutions involved.

 

---

A couple of notes. First, you can use Wagn's naming scheme without using all of Wagn. Check out the SmartName gem that we created. Since the names relate directly to URI space and Rails routes, this is a good space to start.

 

Second, we are already thinking about attaching other namespaces within Wagn. Mostly these are conceived of as connecting Wagns to Wagns and potentially splitting up the cards in a single wagn into multiple domains, but this mechanism can be used to connect to 1) other local models, or more commonly 2) Web applications, probably via some RESTful API.

 

Making Wagn and other models work happily on the same Rails application is largely about organizing the external namespace, URIs and routes.

 

In the end, having a clear use case or how you want to integrate Wagn as a content management system into a larger application is the first step. I've thought about this a lot and keep getting a bit stuck on the concepts. For example, I'm interested in E-commerce on Wagn, so I look for existing E-commerce gems, but the will add their set of models to my Rails application and what I want is for the same logic to work with the models stored in cards. Maybe if more code were written to an abstract ActiveModel api rather than ActiveRecord, we would have a better go at making that work in a patterned and easy to integrate way.

 

As Ethan said above, you thoughts are welcome as we try to make better sense of what would add the most value to the Wagn platform.