Hey Folks, Am hoping a number of you on the list might be able to give some input on something I''m mulling over with a client of mine. THE BACK-STORY The client is a firm down in Southern California that has spent time and money building a membership system and event calendar using Zope through a third-party developer. Not to get into all of the history here, but the experience has, frankly, been long and horrible, with stretches of no communication from the developers, outstanding bugs, etc. They''d hoped to launch almost a year ago. Hell, I don''t even think the developers created and docs or specifications for what''s been built. I''ve been doing a lot of the front-end development (XHTML/CSS/PHP) for their broader site, and they''re now consulting with me to help them move away from their current developers, get another set, finish their app, move hosts, etc. WHAT I''M LOOKING AT While I''m doing that, I''m also mulling over whether or not it would be worth while to just scrap what''s been done and move to RoR instead. The clients aren''t technically savvy, but know more about what they want now than they did in the beginning and already feel that their membership system is falling behind the times. I also believe that it''s important to have a application framework that allows them to easily add/enhance features with speed, low overhead, and ideally low cost (well, economical, anyhow). Ruby and RoR seems like a serious contender. There''s nothing particularly fancy that they''re doing here. Employees can add and administer classes, customers can register and pay for classes, they want to have some back-end reports that they can print, registered customers can create/edit user profiles, etc. (Sorry for being vague here, but I don''t want this message to go on forever.) Again, a lot of this is already built in Zope (with a poorly-designed UI), but there are a number of existing bugs and I''m not clear how well, how fast, or how economically this could scale versus something built with RoR. Would love any feedback you might able to provide. Cheers, Anthony
Anthony Baker wrote:> > Would love any feedback you might able to provide.Scrap it. --Steve
Sounds to me like a pretty simple standard web app. Any framework will do, keep in mind when going with RoR that if you want a multiple developers team that it might be hard to find others for your team. If they like the frontend html code just keep that and fill in the dynamic parts again, go through the screens with them to evaluate what they want. But chasing obscure bugs in a platform your not familiar with in undocumented code is usually a no go. So other then using the HTML that the current project generates, I wouldn''t dive into it any further then you have to. Regards, Mischa Kroon ----- Original Message ----- From: "Anthony Baker" <anthony-ZEJemHc0OvwkEFqJWa3iIgC/G2K4zDHf@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Tuesday, October 18, 2005 7:27 PM Subject: [Rails] [Newbie] Moving App from Zope to RoR> > Hey Folks, > > Am hoping a number of you on the list might be able to give some input on > something I''m mulling over with a client of mine. > > THE BACK-STORY > > The client is a firm down in Southern California that has spent time and > money building a membership system and event calendar using Zope through a > third-party developer. Not to get into all of the history here, but the > experience has, frankly, been long and horrible, with stretches of no > communication from the developers, outstanding bugs, etc. They''d hoped to > launch almost a year ago. Hell, I don''t even think the developers created > and docs or specifications for what''s been built. > > I''ve been doing a lot of the front-end development (XHTML/CSS/PHP) for > their > broader site, and they''re now consulting with me to help them move away > from > their current developers, get another set, finish their app, move hosts, > etc. > > > WHAT I''M LOOKING AT > > While I''m doing that, I''m also mulling over whether or not it would be > worth > while to just scrap what''s been done and move to RoR instead. The clients > aren''t technically savvy, but know more about what they want now than they > did in the beginning and already feel that their membership system is > falling behind the times. > > I also believe that it''s important to have a application framework that > allows them to easily add/enhance features with speed, low overhead, and > ideally low cost (well, economical, anyhow). Ruby and RoR seems like a > serious contender. > > There''s nothing particularly fancy that they''re doing here. Employees can > add and administer classes, customers can register and pay for classes, > they > want to have some back-end reports that they can print, registered > customers > can create/edit user profiles, etc. (Sorry for being vague here, but I > don''t > want this message to go on forever.) > > > Again, a lot of this is already built in Zope (with a poorly-designed UI), > but there are a number of existing bugs and I''m not clear how well, how > fast, or how economically this could scale versus something built with > RoR. > > > Would love any feedback you might able to provide. > > > Cheers, > > Anthony > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
I''ve done quite a bit of work with Zope over the past few years, so before you dump it, here''s a bit of a check list Zope pros (vs. RoR): - maturity - ZODB (Zope''s Object database) is extremely powerful, ingrained into Zope, and would be very difficult to emulate using e.g. Postgres, MySQL, Oracle, etc. - off-the-shelf products. You can download lots of products from www.zope.org, and elsewhere, that give you fully blown applications that you can then tweak for your specific requirements - database support. Zope supports just about any commercial or FOSS database product out there, and does it very well. It plays nicely with views and stored procedures, which can be a challenge with RoR - Plone. Plone is an amazingly powerful CMS built on Zope; I haven''t seen anything to compare with it - user management. Zope''s user management is very intelligent, complete and easy to work with. RoR''s lags behind, as salted_login_generator, ModelSecurity etc. are immature and largely tooled to specific purposes; Zope''s built-in user management fits well for just about any situateion Zope cons (vs. RoR): - scalability/performance. Generally speaking, Zope apps tend to run slowly, probably because of the size of the Zope infrastructure and the fact that it runs in Python, which (like Ruby) is interpreted - learning curve. I''d say that Zope''s learning curve is longer than RoRs, although not that longer if you actually get stuck in - development time. Within a few days, I was developing apps faster with RoR than with Zope - AJAX support. Non-existent in Zope, as far as I''m aware; you have to code up all the Javascript etc. by hand - growth. RoR is growing incredibly fast, and will no doubt catch Zope in terms of developer mindshare if it hasn''t done so already I could go on, but the main point is to not just dump Zope without looking at its strengths. Given you''ve got no Zope background, it''s probably easier for *you* to switch the whole app over to RoR, but you might lose quite a bit in the process - maybe you could find a local Zope guy and work with him to get the existing system working properly Good luck Dave M. On 10/19/05, Mischa Kroon <mischa.kroon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Sounds to me like a pretty simple standard web app. > > Any framework will do, keep in mind when going with RoR that if you want a > multiple developers team that it might be hard to find others for your team. > > If they like the frontend html code just keep that and fill in the dynamic > parts again, go through the screens with them to evaluate what they want. > > But chasing obscure bugs in a platform your not familiar with in > undocumented code is usually a no go. > > So other then using the HTML that the current project generates, I wouldn''t > dive into it any further then you have to. > > Regards, Mischa Kroon > > ----- Original Message ----- > From: "Anthony Baker" <anthony-ZEJemHc0OvwkEFqJWa3iIgC/G2K4zDHf@public.gmane.org> > To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> > Sent: Tuesday, October 18, 2005 7:27 PM > Subject: [Rails] [Newbie] Moving App from Zope to RoR > > > > > > Hey Folks, > > > > Am hoping a number of you on the list might be able to give some input on > > something I''m mulling over with a client of mine. > > > > THE BACK-STORY > > > > The client is a firm down in Southern California that has spent time and > > money building a membership system and event calendar using Zope through a > > third-party developer. Not to get into all of the history here, but the > > experience has, frankly, been long and horrible, with stretches of no > > communication from the developers, outstanding bugs, etc. They''d hoped to > > launch almost a year ago. Hell, I don''t even think the developers created > > and docs or specifications for what''s been built. > > > > I''ve been doing a lot of the front-end development (XHTML/CSS/PHP) for > > their > > broader site, and they''re now consulting with me to help them move away > > from > > their current developers, get another set, finish their app, move hosts, > > etc. > > > > > > WHAT I''M LOOKING AT > > > > While I''m doing that, I''m also mulling over whether or not it would be > > worth > > while to just scrap what''s been done and move to RoR instead. The clients > > aren''t technically savvy, but know more about what they want now than they > > did in the beginning and already feel that their membership system is > > falling behind the times. > > > > I also believe that it''s important to have a application framework that > > allows them to easily add/enhance features with speed, low overhead, and > > ideally low cost (well, economical, anyhow). Ruby and RoR seems like a > > serious contender. > > > > There''s nothing particularly fancy that they''re doing here. Employees can > > add and administer classes, customers can register and pay for classes, > > they > > want to have some back-end reports that they can print, registered > > customers > > can create/edit user profiles, etc. (Sorry for being vague here, but I > > don''t > > want this message to go on forever.) > > > > > > Again, a lot of this is already built in Zope (with a poorly-designed UI), > > but there are a number of existing bugs and I''m not clear how well, how > > fast, or how economically this could scale versus something built with > > RoR. > > > > > > Would love any feedback you might able to provide. > > > > > > Cheers, > > > > Anthony > > > > > > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> Again, a lot of this is already built in Zope (with a poorly-designed UI), > but there are a number of existing bugs and I''m not clear how well, how > fast, or how economically this could scale versus something built with RoR.There could be issues with migrating from ZopeDB to SQL. This is mostly a problem if the existing data are valuable and their structure intricate. Zope builds heavily on aquisition. I don''t know if a ZopeDB adapter exist for RoR. Apart from this I don''t think there would be any problems. It seems more likely that you could use RoR to build the app faster than it would be to analyze the existing app. Throw in a few AJAX trics and impress them :-) /Kasper
Anthony, I used to be a Zopista, then a PHP code monkey and now I''m a Railer (?). Believe me, porting, as in translating the code, is a no go. Besides the issues with the ZODB the framework in Zope is unlike _any_ other so porting the current system to any other framework is probably not feasible (read not cost effective at all). Your best bet is to gather all the requirements neatly and rewrite the app in whichever framework. In my experience doing it in Rails will give you the shortest time with the best structure for cleaner upgrades and modifications. PHP would probably give you the shortest absolute path but it will take you more effort in the long run to do upgrades and modifications. Hope it helps, Adrian Madrid On 10/18/05, Anthony Baker <anthony-ZEJemHc0OvwkEFqJWa3iIgC/G2K4zDHf@public.gmane.org> wrote:> > > Hey Folks, > > Am hoping a number of you on the list might be able to give some input on > something I''m mulling over with a client of mine. > > THE BACK-STORY > > The client is a firm down in Southern California that has spent time and > money building a membership system and event calendar using Zope through a > third-party developer. Not to get into all of the history here, but the > experience has, frankly, been long and horrible, with stretches of no > communication from the developers, outstanding bugs, etc. They''d hoped to > launch almost a year ago. Hell, I don''t even think the developers created > and docs or specifications for what''s been built. > > I''ve been doing a lot of the front-end development (XHTML/CSS/PHP) for > their > broader site, and they''re now consulting with me to help them move away > from > their current developers, get another set, finish their app, move hosts, > etc. > > > WHAT I''M LOOKING AT > > While I''m doing that, I''m also mulling over whether or not it would be > worth > while to just scrap what''s been done and move to RoR instead. The clients > aren''t technically savvy, but know more about what they want now than they > did in the beginning and already feel that their membership system is > falling behind the times. > > I also believe that it''s important to have a application framework that > allows them to easily add/enhance features with speed, low overhead, and > ideally low cost (well, economical, anyhow). Ruby and RoR seems like a > serious contender. > > There''s nothing particularly fancy that they''re doing here. Employees can > add and administer classes, customers can register and pay for classes, > they > want to have some back-end reports that they can print, registered > customers > can create/edit user profiles, etc. (Sorry for being vague here, but I > don''t > want this message to go on forever.) > > > Again, a lot of this is already built in Zope (with a poorly-designed UI), > but there are a number of existing bugs and I''m not clear how well, how > fast, or how economically this could scale versus something built with > RoR. > > > Would love any feedback you might able to provide. > > > Cheers, > > Anthony > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Adrian Esteban Madrid aemadrid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
David Mitchell wrote:> - learning curve. I''d say that Zope''s learning curve is longer than > RoRs, although not that longer if you actually get stuck inHaving spent some time this Summer "getting stuck in" to both Zope and RoR, I''d have to say that the learning curve for Zope is a LOT steeper. Not sure about longer, as I abandoned Zope once I realised how excellent RoR was. I guess it depends on your background - I came via MySql/PHP. If you come to Zope via Java, then I guess all the interface stuff will make more sense. Just my 2p''s worth :) -- Robert Jones