I am starting a large project and still selecting what framework to use. Rather than ask brand x what is wrong with brand y, I am more interested in self confession. Why would I *not* want to use Rails (compared to Iowa and Nitro). I posted a synopsis of the project to ruby-talk but will repost it here if anyone wants it. xev
Robert Mannl wrote:> Yeah I''m interested :)Ok, here goes. This is a web application that: o Needs to emulate the functions of a webmail client (but will have a custom messaging backend based in SQL). o Will have reporting capabilities similar to what you would expect from Crystal Reports. (the reports will be defined in SQL, the web app provides presentation and printing) o Will need various bits of JavaScript and xmlHttpRequest magic. In particular, emulation of ASP.Net''s tree control and bound datagrid. o Will be hosted on Windows Server (but can use Apache instead of IIS). Cannot use Cygwin - so no lighttpd? o Will be load balanced across multiple servers. We *can* cause the load balancer to send request from the same client to the same host - that should help with session and state control. Or, we can store the session in SQL to allow hopping servers. o The ORM needs to be happy with stored procedures (or not used at all). We will never have direct access to even the smallest table. xev
Personally, I really like rails. However, none of my apps have gone into production yet. I've put out a few to support some interaction design projects at school but they only needed to run on my laptop for presentations. However, I have three applications that are going to need to go to production soon and I'm getting a little anxious... Now, I should clarify, I haven't done any reading on moving to production yet, so some of my concerns may be unwarranted, but, here they are. -Finding hosting Very few hosts have ruby installed, let alone rubygems, or rails. People seem to be happy with textdrive, but I have had very little experience with that sort of host. Previously my demands for hosting have been easily fulfilled by 1and1… ie: MovableType driven sites. Ultimately I think the solution to this (for me) is easy, dedicated server hosting. Why? A few of my close friends have offered me space on their dedicated servers. However, this gets into my other concern -FastCGI and Ruby From casually browsing the topics some people have some problems setting up Ruby/RoR with FastCGI -- is this a problem with Rails, its unclear. What I do know is that I do NOT want to be responsible for the $300usd a day of downtime if FastCGI screws up apache for my friend's sites (as they are currently not using fastcgi). Now, like I said, I haven't done any reading on moving to production. Given that fact maybe I shouldn't have posted to this topic about concerns with moving to production. Heck, there may infact be documentation or a roadmap that alleviates both of my concerns with ease. In just thinking about it casually I've considered the possibility of just running Lighttpd with fastcgi and having apache forward the appropriate requests to it, that way the only http server i can screw up is mine. Regardless, what I have experienced with rails is really exciting… Its great because my proffs don't understand how I can produce what I do in the time they give. They think I'm a web-app savant or something :) -Caleb On 5/13/05, Robert Mannl <ro@cayoparaiso.com> wrote:> Yeah I'm interested :) > > > I posted a synopsis of the project to ruby-talk but will repost > > it here if anyone wants it. > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
guh i feel stupid. FYI i sent my first response before you posted details. On 5/13/05, Xevious <xevious-FgZ1Ih9JkPHx9BLsLxWUfA@public.gmane.org> wrote:> Robert Mannl wrote: > > Yeah I''m interested :) > > Ok, here goes. This is a web application that: > > o Needs to emulate the functions of a webmail client > (but will have a custom messaging backend based in SQL). > > o Will have reporting capabilities similar to what you > would expect from Crystal Reports. (the reports will > be defined in SQL, the web app provides presentation and printing) > > o Will need various bits of JavaScript and xmlHttpRequest magic. > In particular, emulation of ASP.Net''s tree control and bound > datagrid. > > o Will be hosted on Windows Server (but can use Apache instead > of IIS). Cannot use Cygwin - so no lighttpd? > > o Will be load balanced across multiple servers. We *can* cause > the load balancer to send request from the same client to the > same host - that should help with session and state control. > Or, we can store the session in SQL to allow hopping servers. > > o The ORM needs to be happy with stored procedures (or not used > at all). We will never have direct access to even the smallest > table. > > xev > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 5/14/05, Xevious <xevious-FgZ1Ih9JkPHx9BLsLxWUfA@public.gmane.org> wrote:> Robert Mannl wrote: > > Yeah I''m interested :)I take it from your points below that you''re currently an ASP.NET shop? As much as I love rails, why are you considering switching? What''s the driver here?> > Ok, here goes. This is a web application that: > > o Needs to emulate the functions of a webmail client > (but will have a custom messaging backend based in SQL).Rails, and any other framework, can build this kind of application.> o Will have reporting capabilities similar to what you > would expect from Crystal Reports. (the reports will > be defined in SQL, the web app provides presentation and printing)Crystal is years ahead of anything I''ve seen in rails as far as reporting goes. You can construct nice reporting frontends in rails, but you''ll lose all the fancy report designers you get with Crystal / Webobjects.> o Will need various bits of JavaScript and xmlHttpRequest magic. > In particular, emulation of ASP.Net''s tree control and bound > datagrid.We''ve got stacks of Ajax magic, but we *don''t* have a binding / datagrid system.> o Will be hosted on Windows Server (but can use Apache instead > of IIS). Cannot use Cygwin - so no lighttpd?Yeah, if you''re windows and no cygwin I''d suggest apache. I''m running a couple of small applications on apache/win32 at present, it''s working fine.> o Will be load balanced across multiple servers. We *can* cause > the load balancer to send request from the same client to the > same host - that should help with session and state control. > Or, we can store the session in SQL to allow hopping servers.There are a number of session store options which will make them accesible to all the web processes. Memcached, Active Record etc. The load balancing shouldn''t be an issue.> o The ORM needs to be happy with stored procedures (or not used > at all). We will never have direct access to even the smallest > table.Ugh. You''ll be able to execute stored procedures, but you''ll instantly lose most of the benefits of Active Record. Personally I''ve seen this approach to data access fail *spectacularly*[1] so I caution against it any chance I get. It sounds like you''re trying to clone ASP.NET development with rails, perhaps you''re better off staying with ASP.NET. Again, what''s your motivation for switching? Perhaps you can compromise some of those points above? -- Cheers Koz [1] 73000 t-sql stored procedures, I''m not making this up.
Yeah I''m interested :)> I posted a synopsis of the project to ruby-talk but will repost > it here if anyone wants it. >
Michael Koziarski wrote:> I take it from your points below that you''re currently an ASP.NET > shop?Not really. A previous developer mocked up some code with a tree and datagrid in ASP.Net, but there isn''t existing codebase.> As much as I love rails, why are you considering switching? > What''s the driver here?My choices are Ruby (Rails, Nitro, or Iowa), Python (CherryPy), Java (J2EE, EJB), or ASP.Net. I''m not into XP, but I would like to have an agile development process (which I had years ago with Ruby). What little ASP.Net I have done has been slow and painful. If I''m going to do in it Python, I might as well do it in Ruby and enjoy myself instead. I would do it in ASP.Net before Java - not because I dislike Java - I am just for current in ASP.Net.> Crystal is years ahead of anything I''ve seen in rails as far as > reporting goes. You can construct nice reporting frontends in rails, > but you''ll lose all the fancy report designers you get with Crystal / > Webobjects.The substance of the reports will come entirely from stored procedures. For presentation I will probably generate PDFs. Or just some really clean HTML.> We''ve got stacks of Ajax magic, but we *don''t* have a binding / > datagrid system.Yeah, I''m not looking forward to implementing one. The ASP.Net grids aren''t really bound either - they just pretend to be.> There are a number of session store options which will make them > accesible to all the web processes. Memcached, Active Record etc. > The load balancing shouldn''t be an issue.Cool.>> o The ORM needs to be happy with stored procedures (or not used >> at all). We will never have direct access to even the smallest >> table. > > > Ugh. You''ll be able to execute stored procedures, but you''ll > instantly lose most of the benefits of Active Record. Personally > I''ve seen this approach to data access fail *spectacularly*[1] so I > caution against it any chance I get.I have no choice. Some of these stored procedures are pages long and incorporate arcane business rules that even I can''t decipher. I have a guarantee from the DBAs that I can specify the paramters and fields of an SP and they will implement what I want. They will not guarantee that tables will not change on a whim.> It sounds like you''re trying to clone ASP.NET development with rails,Not intending to.> perhaps you''re better off staying with ASP.NET. Again, what''s your > motivation for switching?No switching involved. However, every time I work on an ASP.Net project I start feeling as if some brain-dampening-field has been activated.> Perhaps you can compromise some of those > points above?They are basically condensed from the business requirements. xev
If you''re coming from an ASP.NET perspective, you might want take a look at my blog where I am starting to discuss some differences between both platforms: http://dema.ruby.com.br/ rgds Dema Xevious wrote:> Michael Koziarski wrote: > >> I take it from your points below that you''re currently an ASP.NET >> shop? > > > Not really. A previous developer mocked up some code with a tree and > datagrid in ASP.Net, but there isn''t existing codebase. > >> As much as I love rails, why are you considering switching? What''s >> the driver here? > > > My choices are Ruby (Rails, Nitro, or Iowa), Python (CherryPy), > Java (J2EE, EJB), or ASP.Net. > > I''m not into XP, but I would like to have an agile development > process (which I had years ago with Ruby). > > What little ASP.Net I have done has been slow and painful. > > If I''m going to do in it Python, I might as well do it in Ruby > and enjoy myself instead. > > I would do it in ASP.Net before Java - not because I dislike > Java - I am just for current in ASP.Net. > >> Crystal is years ahead of anything I''ve seen in rails as far as >> reporting goes. You can construct nice reporting frontends in rails, >> but you''ll lose all the fancy report designers you get with Crystal / >> Webobjects. > > > The substance of the reports will come entirely from stored procedures. > For presentation I will probably generate PDFs. Or just some really > clean HTML. > >> We''ve got stacks of Ajax magic, but we *don''t* have a binding / >> datagrid system. > > > Yeah, I''m not looking forward to implementing one. The ASP.Net grids > aren''t really bound either - they just pretend to be. > >> There are a number of session store options which will make them >> accesible to all the web processes. Memcached, Active Record etc. >> The load balancing shouldn''t be an issue. > > > Cool. > > >>> o The ORM needs to be happy with stored procedures (or not used >>> at all). We will never have direct access to even the smallest >>> table. >> >> >> >> Ugh. You''ll be able to execute stored procedures, but you''ll >> instantly lose most of the benefits of Active Record. Personally >> I''ve seen this approach to data access fail *spectacularly*[1] so I >> caution against it any chance I get. > > > I have no choice. Some of these stored procedures are pages long and > incorporate arcane business rules that even I can''t decipher. > > I have a guarantee from the DBAs that I can specify the paramters and > fields of an SP and they will implement what I want. They will not > guarantee that tables will not change on a whim. > >> It sounds like you''re trying to clone ASP.NET development with rails, > > > Not intending to. > >> perhaps you''re better off staying with ASP.NET. Again, what''s your >> motivation for switching? > > > No switching involved. However, every time I work on an ASP.Net project > I start feeling as if some brain-dampening-field has been activated. > >> Perhaps you can compromise some of those >> points above? > > > They are basically condensed from the business requirements. > > xev
Xevious wrote:> > I am starting a large project and still selecting what > framework to use. > > Rather than ask brand x what is wrong with brand y, I am > more interested in self confession. > > Why would I *not* want to use Rails (compared to Iowa and Nitro).I don''t know much about Iowa and Nitro, but here are some points that I don''t like about rails (with possible solutions): * There is no form validation, only model validation. * Bundled libraries have modifications that aren''t compatible to the original version (TMail, MySQL?). Solution: try to merge the modifications back into the mainline of the library and/or add methods instead of changing the behaviour of existing methods. * You need a seperate set of FastCGI processes for every application on a server. Components are not useful in practice. Solution: move each application into its own module. This would be easy if not for the existing module/components code in routing. * FastCGI processes eat a lot of RAM (15-20 MB). Solution: don''t require() so many libraries by default? (e.g. breakpointer, redcloth) Andreas
hi All, I''ve decided to stop putting any resources into php development at my company and for my clients (who tend to rely on my advice for platforms). I''m using a bit of another thread I saw, which is relevant - I would like to make a final decision in short order about Rails. Given that, I''d like to open a discussion about the available platform options, and what needs to happen with Rails to get it to the point where it''s the best of all the current options. I think the Rails framework design is near flawless - I haven''t found any structural problems or even tiny things I would change. It seems perfect at the moment. So - to the competitors, and what rails lacks:>> My choices are Ruby (Rails, Nitro, or Iowa), Python (CherryPy), >> Java (J2EE, EJB), or ASP.Net.I would add another: twisted / nevow. (http://www.nevow.com) And a summary: .NET - I will not work with microsoft code, it''s inferior and proprietary -Java is slow and expensive to develop -CherryPy does have good ideas but it''s not as good as rails -CherryPy can use Cheetah which I think is a FANTASTIC template engine - rails has a lot to learn from its caching. -Nevow has some extremely sophisticated presentation tools (formless and stan) which are better than rails, but it''s not full-stack like rails. (So you either write SQL or use twisted.enterprise.row which isn''t maintained anything like AR. -Rails: excellent, new, a littler scary for some companies because there are two orders of magitude fewer ruby programmers than php programmers. I''ve been having a discussion with one of the lead developers of binarycloud, whose opinion I respect a great deal. His experience with rails was of initial excitement, followed by some disappointments: -Rails does not have anything like formless (we had formless-like stuff in binarycloud for building forms from definitions - ours are XML, formless defs are pure python. I need to code some chunks with formless to get a better feel for it, but it seems better than binarycloud''s) -Rails doesn''t do caching nearly so well as cheetah or binarycloud -The rails scaffolding is AMAZING and cool but as soon as you want to touch it you lose its benefits. (bad) The solution to this is to change scaffolding to a rake task that generates real, useable files. Scaffold forms should not use tables, imo. My nits: -ActionMailer is cool but it isn''t necessarily trivial to set up - sending email from Rails should be as easy as PHP. -Little bits of immaturity, but I could really care less about those problems if I have the source of the framework and can contribute to it. So: What Rails Needs =========== -Expression syntax for defining inputs (forms, soap methods, XForms, Adobe''s Weird PDF-input format, etc) without mixing the definition in presentation. -A complete library of widgets to render those expressions as HTML (first) and (for example) XForms (later), QT, whatever / everything. We have this in binarycloud for html - they are EXCEEDINGLY useful in production. The best thing about binarycloud is our form and widget system, based on the node system. It just works (tm). But I''d rather have the definitions in ruby, get rid of the XML. We have the notion of ''DateProvider'' in binarycloud for widgets that accept lists or sets - pulldowns, tables etc - I think that could be better and AR would make things more elegant. Widget libraries are hard to implement properly and flexibly, but I can suggest some things: XHTML, CSS for all styling, code for structure. A binarycloud / nevow formless / whatever esque form toolkit is the biggest missing piece in rails, imho. -Much more sophisticated caching. A caveat: I don''t know enough about rails caching to pretend to be an expert... but: binarycloud has an extremely sophisticated caching mechanism which allows developers to cache individual pieces of presentation based on variables in the environment. For example, you can cache a whole page based on request URI, or a small single component from the page that is specific to a user. Rails doesn''t appear to have that capability like binarycloud (using smarty) does in PHP. I''d like to see it - it would probably increase the requests / sec benchmarks for rails by 2-500%. -Scaffolding needs to be a command-line request that generates files that I can modify. (This should be easy) Some other notes:>>>> o The ORM needs to be happy with stored procedures (or not used >>>> at all). We will never have direct access to even the smallest >>>> table. >>> Ugh. You''ll be able to execute stored procedures, but you''ll >>> instantly lose most of the benefits of Active Record. Personally >>> I''ve seen this approach to data access fail *spectacularly*[1] so I >>> caution against it any chance I get.ActiveRecord is very cool, I would like to see it expanded to handle these complex situations without making the simple stuff more complex :) best, _alex -- alex black, founder the turing studio, inc. enigma-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org http://www.turingstudio.com (whew, time for a redesign -- almost done )
On 5/15/05, alex black <enigma-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org> wrote:> -The rails scaffolding is AMAZING and cool but as soon as you want to > touch it you lose its benefits. (bad) The solution to this is to change > scaffolding to a rake task that generates real, useable files. Scaffold > forms should not use tables, imo.scaffolding can generate real usable files. script/generate scaffold Foos Will create scaffolding for Foo.
>> touch it you lose its benefits. (bad) The solution to this is to change >> scaffolding to a rake task that generates real, useable files. Scaffold >> forms should not use tables, imo. > > scaffolding can generate real usable files. > > script/generate scaffold Foos > > Will create scaffolding for Foo.ah COOL, danke danke :) check that one off the list - what do you think about the form definitions and caching? _a
alex black wrote:>>>My choices are Ruby (Rails, Nitro, or Iowa), Python (CherryPy), >>>Java (J2EE, EJB), or ASP.Net. > > > I would add another: twisted / nevow. (http://www.nevow.com)This is quite intriguing. One inconsistency I see here is the scope of these choices. CherryPy and Nevow seem to be more "toolkit" in scope. J2EE and .NET are more "platform" in scope. There are hundreds of "toolkit" applications built on top of J2EE and .NET. I find Rails to be a bit more than a simple toolkit, but not quite a complete platform on its own. I''m currently making my own comparison, between Rails, Castle(.NET) and some Java framework (Hibernate or EJB3 with Spring, Tapestry, WebWork or Struts).> A binarycloud / nevow formless / whatever esque form toolkit is the > biggest missing piece in rails, imho.I''m not up-to-speed on what ActionPack / Ruby have in place already, but I would agree that some explicit widgets would be a nice *addition*. The problem with widget-only solutions is that it''s hard to be flexible enough to please enough people.> > -Much more sophisticated caching. A caveat: I don''t know enough about > rails caching to pretend to be an expert+1 to that. Excellent ideas, Alex. Cheers, Kevin ---------- Scanned for viruses by ClamAV
> This is quite intriguing. One inconsistency I see here is the scope of > these choices. CherryPy and Nevow seem to be more "toolkit" in scope. > J2EE and .NET are more "platform" in scope. There are hundreds of > "toolkit" applications built on top of J2EE and .NET.Yep. Whether my decision to chuck Java and .NET out the window is correct should be up to the reader to decide - but it''s basically down to Nevow / Twisted and Rails for me. I''m using rails in a couple projects now, I will use twisted / nevow in a test soon.> I find Rails to be a bit more than a simple toolkit, but not quite a > complete platform on its own.Right.> I''m not up-to-speed on what ActionPack / Ruby have in place already, but > I would agree that some explicit widgets would be a nice *addition*. > The problem with widget-only solutions is that it''s hard to be flexible > enough to please enough people.I think we found that balance in binarycloud, and we might well port the form building packages to rails. They just... worked. Very well.>> -Much more sophisticated caching. A caveat: I don''t know enough about >> rails caching to pretend to be an expert > +1 to that.Yeah, this is a biggie. Rails caching is nearly nonexistant. Nevow will shortly have _extremely_ sophisticated caching, I''m talking to them on #twisted.web (freenode) right now.> Excellent ideas, Alex.I put a lot of effort into bc, and we collectively came up with a lot of really good ideas. The language choice was unfortunate, but hey. So I''d like to pick a platform, improve it with what''s good from bc that the platform is missing, and port all of my good app-proto designs to that platform. Now it''s just the choice. It''s a serious competition: rails has a lot of buzz, but when I get right down to it I need the best _code_. Nevow has a lot to offer, and it''s axctually easier to find py people than ruby people. In any case, I''m going to make a final decision based on capabilities and flexibility. _a
> > I''m not up-to-speed on what ActionPack / Ruby have in place already, but > > I would agree that some explicit widgets would be a nice *addition*. > > The problem with widget-only solutions is that it''s hard to be flexible > > enough to please enough people. > > I think we found that balance in binarycloud, and we might well port the > form building packages to rails. They just... worked. Very well.I am curious ... what features can be attained from an explicit form-building framework that can''t be done in Rails now? Is it the separation of form elements from their layout, as an example? I have not run into too many problems with the Rails approach ... I think it does exactly what I want from a form framework without the form framework, but possibly I am missing something, since I am still new to Rails. Brian
>> I think we found that balance in binarycloud, and we might well port the >> form building packages to rails. They just... worked. Very well. > > I am curious ... what features can be attained from an explicit > form-building framework that can''t be done in Rails now? Is it the > separation of form elements from their layout, as an example? I have not > run into too many problems with the Rails approach ... I think it does > exactly what I want from a form framework without the form framework, > but possibly I am missing something, since I am still new to Rails.What we found works best were little isolated widgets that took care of themselves within a larger form context. You express what you want the structure of the form to be, and hand that structure off to a component that uses your templates to render a form. That, or you simple provide macros which can be used in a layout template (something which I found works quite well): <form> <h1>My Form title</h1> #{fetch_cms_content_for_language(my_form_title_intro)} <div class="form_errors"> <h2>Sorry, there were problems with your input</h2> <ul> <li>Error description</li> <li>Error description</li> <li>Error description</li> </ul> </div> <div class="form_element form_element_required form_element_has_errors"> <div class="form_element_label">#{element_label}</div> <div class="form_element_input">#{element_input}</div> <div class="form_element_errors">#{element_errors}</div> </div> .. </form> etc. because: -reconstructing view html for each separate language is dumb (this allows you to abstract things like strings into a definition, but you still need view overrides per language if you have iconographic and roman languages mixed on a site) -retyping <input type="text" size="whatever"> 100,000 times is a violation of DRY -building libraries of complex widgets that may return simple values (like a color selector, calendar, etc) is a big time saver when doing lots of app dev (especially if you can refine those widgets with cool rails JS and style them with CSS) -changing forms on a whole site by editing one file is very, very nice. gotta go, _a
On 5/16/05, alex black <enigma-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org> wrote:> Given that, I''d like to open a discussion about the available platform > options, and what needs to happen with Rails to get it to the point where > it''s the best of all the current options.Excellent, nothing gets your concerns listened to like a willingness to contribute ;)> -Expression syntax for defining inputs (forms, soap methods, XForms, > Adobe''s Weird PDF-input format, etc) without mixing the definition in > presentation. > > -A complete library of widgets to render those expressions as HTML (first) > and (for example) XForms (later), QT, whatever / everything. We have this > in binarycloud for html - they are EXCEEDINGLY useful in production. The > best thing about binarycloud is our form and widget system, based on the > node system. It just works (tm). But I''d rather have the definitions in > ruby, get rid of the XML. We have the notion of ''DateProvider'' in > binarycloud for widgets that accept lists or sets - pulldowns, tables etc > - I think that could be better and AR would make things more elegant. > > Widget libraries are hard to implement properly and flexibly, but I can > suggest some things: XHTML, CSS for all styling, code for structure. > > A binarycloud / nevow formless / whatever esque form toolkit is the > biggest missing piece in rails, imho.I''m glad that we don''t have this kind of thing. One of the things that I love about rails is the fact that it doesn''t try to deal in such abstract terms. ActionPack is unashamedly an HTTP/HTML solution, it allows me to build web applications an order of magnitude faster because of this. I don''t have to build a form, then a form renderer, then a form validator etc. etc. etc. Having said all of that, if such a thing could be entirely optional, then what harm could it do? Perhaps we could have a seperate view implementation which works this way?> -Much more sophisticated caching. A caveat: I don''t know enough about > rails caching to pretend to be an expert... but: binarycloud has an > extremely sophisticated caching mechanism which allows developers to cache > individual pieces of presentation based on variables in the environment. > For example, you can cache a whole page based on request URI, or a small > single component from the page that is specific to a user. Rails doesn''t > appear to have that capability like binarycloud (using smarty) does in > PHP. I''d like to see it - it would probably increase the requests / sec > benchmarks for rails by 2-500%.Rails'' caching is fairly decent, but I don''t know enough about it to comment. I do know that a lot of my java work has been ''turn off your silly caching, the DB is fast enough''. Caching is hard, harder than most people realise. But this is probably one area where patches would be gratefully accepted. I''m always skeptical about caching discussions without profiler output & detailed stress testing.> -Scaffolding needs to be a command-line request that generates files that > I can modify. (This should be easy)It''s already there, script/generate scaffold.> Some other notes: > > >>>> o The ORM needs to be happy with stored procedures (or not used > >>>> at all). We will never have direct access to even the smallest > >>>> table. > >>> Ugh. You''ll be able to execute stored procedures, but you''ll > >>> instantly lose most of the benefits of Active Record. Personally > >>> I''ve seen this approach to data access fail *spectacularly*[1] so I > >>> caution against it any chance I get. > > ActiveRecord is very cool, I would like to see it expanded to handle these > complex situations without making the simple stuff more complex :)Given that you''re quoting me here, I think I should respond. I love the fact that AR *doesn''t* handle this kind of situation. Allowing all this kind of stuff to be overridden increases the complexity of the code, and makes it more cumbersome for the 90% of developers who don''t need it. Even Hibernate''s support for stored procedures is extremely weak. One option if you have a super paranoid DBA is for views with triggers on update. If you hide the stored procedures there, perhaps it''ll be ok? If I were once again stuck in a stored-procedure shop I''d probably use the DAO pattern rather than ORM. While there''s more code, and your database access become programmatic rather than ''as-needed'' I think the reduced complexity is worth it. class SQLCustomerDao def load_customer(id) # call procedure # marshall result # return end def save_customer(cust) # marshall into SQL # call procedure # handle Errors end def order_books(customer) # call book_order_procedure # handle errors end end class Customer cattr_accessor :dao def self.find(id) dao.load_customer(id) end def save Customer.dao.save_customer(this) end end Then to work with test implementations you can just go: Customer.dao= TestCustomerDao If someone can come up with a non-intrusive solution that works for stored procedures, then great. But handling this kind of thing with a non-trivial object graph gets really hard really quickly and I''d always recommend either: 1) Ditch the stored procedures, or 2) Switch to DAOs. -- Cheers Koz
Michael Koziarski wrote:> I love the fact that AR *doesn''t* handle this kind of situation. > Allowing all this kind of stuff to be overridden increases the > complexity of the code, and makes it more cumbersome for the 90% of > developers who don''t need it. Even Hibernate''s support for stored > procedures is extremely weak. > > One option if you have a super paranoid DBA is for views with triggers > on update. If you hide the stored procedures there, perhaps it''ll be > ok?In my situation, I have little control over the data. The DBAs own the databases. They are required to give me an interface to the data in the form of stored procedures - nothing more. The DBAs are members of the IT Operations dept (as opposed to development) and they have no incentive to make the developers lives easier. Any Rails code would live in the DMZ and I am not sure that I want business logic living in the DMZ. xev
On 5/16/05, Xevious <xevious-FgZ1Ih9JkPHx9BLsLxWUfA@public.gmane.org> wrote:> Michael Koziarski wrote: > > > I love the fact that AR *doesn''t* handle this kind of situation. > > Allowing all this kind of stuff to be overridden increases the > > complexity of the code, and makes it more cumbersome for the 90% of > > developers who don''t need it. Even Hibernate''s support for stored > > procedures is extremely weak. > > > > One option if you have a super paranoid DBA is for views with triggers > > on update. If you hide the stored procedures there, perhaps it''ll be > > ok? > > In my situation, I have little control over the data. The DBAs > own the databases. They are required to give me an interface to > the data in the form of stored procedures - nothing more. The > DBAs are members of the IT Operations dept (as opposed to development) > and they have no incentive to make the developers lives easier.I''ve been here and you have my sympathy. I''d definitely recommend you take a DAO approach rather than try and build support into active record to handle these cases. You can still include a lot of AR''s functionality as a lot of it lives in Modules which are ''relatively'' de coupled from ActiveRecord::Base.> Any Rails code would live in the DMZ and I am not sure that I want > business logic living in the DMZ.If your application contains no logic, what exactly does it do? ;) I can see where you''re coming from though.> xev > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
Michael Koziarski wrote:>>Any Rails code would live in the DMZ and I am not sure that I want >>business logic living in the DMZ. >> >> > >If your application contains no logic, what exactly does it do? ;) I >can see where you''re coming from though. > >Business logic => model. A lot of web applications don''t have any business logic beyond store/retrieve data. Most of the web applications are presentation (view) and user interaction/fetching data from model (controller). - Adam
Michael Koziarski wrote:> If your application contains no logic, what exactly does it do? ;) I > can see where you''re coming from though.Yeah, I am not sure that web applications are the place for business logic in general. Validation logic, perhaps. This is one of the things that concerns me about Rails. I really want to see Ruby move more into the mainstream and I love the attention that Rails is bringing to Ruby. However, I don''t see Rails helping position Ruby as an enterprise (there is that e-word again) solution when serious web apps need more than just simple CRUD ORM. That is, consider a customer modifying an EDI transaction that is responible for the transfer of a few million dollars. This could result in dozens of tables being modified on multiple servers. It is not rational to believe that any IT VP of a large corporation is going to be happy to find out that someone is doing this on a table by table basis from within a web application. Now, touching on the business logic in the DMZ - which makes more sense: To validate a user by calling a stored procedure (on a server *not* in the DMZ) and passing it userID and passWord? Or, validate it in Ruby code and ORM? In the first scenario, if an attacker makes it onto the DMZ, they can try a dictionary attack by calling the validateUser store procedure. This will not be very productive as all sort of alarms will go off and the SP will start delaying its responses. In the second scenario, the attacker can read the entire users table and attack the hashes at leisure. In my opinion, that is the sort of thing that needs taken into consideration before big corps view Rails as more than a blog, photo-album, and todo-list generator. (an oversimplification) xev
On 5/16/05, Xevious <xevious-FgZ1Ih9JkPHx9BLsLxWUfA@public.gmane.org> wrote:> Michael Koziarski wrote: > > > If your application contains no logic, what exactly does it do? ;) I > > can see where you''re coming from though. > > Yeah, I am not sure that web applications are the place for > business logic in general. > > Validation logic, perhaps. > > This is one of the things that concerns me about Rails. I really > want to see Ruby move more into the mainstream and I love the > attention that Rails is bringing to Ruby. > > However, I don''t see Rails helping position Ruby as an enterprise > (there is that e-word again) solution when serious web apps need > more than just simple CRUD ORM.I really think that you''re missing the point here. The *reason* that rails is so simple to work with, the reason that you can save so much time, and so much money is that it''s focused on building web applications. I''ll admit I''m currently jaded. But to me, ''Enterprise'' development is just a fancy way of saying "over complicated software with shitty legacy systems & negative ROI". </rant> ;)> That is, consider a customer modifying an EDI transaction that is > responible for the transfer of a few million dollars. This could > result in dozens of tables being modified on multiple servers. It > is not rational to believe that any IT VP of a large corporation > is going to be happy to find out that someone is doing this on a > table by table basis from within a web application.If rails ever tries to solve this kind of problem it will have overshot the ''sweet spot'' it currently occupies and become just as complicated as the current J2EE/CICS/COBOL frameworks. By way of clarification, I currently work for a pretty large bank and we deal with serious sums of money. I''ve worked for a few of these banks now, and the an international casino chain. In all those cases, there was *dedicated middleware* handling these kinds of transactions, not stored procedures. Stored Procedures *suck* at updating "dozens of tables ... on multiple servers", some kind of middleware will do a much better job. The ''vendors'' currently call this ESB or SOA, but in reality all you''re talking about is a place to send requests and get answers, you don''t need Websphere Process Choreographer to do this. Ruby has great libraries for calling web services, REST or SOAP. However web services are the ultimate ''buzz word'' right now, and for key enterprise services you probably want two phase commit, the CICS / MQ libraries for ruby are either non-existent or lacking. Perhaps that''s an area that could impact on enterprise adoption?> Now, touching on the business logic in the DMZ - which makes more > sense: To validate a user by calling a stored procedure (on a server > *not* in the DMZ) and passing it userID and passWord? > > Or, validate it in Ruby code and ORM? > > In the first scenario, if an attacker makes it onto the DMZ, they can > try a dictionary attack by calling the validateUser store procedure. > This will not be very productive as all sort of alarms will go off > and the SP will start delaying its responses. > > In the second scenario, the attacker can read the entire users table > and attack the hashes at leisure.This example is fairly contrived, I''ve yet to find a large organisation which still builds login solutions for each application. Most/all of them have undertaken an ''Identity Management'' project of some sort and converged on a big LDAP database.> In my opinion, that is the sort of thing that needs taken into > consideration before big corps view Rails as more than a blog, > photo-album, and todo-list generator. (an oversimplification)Stored Procedures are a total non-issue. Just use DAOs. If you''re really building ''big-iron'' applications, you want common enterprise services for key functionality like: * Authenticating Users * Listing their Authorisation Rights (roles) * Creating a Transaction But all of this is beside the point that a key strength rails has it that it *doesn''t* try to solve all these problems. This is a disruptive innovation http://www.loudthinking.com/arc/000412.html David''s slayed a few sacred cows, and stored procedures are one of them ;) Having said that, there''s nothing tying you to ActiveRecord with your rails applications. You can build something with ActionPack, ActionMailer & ruby-dbi. You''ll just miss out on a few nice features. If you start building your applications this way you may be able to extract your code into some useful library that could be used as a drop-in replacement for ActiveRecord... ActionStoredProcedurePersistance? -- Cheers Koz PS. Nothing I say here is any form of endorsement from my employer or any former employers
Xevious wrote:> In the first scenario, if an attacker makes it onto the DMZ, they can > try a dictionary attack by calling the validateUser store procedure. > This will not be very productive as all sort of alarms will go off > and the SP will start delaying its responses. > > In the second scenario, the attacker can read the entire users table > and attack the hashes at leisure. > > > In my opinion, that is the sort of thing that needs taken into > consideration before big corps view Rails as more than a blog, > photo-album, and todo-list generator. (an oversimplification)Your points are valid, yet they are moot when it comes to RoR. RoR is a tool. You *can* build your business logic into the web application. You *can* build your business logic as a web application. There are advantages and disadvantages to them both, but it is up to you to choose which one you want. ActiveRecord is designed to make building models in the web application easier. But it doesn''t stop you from using your own interface to your application. If all your stuff is in stored procedures, you may easily create a somewhat equivalent to what AR does but for stored procedures. The reason is that Ruby is a dynamic language and defining your own functions based on what a stored procedure returns is easy. Even if you use make your own model interface (ie. not using AR), this doesn''t stop you from using the View and Controller part of Rails. This means you still have your business logic in the DB, but you leave the rendering and user interaction in the DMZ, where it belongs. - Adam
Michael Koziarski wrote:> I''ll admit I''m currently jaded. But to me, ''Enterprise'' development > is just a fancy way of saying "over complicated software with shitty > legacy systems & negative ROI". </rant> ;)That is mostly correct. Unfortunately, a lot of it is still involved in making the world go round.> If rails ever tries to solve this kind of problem it will have > overshot the ''sweet spot'' it currently occupies and become just as > complicated as the current J2EE/CICS/COBOL frameworks.If it doesn''t, then what? We should recommend that people use Java for large and complex apps?> By way of clarification, I currently work for a pretty large bank and > we deal with serious sums of money. I''ve worked for a few of these > banks now, and the an international casino chain. In all those > cases, there was *dedicated middleware* handling these kinds of > transactions, not stored procedures. > > Stored Procedures *suck* at updating "dozens of tables ... on multiple > servers", some kind of middleware will do a much better job. The > ''vendors'' currently call this ESB or SOA, but in reality all you''re > talking about is a place to send requests and get answers, you don''t > need Websphere Process Choreographer to do this.I think stored procedures suck and I have written my share of TSQL. However, our DBAs seem to have had no trouble implementing transactions (and rollbacks) over linked servers. (Over 500GB of online data - WooHoo!) In our case, the SPs *are* the dedicated middleware. I have considered writing web services for all the SPs in C# just to get rid of some type issues I have experienced with the Ruby SQLServer DBI.> This example is fairly contrived, I''ve yet to find a large > organisation which still builds login solutions for each application. > Most/all of them have undertaken an ''Identity Management'' project of > some sort and converged on a big LDAP database.And, you have answered the contrived portion rather than address the underlying issue that allowing full CRUD from the DMZ is *bad*. (As a sidenote - we use Active Directory for auth, but are trying to avoid it in this project.)> Stored Procedures are a total non-issue. Just use DAOs.I think an extension to AR that uses web services would be good. Rather than specify a DB and table, instead specify a web service prefix name. "Employees" looks for employee-c, -r, -u, and -d. Or something like that. (I need more sleep) -good stuff snipped-> But all of this is beside the point that a key strength rails has it > that it *doesn''t* try to solve all these problems.And, that is one of the problems for me. Of the things that Rails provides, those that I need (State management, templating, programatic html generation, and DB (or web service) interface) can be obtained in a number of different ways. > This is a disruptive innovation It could be. I am not willing to say that yet. Please don''t misunderstand - I think Rails is one of the neatest things since sliced bread. At the same time, I may be more jaded than you. :) I seen so much tech hyped in the last 20 years... Remember, Java was supposed to be controlling our microwave ovens by now. Humans have nasty habit - even when trying not to - of misapplying new tech and paradigms. (latest example - MS trying to pretend that web development is just like desktop development ala VS.) xev
On 5/16/05, Xevious <xevious-FgZ1Ih9JkPHx9BLsLxWUfA@public.gmane.org> wrote:> Michael Koziarski wrote: > > > I''ll admit I''m currently jaded. But to me, ''Enterprise'' development > > is just a fancy way of saying "over complicated software with shitty > > legacy systems & negative ROI". </rant> ;) > > That is mostly correct. Unfortunately, a lot of it is still involved > in making the world go round. > > > If rails ever tries to solve this kind of problem it will have > > overshot the ''sweet spot'' it currently occupies and become just as > > complicated as the current J2EE/CICS/COBOL frameworks. > > If it doesn''t, then what? We should recommend that people use > Java for large and complex apps?Each decision depends on the requirements, but yes, there are some cases where Java makes much more sense than rails. In overall terms it''s the minority of applications, the market for simpler applications is much larger, but less ''buzz word'' filled.> And, you have answered the contrived portion rather than address the > underlying issue that allowing full CRUD from the DMZ is *bad*.You''re right, I should''ve been more explicit. I''d view this ''compromised host'' situation as fairly rare, most of the data won''t be in this class importance. For the secure data, I''d use some common service, if stored procedures are all you have, then so be it. Do the authentication with this, if that succeeds then just query the tables/view for all the other properties. Just hide the passwords from the web user.> I think an extension to AR that uses web services would be good. > Rather than specify a DB and table, instead specify a web service > prefix name. "Employees" looks for employee-c, -r, -u, and -d. > Or something like that. (I need more sleep)Rather than Extension to AR, perhaps an alternative to it? That way the lucky ones without our ''enterprise'' requirements build simple apps, and those who need to put in the extra work?> And, that is one of the problems for me. Of the things that > Rails provides, those that I need (State management, templating, > programatic html generation, and DB (or web service) interface) > can be obtained in a number of different ways. > > Please don''t misunderstand - I think Rails is one of the neatest > things since sliced bread.So do I, that''s why I started contributing. I think a lot of what you''re trying to achieve is wtill possible with ''rails'', you''ll just have to implement your own model layer. That''ll still be less work than a lot of other frameworks. Plus you may even be able to extract your implementation into a support library, helping others in your situation.> At the same time, I may be more jaded > than you. :)That''d be pretty hard, but not impossible ;) -- Cheers Koz
Xevious escreveu:> My choices are Ruby (Rails, Nitro, or Iowa), Python (CherryPy), > Java (J2EE, EJB), or ASP.Net.Java (J2EE, EJB). If you go to java route stay away from EJB. I''m standing before a crossroads. Two options in my case: Java: Tapestry (Web Components), Hibernate(good orm, accept stored procs), Spring (makes java less painfull) Ruby: Rails (Firebird is not supported like MySql and Postgres), I''m a little bit reluctant of putting bussiness rules in a dynamic typed language. Geraldo Lopes de Souza
> Ruby: Rails (Firebird is not supported like MySql and Postgres), > I''m a little bit reluctant of putting bussiness rules in a > dynamic typed language.Why is that?
On 5/16/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Ruby: Rails (Firebird is not supported like MySql and Postgres), > > I''m a little bit reluctant of putting bussiness rules in a > > dynamic typed language. > > Why is that?One possible reason: it''s much more difficult to extract business rules from Ruby than it is from rules stored in a database--a concern when it''s time to migrate to an application to a new framework. -- "Thanks to the crew of rocketscientists.ca for the gmail invitation!" http://www.rocketscientists.ca/ _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Tomas Jogin escreveu:>>Ruby: Rails (Firebird is not supported like MySql and Postgres), >> I''m a little bit reluctant of putting bussiness rules in a >>dynamic typed language. > > > Why is that?When you put rules in a static typed language you have the compiler to help you refactor the system. Of course the application is not free from bugs by just compiling, but at least the compiler helps you saying . With dynamic typed languages you need to write test always, and there are times that you don''t have time to test the system. This type of modification are in my opinion best achieved with static typed language. I know it''s a trade-off matter. Java: much more verbose, compiler is your friend when modificating the system. Eclipse free ide that helps refactor. IMHO java is just acceptable because the ide''s. Without them you have to work like a slave. Ruby: very expressive, cohesive language. With rails you have productivity. Lower entry for new programmers. But you''re obrigated to test every code you make. Maybe by writing code more quickly you get the time needed to write tests. I''m trying to make time to start a test application with rails to see what happens. Geraldo Lopes de Souza
> With dynamic typed languages you need to write test always, and there > are times that you don''t have time to test the system. This type of > modification are in my opinion best achieved with static typed language.Compile time checking is not a replacement for unit tests. You should have unit tests regardless of the environment you work in. I''d rather write my tests in Rails than C# any day. -- rick http://techno-weenie.net
Rick Olson escreveu:> > Compile time checking is not a replacement for unit tests. You should > have unit tests regardless of the environment you work in. I''d rather > write my tests in Rails than C# any day.In theory that works very well, but my point is that with real world applications sometimes you have no time to write tests. Geraldo Lopes de Souza
On 5/16/05, Geraldo Lopes de Souza <geraldo-lopes-I4oVjbygTnVfyO9Q7EP/yw@public.gmane.org> wrote:> In theory that works very well, but my point is that with real world > applications sometimes you have no time to write tests.There''s _always_ time to write tests. Not writing tests is laziness, pure and simple (an misguided laziness at that, since tests generally _save_ you time in the long run.) I sure hope you don''t work on pacemakers or space-shuttles. -- Regards, John Wilger ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland
John Wilger escreveu:> > There''s _always_ time to write tests. Not writing tests is laziness, > pure and simple (an misguided laziness at that, since tests generally > _save_ you time in the long run.) > > I sure hope you don''t work on pacemakers or space-shuttles. >I was expecting this kind of reaction. I''m not lazy guy for sure. Assuming a Jeronimo Savonarola (Write tests or burn in hell) attitude is very easy. Geraldo Lopes de Souza
> Assuming a Jeronimo Savonarola (Write tests or burn in hell) attitude is > very easy.Just like assuming a "i dont have time to test" attitude?
On 5/16/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Assuming a Jeronimo Savonarola (Write tests or burn in hell) attitude is > > very easy. > Just like assuming a "i dont have time to test" attitude?What about a "I don''t have time to learn to write effective tests" attitude? Unit tests seem pretty simple to create, but functional tests have been much more of a problem for me. - Dennis -- "Thanks to the crew of rocketscientists.ca for the gmail invitation!" http://www.rocketscientists.ca/
Tomas Jogin escreveu:>>Assuming a Jeronimo Savonarola (Write tests or burn in hell) attitude is >>very easy. > > Just like assuming a "i dont have time to test" attitude?No. I don''t think testing is evil. I think that it must to be done. I just think that when you can''t (for some reason) write test, you''re in better place with a static typed language, than a dynamic typed one. Plain simple, just an opinion. Geraldo Lopes de Souza
2005/5/16, Geraldo Lopes de Souza <geraldo-lopes-I4oVjbygTnVfyO9Q7EP/yw@public.gmane.org>:> In theory that works very well, but my point is that with real world > applications sometimes you have no time to write tests.I''m not agree... expecially in big projects tests (unit, functional, whatever) are a "must" read these: http://www.artima.com/weblogs/viewpost.jsp?thread=7588 http://www.oluyede.org/blog/2004/07/13/debugging-and-net/ -- Lawrence http://www.oluyede.org/blog
2005/5/16, Geraldo Lopes de Souza <geraldo-lopes-I4oVjbygTnVfyO9Q7EP/yw@public.gmane.org>:> No. I don''t think testing is evil. I think that it must to be done. > I just think that when you can''t (for some reason) write test, you''re in > better place with a static typed language, than a dynamic typed one.Understood, but in Python is use things like pychecker/pylint (don''t know much about the counterparts in Ruby) -- Lawrence http://www.oluyede.org/blog
On 5/16/05, Geraldo Lopes de Souza <geraldo-lopes-I4oVjbygTnVfyO9Q7EP/yw@public.gmane.org> wrote:> John Wilger escreveu: > > > > There''s _always_ time to write tests. Not writing tests is laziness, > > pure and simple (an misguided laziness at that, since tests generally > > _save_ you time in the long run.) > > > > I sure hope you don''t work on pacemakers or space-shuttles. > > > I was expecting this kind of reaction. I''m not lazy guy for sure.Ugh. Sorry to come off so harsh. Hadn''t had my caffeine yet when I posted that! ;-) -- Regards, John Wilger ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland
> Excellent, nothing gets your concerns listened to like a willingness > to contribute ;)Heh, yep...>> Widget libraries are hard to implement properly and flexibly, but I >> can >> suggest some things: XHTML, CSS for all styling, code for structure. >> >> A binarycloud / nevow formless / whatever esque form toolkit is the >> biggest missing piece in rails, imho. > > I''m glad that we don''t have this kind of thing. One of the things > that I love about rails is the fact that it doesn''t try to deal in > such abstract terms. ActionPack is unashamedly an HTTP/HTML > solution, it allows me to build web applications an order of > magnitude faster because of this.I''m not proposing that QT or XForms suddenly become a priority, I''m just suggesting that they are _possibilities_ with an expression format. In a way it''s a way to publish a model method to the outside world, obviously that exists to some extent in rails but it''s not ''unified'' I like DRY, I use it. I think rewriting <input type="text" size="30" maxlength="220" /> 500 times in an application very... dumb. :) At minimum I''d like to be able to do something to the effect of: <% output_my_widget(name) %> where that ''name'' is a small definition like: input text size = 20 maxlength = blah for = model.field etc... obviously I would need to collect my thoughts after I''m a bit more experienced with erb and rails - but that''s the basic idea. so _at minimum_ I am suggesting a collection of flexible widgets, at maximum I''m suggesting an input set expression format which can be use by scaffold to generate simple forms with those widgets.> I don''t have to build a form, then a form renderer, then a form > validator etc. etc. etc.Hm, reuseable, encapsulated validation code is a VERY food thing. I like the way AR does it, I haven''t tried to extend it, but I want to be able to say "run this through a regex" or "verify that this data is in FASTA format" etc. http://ngfnblast.gbf.de/docs/fasta.html> Having said all of that, if such a thing could be entirely optional, > then what harm could it do? Perhaps we could have a seperate view > implementation which works this way?Sorta, I would imagine it as just something one uses in normal views. Just more efficient tools. And if you don''t like them, you don''t use them - just like actionpack.> Rails'' caching is fairly decent, but I don''t know enough about it to > comment.I don''t really either - does anyone watching this thread really know? :)> I do know that a lot of my java work has been ''turn off your > silly caching, the DB is fast enough''.Hm. Faster is always better for my clients :)> Caching is hard, harder than > most people realise.Really - if it''s integrated into the framework and it''s per-object then it really isn''t that hard. binarycloud''s caching is pretty easy to understand. I''d like to see individual views cached based on the environment, i.e. one can specify: "cache one copy of this regardless of the environment" "cache one copy of this per session id" "cache one copy of this per URI" ... "cache one copy of this per URI and per session ID" basically you need to know: -does this change per location -is this ''personalized'' content for the user?> I''m always skeptical about caching discussions without profiler output > & detailed stress testing.All you need to do is look at development.log, and it will tell you how many requests per second it will handle for a given page - and rails is slow.> It''s already there, script/generate scaffold.Yeah, someone else corrected me - thanks :)> I love the fact that AR *doesn''t* handle this kind of situation. > Allowing all this kind of stuff to be overridden increases the > complexity of the code, and makes it more cumbersome for the 90% of > developers who don''t need it. Even Hibernate''s support for stored > procedures is extremely weak.I''m not suggesting that AR should be extended into a frankenstein hibernate. PHP is a great example of badly emulating something else. That said - composite keys aren''t really that rare.> One option if you have a super paranoid DBA is for views with triggers > on update. If you hide the stored procedures there, perhaps it''ll be > ok?Yep, not a bad idea. I don''t use stored procedures extensively, and I don''t expose them to the app.> class SQLCustomerDao > def load_customer(id) > # call procedure > # marshall result > # return > endYep - DAOs work really well. best, _alex -- alex black, founder the turing studio, inc. 510.666.0074 root-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710
alex black wrote:> I like DRY, I use it. I think rewriting <input type="text" size="30" > maxlength="220" /> 500 times in an application very... dumb. :) > > At minimum I''d like to be able to do something to the effect of: > > <% output_my_widget(name) %> > > where that ''name'' is a small definition like: > > input > text > size = 20 > maxlength = blah > for = model.field > > etc...The irony. Or maybe it is the revolving wheel of history. I wrote a similar widget library for Python around 5 years ago and then rewrote it for Ruby a few months later. All html constructs were implemented as objects. Then the widgets were built from those objects. Elegant and versatile handling of collections... It was pretty. xev
> The irony. Or maybe it is the revolving wheel of history. > > I wrote a similar widget library for Python around 5 years > ago and then rewrote it for Ruby a few months later. > > All html constructs were implemented as objects. Then the widgets > were built from those objects. Elegant and versatile handling > of collections... It was pretty.Cool - do you still have the code? I''m planning to port the binarycloud widget library to rails, but why do it if the code already exists ? :) best, _alex -- alex black, founder the turing studio, inc. 510.666.0074 root-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710
alex black wrote:> Cool - do you still have the code?Yes. Not that it helps. IIRC, it is encrypted with a PGP key that I no longer have. Also, it was written on company time and was not authorised to be released. xev
Xevious wrote:> alex black wrote: > >> I like DRY, I use it. I think rewriting <input type="text" size="30" >> maxlength="220" /> 500 times in an application very... dumb. :) >> >> At minimum I''d like to be able to do something to the effect of: >> >> <% output_my_widget(name) %> >> >> where that ''name'' is a small definition like: >> >> input >> text >> size = 20 >> maxlength = blah >> for = model.field >> >> etc... > > > The irony. Or maybe it is the revolving wheel of history. > > I wrote a similar widget library for Python around 5 years > ago and then rewrote it for Ruby a few months later. > > All html constructs were implemented as objects. Then the widgets > were built from those objects. Elegant and versatile handling > of collections... It was pretty. > > xevCheck out the ActionView::Helpers module. It''s in the rails api documentation at http://api.rubyonrails.com. Specifically ActionView::Helpers::FormHelper contains the widgets mentioned above (for example: textfield). If you use the "script/generate scaffold" command you''ll find that scaffold uses these widgets in the files generated in the app/views directory. Best regards, Bas
On 5/16/05, Bas van Klinkenberg <lists-JQ6x5Nlb7DGNzEXqMhSRc45ogaMWVTX7Zkel5v8DVj8@public.gmane.org> wrote:> Xevious wrote: > > alex black wrote: > >> I like DRY, I use it. I think rewriting <input type="text" size="30" > >> maxlength="220" /> 500 times in an application very... dumb. :) > >> > >> At minimum I''d like to be able to do something to the effect of: > >> > >> <% output_my_widget(name) %> > >> > >> where that ''name'' is a small definition like: > >> > >> input > >> text > >> size = 20 > >> maxlength = blah > >> for = model.field > >> > >> etc... > > > > > > The irony. Or maybe it is the revolving wheel of history. > > > > I wrote a similar widget library for Python around 5 years > > ago and then rewrote it for Ruby a few months later. > > > > All html constructs were implemented as objects. Then the widgets > > were built from those objects. Elegant and versatile handling > > of collections... It was pretty. > > > > xev > > Check out the ActionView::Helpers module. It''s in the rails api > documentation at http://api.rubyonrails.com. > Specifically ActionView::Helpers::FormHelper contains the widgets > mentioned above (for example: textfield). > If you use the "script/generate scaffold" command you''ll find that > scaffold uses these widgets in the files generated in the app/views > directory.Yes, and the existing helper widgets are automatically created from an existing object in your model (you specify the name on widget creation) containing information from the fields if it has any, or displaying the field blank otherwise. This means that the same form can be reused for both creation and editing, *and* that when the form refreshes because of errors, all of the data is still there. I love this. I agree -- check out some scaffold code for seeing how this is done with partials.> Best regards, > BasSincerely, Tom Reinhart tom-V0YqjHVuocLQT0dZR+AlfA@public.gmane.org http://AllTom.com/
Alex, I''m not sure if it''s been communicated or not... but my understanding is that when Rails runs in "Development Mode", there is _no_ caching being done at all. This allows the developer to not worry about whether data is cached (especially when debugging a problem). You may want to check Rails'' caching abilities in a Production environment. HTH! On 5/16/05, alex black <enigma-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org> wrote:> All you need to do is look at development.log, and it will tell you how > many requests per second it will handle for a given page - and rails is > slow.-- - Frank FrankManno.com <a href="http://www.spreadfirefox.com/?q=affiliates&id=2496&t=1">Get Firefox!</a>