The tutorial was one reason I started getting interested. It is pretty similar. As far as integrating with the User model, that also looked like a good fit. Since it's in-house, I have the luxury of using Active Directory (LDAP) for sign-in, and once I know who's out there, the rest should be pretty much stock Hobo, if I'm reading it correctly. Thanks for the reassurance on HoboFields -- I'll read that part with an eye on the alternative.
I think I'll work the tutorial after hours tonight, then decide whether to do a Hobo-based site tomorrow. Really, I should at least see how much capability comes right "out of the box." Then, I can concentrate on stuff that needs tweaked. I guess I might be able to get to a go/no-go in a day, maybe two. I can afford that, if the OOB is as nifty as the tut indicates. Thanks again for the evaluation and opinion! Ron On Apr 16, 12:02 pm, Bryan Larsen <[email protected]> wrote: > I'd go with Hobo. Of course, I'm biased. :) > > Your problem sounds like an evolution of our > tutorial:http://cookbook.hobocentral.net/tutorials/agility, so that will help. > > Hobo lets you concentrate on your Model logic and provides default > Controllers & Views for you. You only have to tweak to customize, and > it sounds like you're ok with a minimum of that. > > The permission system also will save you a lot of time > > The tutorial uses HoboFields. You probably don't want to use > HoboFields because you already have your models. Hobo does not > require HoboFields, so you'll be OK. > > The only gotcha I see is merging your User model with the Hobo User > model. That should be fairly straightforward. > > We know the documentation is weak, but we're a friendly group here. > > I would suggest working through the tutorial as a first step. > > cheers, > Bryan > > On Apr 16, 8:48 am, paron <[email protected]> wrote: > > > I am just looking for opinions, here. I have until June 1st to get an > > application on-line, or they will burn my house down. > > > I have to write an application with 15 related tables, which already > > exist. Appearance is second to ease of use, since it is strictly in- > > house. The application is a time tracker for projects -- but our > > projects consist of overlapping subprojects broken up geopolitically > > or by funding sources, assigned across in-house and contractor > > providers. We need to be able to retrieve reports by geopolitical > > entity, or by funding groups, or by project, or by contractor, > > or . . . There are four user roles -- Project Manager, Group Leader, > > Producer and Administrator (the $ folks.) with different permissions. > > > Further background: I've used Rails since the 1.2 release, IIRC. I > > guess I'm solid, but not flashy. If the documentation were more > > comprehensive, I'd probably be a little more comfortable switching, > > but . . . > > > Your opinions as people who've already climbed the Rails-to-Hobo > > learning curve sure would help me make up my mind. I am especially > > concerned about the fact that my tables already exist -- does Hobo > > depend on a blank slate? Do I stand a better chance of keeping my job > > by coding my brains out in Rails, or by learning Hobo and then coding > > my brains out in that? Will Hobo add enough to my coding speed to pay > > back the learning curve? > > > Ron --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
