Transitioning to Tog?
Will Merrell
I have several Rails sites up and working, and several more in the
pipeline. I have found tog and played with it a little. I like the idea
a lot, and would like to start to integrate it into what I do.
What is the best way to integrate tog into my work flow?
I am currently concerned with two areas.
1) What is the recommended way to override and customize my sites. How
should I set up my custom layouts, css, javascripts, models and
controllers. I have done some of this, but would like to know what are
the suggested or recommended practices on this.
2) Most of my sites are based on Restful Authentication extended with
the roles_requirement plugin. I use the roles system to control access
and navigation. In addition to controlling page access with roles I
present or hide navigation buttons and links based on the user's roles,
etc. Now that I have enough layers of sugar over the RA core I find it
fairly easy to work with, although starting a new project is always a
pain to get the RA stuff setup properly. I would readily dump the RA
stuff, but I like the roles based access control. What are the
recommendations for migrating from an RA/roles architecture to the tog
based architecture? Does tog include a roles type of access control? How
hard would it be to add it? Are there reasons not to add it?
Thanks,
-- Will Merrell
Alberto Molpeceres
Thank you for your kind words about tog.
> 1) What is the recommended way to override and customize my sites. How
> should I set up my custom layouts, css, javascripts, models and controllers.
> I have done some of this, but would like to know what are the suggested or
> recommended practices on this.
Not sure if I understand your question, so two answers in one :).
You can organize your project-specific code as you normally do. You
will find that tog uses three namespaces ("none", "member" and
"admin"), which refers to "users", "content owners" (that is: a
blogger, a group moderator, a guy who shres content to a group, etc)
and "site-wide admin". We think that this approach makes code easier
to read and understand since clases and methods are smaller, but you
are not forced to follow it.
For overwriting any of tog's clases/views/assets you only need to at
it to your app with the same path and add/overwrite whatever you need.
That is, if you are not happy or miss something in
tog_social/app/models/group.rb you can just add a group model in your
app with the code you need and that's all. For views and assets, your
copy will be used, no merge.
> 2) Most of my sites are based on Restful Authentication extended with the
> roles_requirement plugin. I use the roles system to control access and
> navigation. In addition to controlling page access with roles I present or
> hide navigation buttons and links based on the user's roles, etc. Now that I
> have enough layers of sugar over the RA core I find it fairly easy to work
> with, although starting a new project is always a pain to get the RA stuff
> setup properly. I would readily dump the RA stuff, but I like the roles
> based access control. What are the recommendations for migrating from an
> RA/roles architecture to the tog based architecture? Does tog include a
> roles type of access control? How hard would it be to add it? Are there
> reasons not to add it?
Ok, first RA. Tog is based on RA, so no difference on that. If
installing tog on an existing project you will be asked if you wish to
install tog_user, so you can decide if you want to continue using your
own code or just tog_user. If you are using a recent version of RA and
your model name is "User", migrating to tog_user shouldn't be a pain
since tog_user is just about signup, login and small user
administration.
And then role_requirement. You can install this plugin and overwrite
tog controllers to support it as I explained above, but tog hasn't
support for roles right now and at least for me, I'm not sure it will
have. Tog focus on content, not people, since we believe on social
networks driven by content. So, for most of the project we develop,
this namespace separation (owner vs not-owner) + "sharing between
users/groups" is enough.
I agree that this doesn't fit all kind of sites, of course, and maybe
some support for roles could be added for tog_users, but we've always
tried to keep the code as simple and small as possible. If this
becomes a real necessity for many of us here, it could be added.
Reading my mail I'm not sure I've answered your questions, but at
least it's something to start a discussion or if you prefer we could
talk (here or privately) about one of your projects specifically and
see options.
Bye,
al.