Card gem or the Card/Deck Split

Again, just for discussion for now.

I've looked a little at how rails does the many projects in one repo and tried to do something similar here.  My thinking now is that if we get this split right, then everything needed for the platform is in the card gem and the wagn (soon to be decko) gem is what makes it case 1, a web application that uses the card engine.

It took me a while, but I got it to load and run the few specs left behind in the wagn part.  Seems like the mods should be split, but many of them are core.  Please add your comments about what is core and what is not.  I'm thinking that things like accounts has be be with the deck as authentication is a site issue.  Default is a plain card, and then we are using card_ids as the creator/updater.  Question for all is how we want to connect to an external user model, do we always want to have a card with a card_id that is associated with the external mode?  Is that just another instance of an external model bound to a deck via a standard way of doing that?  My plan was to add card_id to the external table (making it belong to a card and the card will have_one of the external model).

The part I haven't figured out/finalized is the way the top level objects should work.  Initially I thought (wrongly) that the Engine (Card::Engine < Rails::Engine) needed to be part of the Wagn::Application < Rails::Application object, but there just isn't a way to have one object fill both roles.  And this split implies that the application will always have very simple routes that mount the Card::Engine thing, and the same thing in the platform use, but you'd have all your application's initial routes.  We may also want to split out some of the legacy routes to the application and leave only the platform standard stuff in Card::Engine routes.
It's like this:


decko ---------
               \
decko-rails ----- card
               /
whatever-else -


I'm guessing decko-rails may also depend upon the decko gem?  There are
lots of ways that could work, but I imagine they'll share code.

I'm not attached to the name decko-rails per se, but whatever you stick in
your Gemfile in your rails app *has* to have "decko" in it, because a big
part of the value of this is getting out the decko name, and otherwise your
site isn't even using decko at all.  If you're not seeing that then perhaps
you're not really thinking through the marketing approach?  We can't try to
throw 5 (or even 2) different brands out there.  Almost no non-technical
person in the world knows ActiveRecord.  Card is not our brand name, Decko
is.

I am, however, very strongly attached to getting the controller out of the
card gem.

*"why leave it out; it isn't that much code"*


It's all of actionpack, which means all of rack.  And it may be railties,
too.  So it *is* a lot of code, even if it isn't mostly wagn code.  In
fact, conceptually it's probably the cleanest way to separate the most
code. (at least until we start breaking out mods).  It's ultimately quite
similar to ActiveRecord; yes the vast majority of users are using it via
rails. But if you're not using via rails, why would you want rails
controllers and such hanging around?

Consider a use case close to your heart: XML.  My understanding was that
you didn't think ActionController was really helping you much in building
what you wanted there.  Perhaps you would want to tackle XML that by making
decko use something other than ActionController.  Perhaps you want to write
a different gem that uses card.  In any case, the "isn't much code"
argument becomes weak there, because there's this huge lump of code that
you want to get rid of but can't.

*"considering the MVC stack together is a valid modular unit as well"*


I'm not saying it's not a valid unit, but it's not really modular; it's
pretty much the whole thing.  To me if we leave in the controller there's
basically no need for a separate card gem.

Let's discuss javascript somewhere else when we're ready to tackle card
content issues.




On Mon, Dec 8, 2014 at 12:44 PM, Gerry Gleason <notifications@github.com>
wrote:

> In card/app/controllers/card_controller.rb:
>
> > @@ -5,7 +5,7 @@
> >
> >  class CardController < ActionController::Base
> >
> > -  include Wagn::Location
> > +  include Card::Location
>
> I certainly see the point of wanting to use the models without the
> controller, but I think considering the MVC stack together is a valid
> modular unit as well. Maybe we need to talk to get straight on the language.
>
> I guess the question for me is what kind of API are we creating here?
> Thinking with the new MoFoS, that's a model/view API thought of together,
> and the card controller is simply exposing that in a canonical controller
> via web oriented APIs. That is really the industry standard for service
> oriented APIs and allows the bridging of language domains with ease. I
> mean, why leave it out? If you don't need it, it isn't that much code.
>
> Maybe you want to call this card-rails, and split this part into two gems?
> (I would say card-engine to be more precise, but I'm fine with either.)
>
> It also kind-of opens up questions about the front-end components. I see
> how some javascript is in mods, which is right from a dependency
> perspective, but I'm not sure how well it matches up with current practice
> in JS APIs, loading and packaging. When we add decks to P2P (my trib
> project), we will already have tinymce, and there are some configuration
> customizations we do and may want with across any card based extension. If
> we do things right different approaches can co-exist with cards.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/wagn/wagn/pull/263/files#r21478973>.
>



-- 
Ethan McCutchen
One of the Wagneers, Wagn.org

Wagn. How pioneers roll.

s: ethan.mccutchen
t: @intogreater