Hi, I am developing a larger scale application with rails to manage our businesses crm, order processing, catalogue, stock control, service jobs etc. Logically the application has distinct modules or sections of functionality. As you can imagine there are also many cross cutting dependencies between the areas of functionality. Initially I have considered breaking it into ruby modules, primarily grouping application controllers into areas of functionality. As a guide, in terms of number features and screens I would say it will easily exceed any of the 37signals products I use. I could equate it to rolling basecamp, highrise and campfire into one application. I was hoping someone might share experience of a rails app of a larger size, or specifically how they structured the application to avoid a confusing mass of controllers and actions. Regards, Andrew Edwards -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 4/18/07, Andrew Edwards <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I am developing a larger scale application with rails to manage our > businesses crm, order processing, catalogue, stock control, service jobs > etc.Define ''large''. Do you mean large amounts of functionality, large amount of registered users or high volume of read traffic? (or even write traffic). If its low-user base, but lots of functionality, you could do it in camping even. If the various silos of functionality need to be integrated in some way, then thats something very different.> I was hoping someone might share experience of a rails app of a larger > size, or specifically how they structured the application to avoid a > confusing mass of controllers and actions.You start by thinking about your Models and Views first. If this data is not coming from a database, you need to consider why you are using Rails even - database-driven is implicit. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Richard Conroy wrote:> > Define ''large''. > > Do you mean large amounts of functionality, large amount of registered > users or high volume of read traffic? (or even write traffic). > > If its low-user base, but lots of functionality, you could do it in > camping > even. > > If the various silos of functionality need to be integrated in some way, > then thats something very different. >Sorry, I was referring to large amounts of functionality. It is an internal application with a limited number of users. I haven''t checked camping but will look into it. I had originally intended using java with the spring framework & hibernate. However I found I was making poor headway using my mix of agile/homebrew methods. Small changes in direction often needed major refactoring and multiple updates to code and config. So far my attempts with rails are looking good. However from experience I can see things getting harder to maintain as I add more managed entities and features.>> I was hoping someone might share experience of a rails app of a larger >> size, or specifically how they structured the application to avoid a >> confusing mass of controllers and actions. > > You start by thinking about your Models and Views first. > If this data is not coming from a database, you need to consider why > you are using Rails even - database-driven is implicit.The entire application is database driven. I think I should spend more time looking towards user views. Hopefully this may more logically separate the application for me. Thanks, Andrew. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
If you can focus on what your users do and build your application from that perspective, you will be fine. Each entity (noun) in your system has a model, and that''s where your business rules should be.. It''s the user interface that separates the functionality. You can take that a step further by treating your domain model as RESTful resources, where you typically have a controller for each model. This sort of eliminates complex design in terms of controllers, cos you just know how to add a record to your database. Sorting things at the UI is a bit trickier, but you will have that in any language. :) Hope that might help! I''m trying to be as general as possible here. On 4/18/07, Andrew Edwards <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Richard Conroy wrote: > > > > Define ''large''. > > > > Do you mean large amounts of functionality, large amount of registered > > users or high volume of read traffic? (or even write traffic). > > > > If its low-user base, but lots of functionality, you could do it in > > camping > > even. > > > > If the various silos of functionality need to be integrated in some way, > > then thats something very different. > > > > Sorry, I was referring to large amounts of functionality. It is an > internal application with a limited number of users. > > I haven''t checked camping but will look into it. I had originally > intended using java with the spring framework & hibernate. However I > found I was making poor headway using my mix of agile/homebrew methods. > Small changes in direction often needed major refactoring and multiple > updates to code and config. > > So far my attempts with rails are looking good. However from experience > I can see things getting harder to maintain as I add more managed > entities and features. > > >> I was hoping someone might share experience of a rails app of a larger > >> size, or specifically how they structured the application to avoid a > >> confusing mass of controllers and actions. > > > > You start by thinking about your Models and Views first. > > If this data is not coming from a database, you need to consider why > > you are using Rails even - database-driven is implicit. > > The entire application is database driven. I think I should spend more > time looking towards user views. Hopefully this may more logically > separate the application for me. > > Thanks, > > Andrew. > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 4/18/07, Andrew Edwards <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Sorry, I was referring to large amounts of functionality. It is an > internal application with a limited number of users.Ah *good*. And you answered the other major critical decision (database driven) with an affirmative too. I was just checking that you weren''t using Rails in a way that will ultimately frustrate you.> I haven''t checked camping but will look into it.It''s ActiveRecord at the core. Its even tinier than Rails (a complete non-trivial MVC web-app in a single sourcefile). It trades off a lot of things that Rails has, so I wouldn''t host my e-commerce site with it, but it''s perfectly valid for small deployments and in your case you could use it to proof-of-concept Controllers architectures.> I had originally > intended using java with the spring framework & hibernate.I thought you might have been, hence the questions. hibernate has the ability to model non-DB data sources, like maybe SOAP services, LDAP information, etc. I thought that might have been how you were integrating your CRM & Business processes. However I> found I was making poor headway using my mix of agile/homebrew methods. > Small changes in direction often needed major refactoring and multiple > updates to code and config.Hibernate is pretty damn good at integrating with anything, but the price you pay is code bloat and over-complexity of the common cases.> So far my attempts with rails are looking good. However from experience > I can see things getting harder to maintain as I add more managed > entities and features.As long as your views and especially your models are done right, I wouldn''t worry too much about it.> >> I was hoping someone might share experience of a rails app of a larger > >> size, or specifically how they structured the application to avoid a > >> confusing mass of controllers and actions. > > > > You start by thinking about your Models and Views first. > > If this data is not coming from a database, you need to consider why > > you are using Rails even - database-driven is implicit. > > The entire application is database driven. I think I should spend more > time looking towards user views. Hopefully this may more logically > separate the application for me.In a green field Rails app, your views are most important, then you design your models to support them. And glue them together with controllers. In your case, if I have interpreted it right, you already have a legacy database of your CRM system? In which case your Models are limited to an extent. You probably have some ideas (or your bosses & users of your old system do) of your views. Then you have to wire up Views to Models through your controllers. In a special case, already mentioned by Brian, you might want to have a 1:1 Controller:Model ratio, and if you expect that you are going to have a lot of Models it might be worth doing that anyway. At the end of the day, simplify your controller design by where you expect the complexity to accumulate. With simple areas you can dedicate one controller to multiple views and models, but go with a 1:1 C:M ratio in your feature-popular code. You are unifying processes that already exist, so you can probably second guess where those are. Refactoring a ''busy'' controller isn''t terribly difficult but it is time you would prefer to spend elsewhere. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
@Richard: Excellent response :) On 4/18/07, Richard Conroy <richard.conroy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > On 4/18/07, Andrew Edwards <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > Sorry, I was referring to large amounts of functionality. It is an > > internal application with a limited number of users. > > Ah *good*. And you answered the other major critical decision (database > driven) with an affirmative too. I was just checking that you weren''t > using > Rails in a way that will ultimately frustrate you. > > > I haven''t checked camping but will look into it. > > It''s ActiveRecord at the core. Its even tinier than Rails (a complete > non-trivial MVC web-app in a single sourcefile). It trades off a lot of > things > that Rails has, so I wouldn''t host my e-commerce site with it, but it''s > perfectly valid for small deployments and in your case you could use > it to proof-of-concept Controllers architectures. > > > > I had originally > > intended using java with the spring framework & hibernate. > > I thought you might have been, hence the questions. hibernate has the > ability to model non-DB data sources, like maybe SOAP services, LDAP > information, etc. I thought that might have been how you were integrating > your CRM & Business processes. > > However I > > found I was making poor headway using my mix of agile/homebrew methods. > > Small changes in direction often needed major refactoring and multiple > > updates to code and config. > > Hibernate is pretty damn good at integrating with anything, but the price > you pay is code bloat and over-complexity of the common cases. > > > So far my attempts with rails are looking good. However from experience > > I can see things getting harder to maintain as I add more managed > > entities and features. > > As long as your views and especially your models are done right, I > wouldn''t worry too much about it. > > > >> I was hoping someone might share experience of a rails app of a > larger > > >> size, or specifically how they structured the application to avoid a > > >> confusing mass of controllers and actions. > > > > > > You start by thinking about your Models and Views first. > > > If this data is not coming from a database, you need to consider why > > > you are using Rails even - database-driven is implicit. > > > > The entire application is database driven. I think I should spend more > > time looking towards user views. Hopefully this may more logically > > separate the application for me. > > In a green field Rails app, your views are most important, then you > design your models to support them. And glue them together with > controllers. > > In your case, if I have interpreted it right, you already have a legacy > database of your CRM system? In which case your Models are limited > to an extent. > > You probably have some ideas (or your bosses & users of your old system > do) of your views. Then you have to wire up Views to Models through > your controllers. > > In a special case, already mentioned by Brian, you might want to have a > 1:1 > Controller:Model ratio, and if you expect that you are going to have > a lot of Models it might be worth doing that anyway. > > At the end of the day, simplify your controller design by where you expect > the complexity to accumulate. With simple areas you can dedicate one > controller to multiple views and models, but go with a 1:1 C:M ratio > in your feature-popular code. > > You are unifying processes that already exist, so you can probably second > guess where those are. Refactoring a ''busy'' controller isn''t terribly > difficult > but it is time you would prefer to spend elsewhere. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I have a JEE enterprise resource planning system that my group at my job has been working on for a while now. We only have a few people, so it is very time consuming. We are currently exploring the idea of re- writing our system in Rails. We decided to take a RESTful approach. In organizing our application we looked at each module. For example, Customers, Quotes, Sales Orders. We consider these ''documents''. Documents are sort of like packages of related models. For example, sales_orders have many sales_order_line_items and sales_order_line_items have many sales_order_line_item_delivery_schedules. We then broke our models down into namespaces that relate to their related documents. For example, we have models like: Customer, Customer::Bill, Customer::Ship, Customer::Ship::Account. We use nested resources (RESTful specific) to refer to a things inside the namespace. For example, you can''t access a customer billing address without references the customer like: /customers/:customer_id/bills/:id. We also have a lot things we call ''lookup objects''. For example, customer_ship_accounts belong_to shipping_method. There are shipping methods like UPS, FedEx, etc. But shipping method is not only used with ship_accounts it is also used directly in other modules. In the case of lookups the models are defined like: Lookup::ShippingMethod, but their table names are like: shipping_methods. Our main goal was to make things as simple as possible compared to our old application. We wanted everything organized and we wanted to write as little code as possible. We didn''t want to depend on javascript in our interface. We thought it would be nice if we had an API out of the box. All in all, it is working out quite nicely. The scaffold_resource generator has a few bugs when it comes to models with namespaces so deep, but we are working through them and eventually we plan to write a generator based on scaffold_resource that helps us more. On Apr 18, 11:19 am, Andrew Edwards <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Hi, > > I am developing a larger scale application with rails to manage our > businesses crm, order processing, catalogue, stock control, service jobs > etc. > > Logically the application has distinct modules or sections of > functionality. As you can imagine there are also many cross cutting > dependencies between the areas of functionality. > > Initially I have considered breaking it into ruby modules, primarily > grouping application controllers into areas of functionality. > > As a guide, in terms of number features and screens I would say it will > easily exceed any of the 37signals products I use. I could equate it to > rolling basecamp, highrise and campfire into one application. > > I was hoping someone might share experience of a rails app of a larger > size, or specifically how they structured the application to avoid a > confusing mass of controllers and actions. > > Regards, > > Andrew Edwards > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
How do you deal with namespaced models and fixtures (for unit tests). I tried playing around with putting my models in namespaces, but it seems a bit buggy in that regard. -carl On 4/18/07, Thomas Mango <tsmango-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> In organizing our application we looked at each module. For example, > Customers, Quotes, Sales Orders. We consider these ''documents''. > Documents are sort of like packages of related models. For example, > sales_orders have many sales_order_line_items and > sales_order_line_items have many > sales_order_line_item_delivery_schedules. We then broke our models > down into namespaces that relate to their related documents. For > example, we have models like: Customer, Customer::Bill, > Customer::Ship, Customer::Ship::Account. We use nested resources > (RESTful specific) to refer to a things inside the namespace. For > example, you can''t access a customer billing address without > references the customer like: /customers/:customer_id/bills/:id.-- EPA Rating: 3000 Lines of Code / Gallon (of coffee) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
To be honest, we haven''t tackled that yet. We are still proving that we can efficiently develop a large scale application using Rails compared to our previous framework. On Apr 18, 2:59 pm, "Carl Lerche" <carl.ler...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> How do you deal with namespaced models and fixtures (for unit tests). > I tried playing around with putting my models in namespaces, but it > seems a bit buggy in that regard. > > -carl > > On 4/18/07, Thomas Mango <tsma...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > In organizing our application we looked at each module. For example, > > Customers, Quotes, Sales Orders. We consider these ''documents''. > > Documents are sort of like packages of related models. For example, > > sales_orders have many sales_order_line_items and > > sales_order_line_items have many > > sales_order_line_item_delivery_schedules. We then broke our models > > down into namespaces that relate to their related documents. For > > example, we have models like: Customer, Customer::Bill, > > Customer::Ship, Customer::Ship::Account. We use nested resources > > (RESTful specific) to refer to a things inside the namespace. For > > example, you can''t access a customer billing address without > > references the customer like: /customers/:customer_id/bills/:id. > > -- > EPA Rating: 3000 Lines of Code / Gallon (of coffee)--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Everyone, some great advice. Thanks very much. I''m always keen to read people''s opinion on high level application architecture and planning. I don''t often find it a topic for consideration in most rails text''s or manuals. I suppose many of the best practices are naturally abstract to some degree and need to be interpreted for each language or framework. As such these are available but not necessarily under the guise of a ruby or rails book/webpage. Thomas, it sounds as if your project is quite similar. It is reassuring to hear of a similar project making good progress. Thanks for the tips. Andrew. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---