Rails - Sep 2006 - Site Architecture: One big rails app or multiple small apps

Hi,

What does everyone think regarding whether to build one large rails app 
or multiple small rails apps?

For example, lets say I build an online friends site using ror, which 
would contain different categories to be placed under subdomains under 
the toplevel.

For example:
   mysite.com: showcasing all sections, handle user registration and 
login
   dating.mysite.com: for general dating
   intimate.mysite.com: for intimate encounters
   friends.mysite.com: for general friendship

Should I make each of the above section a separate rails application?
   mysite.com --> mainapp
   dating.mysite.com --> datingapp
   intimate.mysite.com --> intimateapp
   friends.mysite.com --> friendapp

Or would it be better to create all those sections under one single 
rails application such as:
   mainapp/
   mainapp/dating_module
   mainapp/intimate

Looking to be enlightened on some pros and cons for both ways, in 
regards to peformance, maintainability, development, etc.


Few things to consider in my design:
- each section of site will share 1 database and user registration/login 
system via the main mysite.com
- each section of the site will have many common functionalities, such 
as user data, tags, user photos.  I would expect a good portion of the 
models to be the same and some of the controller.   The views would be 
completely different.
- For example, a user going to "my account" section should be the same
across all sections as that data shared among all sections.

Thanks!

-- 
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
-~----------~----~----~----~------~----~------~--~---

Truong-an Thai wrote:
> Hi,
>
> What does everyone think regarding whether to build one large rails app
> or multiple small rails apps?
One app.

Ruby allows you all sorts of ways to share code between the similar
modules: inheritance, modules as mixins, metaprogramming, etc

If the user accounts are common and there is one database for the whole
thing then I think you''d be doing battle and going against Rails if you
had multiple applications.

Although I''ve never done it, Rails also allows ways of splitting a high
traffic application across multiple servers (db on one server, app
parts on other servers) and Capistrano can help with this deployment.

Peter


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi Peter,

How would you split up the modules in the application? I have seen
people do nesting with routes, etc but in terms of maintanence down
the track how would someone know what is where? Hope that makes sense.

Thanks,
Carl.

On 9/3/06, petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Truong-an Thai wrote:
> > Hi,
> >
> > What does everyone think regarding whether to build one large rails
app
> > or multiple small rails apps?
>
> One app.
>
> Ruby allows you all sorts of ways to share code between the similar
> modules: inheritance, modules as mixins, metaprogramming, etc
>
> If the user accounts are common and there is one database for the whole
> thing then I think you''d be doing battle and going against Rails
if you
> had multiple applications.
>
> Although I''ve never done it, Rails also allows ways of splitting a
high
> traffic application across multiple servers (db on one server, app
> parts on other servers) and Capistrano can help with this deployment.
>
> Peter
>
>
> >
>

-- 
Carl Woodward
0412218979
cjwoodward-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Carl Woodward wrote:
> Hi Peter,
>
> How would you split up the modules in the application? I have seen
> people do nesting with routes, etc but in terms of maintanence down
> the track how would someone know what is where? Hope that makes sense.
That''s a lot more advice than I could give. It would depend so much on
the situation and how the modules interconnect and a whole lot more.
Perhaps post a specific example and someone with appropriate experience
can give a valuable answer.

Give that that orginial post said that everything will be the same
between the modules except the views it sounds like a one app deal to
me.

Peter


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

To me, there is no question it should be one app.

However, I am new here, and have the same question in my mind. I don''t 
know how to do it.

Anybody gives a high-light on this?


-- 
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
-~----------~----~----~----~------~----~------~--~---

Well I can pick something simple,

say I''ve got some sort of social book marking application and with
that there is a blogging application. You should be able to move
through these applications seamlessly (i.e. single signon). And then
add to this a billing application that also shares the same user
credentials.

Any ideas?

Thanks,
Carl.

On 9/3/06, petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Carl Woodward wrote:
> > Hi Peter,
> >
> > How would you split up the modules in the application? I have seen
> > people do nesting with routes, etc but in terms of maintanence down
> > the track how would someone know what is where? Hope that makes sense.
>
> That''s a lot more advice than I could give. It would depend so
much on
> the situation and how the modules interconnect and a whole lot more.
> Perhaps post a specific example and someone with appropriate experience
> can give a valuable answer.
>
> Give that that orginial post said that everything will be the same
> between the modules except the views it sounds like a one app deal to
> me.
>
> Peter
>
>
> >
>

-- 
Carl Woodward
0412218979
cjwoodward-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On 9/2/06, Carl Woodward
<cjwoodward-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Well I can pick something simple,
>
> say I''ve got some sort of social book marking application and with
> that there is a blogging application. You should be able to move
> through these applications seamlessly (i.e. single signon). And then
> add to this a billing application that also shares the same user
> credentials.
what is social bookmarking?

user will have a controller: UserController (create a user with the
registration page, modify user preferences)
login will have a controller: LoginController
the blogging with have a couple controllers: ArticleController,
CommentController
billing sounds like an administration-only task: BillingController
maybe something for the user: PaymentController

These modules seem relatively small so it isn''t a big deal to have
them all in one app.

Study this link until it makes sense. There were lots of great blog
articles around the blogsphere when this came out

http://www.loudthinking.com/arc/000593.html

while looking at the slides watch the video too

http://blog.scribestudio.com/articles/2006/07/09/david-heinemeier-hansson-railsconf-2006-keynote-address

This helped me understand how to split up tasks in the controllers (and views)

Peter

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Carl,

Single Sigon would be a different topic.  If all your sites are on the 
same domain or even subdomain, single sign isn''t a problem.

The true question is, should you make multiple railsapps out of this.  I 
think it comes down to how much you will be sharing between the 
different railsapps.  I would expect at least the user data to be 
shared.

If you were to create multiple rails apps, then you would have to copy 
code from one rails app to another rails app.

OR, you could have a "mainrailsapp", that handles the user
registraiton,
login, etc.  Have your other railsapps simply redirect to this app for 
login and such.


I think a really good example to analyze based on my original question 
is 43things.com and 43places.com.

Obviously, they the two sites share a lot of the same funcitonalities, 
such as user registration, uploading images, writing entries.   What 
makes me wonder is, are they running separate rails applications for 
each site?     There is enough custimization on each site which makes me 
think it would be easier to create separate rails application, however 
that would require a lot of code duplication for simliar 
funcitonalities.

A pro I see for creating separate rails apps is that you could potential 
have site "A" running while putting down site "B" for
mainenance without
affect each other.

And what about memory usage with a single large rails app vs multiple 
smaller rails apps.


Truong.


Carl Woodward wrote:
> Well I can pick something simple,
> 
> say I''ve got some sort of social book marking application and with
> that there is a blogging application. You should be able to move
> through these applications seamlessly (i.e. single signon). And then
> add to this a billing application that also shares the same user
> credentials.
> 
> Any ideas?
> 
> Thanks,
> Carl.
> 
> On 9/3/06, petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> the situation and how the modules interconnect and a whole lot more.
>> >
>>
> 
> 
> --
> Carl Woodward
> 0412218979
> cjwoodward-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

-- 
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
-~----------~----~----~----~------~----~------~--~---

Hey Truong-an
> The true question is, should you make multiple railsapps out of this.  I
> think it comes down to how much you will be sharing between the
> different railsapps.
yes...exactly.
> A pro I see for creating separate rails apps is that you could potential
> have site "A" running while putting down site "B" for
maintenance without
> affect each other.
>
> And what about memory usage with a single large rails app vs multiple
> smaller rails apps.
why is that a pro?  How many times do you have to take a site down for
maintenance?  maybe 5 min a month?  Same goes with memory.  Why make a
major architecture decision based on some far off ''what-if?''

Truong, I think you hit the nail on the head when you stated that it
comes down to how much code sharing there is.

As for the original question, I''m creating a site that will eventually
have about 7 very different components (mini-apps?) under one umbrella.
 I''m sticking with the single RoR approach because I want to keep it
simple.  I suspect that I''ll want to pull one or two of the components
out into their own app in the future, but I just don''t know right now.
So why complicate my initial development and deployment worrying about
something that might or might not happen?  Yet if I see a lot of common
code I DRY it up by putting it in a plugin or a file living in the lib/
dir.  Plus, with the way RoR is organized, pulling out a few
controllers into their own app will be a piece of cake.  I think it
would be harder to try and ''simplify'' multiple apps into one
than split
one app into many.

Good luck with your project!
Adam


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

If you are looking to share alot of code, whether it be controllers,
models, views, tests, etc.. A Rails Engine would be the way to go.

They are a more comprehensive system which extends upon the plugin
architecture. You can use the svn:externals feature to be able to have
a single location which all your code is stored in a central location,
then each app that utilizes that code can be very easily updated.

In addition, when it comes to customizing it based on some specific
application, you can override your Engine code for that specific
application.

Starting off with an Engine before you see that the code is indeed
central to more than one of your applications doesn''t make sense
unless it is indeed something that is common. Such as the DateBocks
library I wrote, Substruct eCommerce Engine Seth wrote, or something
similar. Whereby the majority of your code (+~80%) or so, is going to
be the same across all your apps.

You can find more info at http://rails-engines.org

-NSHB

On 9/3/06, Adam Greene
<adam.greene-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hey Truong-an
>
> > The true question is, should you make multiple railsapps out of this. 
I
> > think it comes down to how much you will be sharing between the
> > different railsapps.
>
> yes...exactly.
>
> > A pro I see for creating separate rails apps is that you could
potential
> > have site "A" running while putting down site "B"
for maintenance without
> > affect each other.
> >
> > And what about memory usage with a single large rails app vs multiple
> > smaller rails apps.
>
> why is that a pro?  How many times do you have to take a site down for
> maintenance?  maybe 5 min a month?  Same goes with memory.  Why make a
> major architecture decision based on some far off
''what-if?''
>
> Truong, I think you hit the nail on the head when you stated that it
> comes down to how much code sharing there is.
>
> As for the original question, I''m creating a site that will
eventually
> have about 7 very different components (mini-apps?) under one umbrella.
>  I''m sticking with the single RoR approach because I want to keep
it
> simple.  I suspect that I''ll want to pull one or two of the
components
> out into their own app in the future, but I just don''t know right
now.
> So why complicate my initial development and deployment worrying about
> something that might or might not happen?  Yet if I see a lot of common
> code I DRY it up by putting it in a plugin or a file living in the lib/
> dir.  Plus, with the way RoR is organized, pulling out a few
> controllers into their own app will be a piece of cake.  I think it
> would be harder to try and ''simplify'' multiple apps into
one than split
> one app into many.
>
> Good luck with your project!
> Adam
>
>
> >
>

-- 
Nathaniel Steven Henry Brown

Open Source Insight - http://nshb.net
Open Source Development - http://inimit.com
Open Source Training  - http://osevents.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
-~----------~----~----~----~------~----~------~--~---

Some reasons to split up the application would include:

* User Management / Delegated Management - build it only once & abstract 
from apps
- Ruby eventually will need to cater for the supporting a "Porlet"
type
standard which then addresses the concept of having muliple 
applicationsn (portlets) within an overall portal perhaps.

* Authentication - build only once again & abstract from apps
- we did this once in java based on the concept of passing off to the 
common application with appropriate session parameters (e.g. return 
link) and then handing control back afterwards.  Was quite ackward from 
a security sense as there were quite a few checks and balances to take 
care of.  A portlet/portal concept would be better.
- in the case of ruby I would be inclined to have a standard mix-in 
concept for this (but leave the actual user management screens in a 
separate app)

* Lower Deployment Risk - i.e. the ability to perform a production 
release of 1 application only without the risk of impacting another 
application.  This is an issue in a large organisation who will want 
regression testing against the areas that have changed.

thats all for now...

-- 
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
-~----------~----~----~----~------~----~------~--~---

On Sep 3, 2006, at 10:17 PM, Adam Greene wrote:
>> A pro I see for creating separate rails apps is that you could  
>> potential
>> have site "A" running while putting down site "B"
for maintenance
>> without
>> affect each other.
>
> why is that a pro?  How many times do you have to take a site down for
> maintenance?  maybe 5 min a month?  Same goes with memory.  Why make a
> major architecture decision based on some far off
''what-if?''
Obviously I can write only for myself, but it''s not the planned  
downtime that introduces the pain.  It''s the unplanned downtime when  
I''ve wished that I had two apps.

That said, on one of my projects, I''ve recently consolidated four  
apps into one.  I had admin, www, and two other subdomains, each as  
its own Rails app.  I even had a shared_models directory that each of  
the apps added to their load paths (which means it was five things in  
subversion, not just four).  The setup became unwieldy.   Looking  
back, it was a very poor design for this application.

I can''t say there''s never a time to have separate apps, but I
would
think long and hard about my reasoning before making that design  
decision again (especially if the apps share the same database(s)).

Ditto NSHB on looking into Engines.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Okay seems like mixed opinions and really been up to each individual''s 
project.

I think I left out a few important things when stating my original 
question, so I hope to be more clear this time to get more precise 
feedback from everyone.  I think the specific example here can be useful 
by many developers out there.

This is bit long, but it is important to understand the nature of the 
application itself.

Lets Assume few things first:

Site A and Site B, are very similar sites, but just different themes. 
For example, "43things.com" and "43places.com".

Assume that two sites are under one domain using subdomains (to avoid 
any single-sign-on complications).

They will share the same database (but can have different tables).
For example, the ''user'' table will definitely be shared since
we want
users to move across siteA and siteB seamlessly once registered.

However, lets look at site functionalities such as entries, comments, 
photos, etc.  The model and controller logic between Site A and Site B 
for entries/comments/photos could pretty much be the same.  The views 
will look different as we want to present them as different sites, and 
we could use localizations to change the site text.

Now, I am thinking of storing the entries/comments data for site A and 
site B in SEPARATE TABLES.  For example I can have, tables:

''site_a_entries'', ''site_b_entries''
''site_a_comments'', ''site_b_comments'',
''site_a_photos'', ''site_b_photos''

And so on...


Lets break down the two paths:

*** MULTIPLE APPS ***

My approach would simply be to develop siteA first with all the 
functionalities and such complete, which may also use a few plugins, 
gems, etc (localization, fileColumn, acts_as_taggable, etc).   Site text 
would be handled using a localization file.  Look and feel with external 
css file.  Specific tables can be set for this site via set_table_name 
on the model.

Now, for siteB, I simply create new railsapp and copy siteA files over. 
All I have to do at this point to complete siteB is:

- modify each specific model, such as entries/comments/photos, 
set_table_name value so that it points to correct table for this site. 
(based on my intention of using separate tables above).
- add the specific table for this site, such as
''site_b_entries'',
''site_b_comments''
- modify the text in localization file
- modify the css file to change color and themes
- modify the views to present data differently

So this would be fairly easy approach in terms of implementation. 
Don''t
have to worry about tossing in logic to determine which activerecord 
model to use in the controllers and which specific tables to use in the 
model, which css to use, which localization to use.

But the cost is maintainability.  I basically have two copies of the 
same model/controller code, and plugins/gems used across both sites.

Not to mention, I might have a 3rd rails app, to handle the common 
login/user account which also acts as the ''main'' site app.

Changes to site header/footer will require changes to 3 files in 3 apps 
for example.


*** ONE RAILS APP for both sites ****

This approach is what is complicating me.

I could initially create the two sites using modules, such as "script 
generate controller siteA/entries" and "script generate controller 
siteB/entries."    So controllers/views will be grouped appropriately. 
However, I don''t think there are clean ways to pack models in modules.

Now comes the specific tables for each site.  How would we group the 
activerecord models?  Would it even be possible to share activerecord 
model code, that acts on different tables?  What about inside 
controllers which needs to use a particular activerecord model?

Should I even bother with using separate tables for entries between 
siteA and siteB? (1 million rows in one table vs. 500K rows in each of 
two tables).
I''ve just read about rails 1.1 polymorphic models...which may work for 
this scenario, but it still packs all the model types into a table 
representing the collection.  So you still end up with 1 million rows in 
addition to the 500K rows for each site specific table.

I can imagine having a lot of code to do this in the controllers, 
models, etc.
   if subdomain == ''siteA''
     ...
   if subdomain == ''siteB''
     ...

Maybe some metaprogramming may help in this?

Or, perhaps I could just roll out one app still, but do not share any of 
the
model/controller code.  Still a lot of code duplication but no messy 
logic to determine which activerecord model to act on.  Would still have 
to manage which localization or css template to use based on subdomain 
info.

So you see the complication and I hope it is clear now where my problem 
is =).

In Summary:
** Multilpe Rails App = Easier implementation but require code 
duplication, more management.
** One Rails App = More difficult implementation, maybe less code 
duplication, less management.

Thanks in advance for all suggestions.

Truong-An.



Zachary Holt wrote:
> On Sep 3, 2006, at 10:17 PM, Adam Greene wrote:
> 
>>> A pro I see for creating separate rails apps is that you could  
>>> potential
>>> have site "A" running while putting down site
"B" for maintenance
>>> without
>>> affect each other.
>>
>> why is that a pro?  How many times do you have to take a site down for
>> maintenance?  maybe 5 min a month?  Same goes with memory.  Why make a
>> major architecture decision based on some far off
''what-if?''
> 
> Obviously I can write only for myself, but it''s not the planned
> downtime that introduces the pain.  It''s the unplanned downtime
when
> I''ve wished that I had two apps.
> 
> That said, on one of my projects, I''ve recently consolidated four
> apps into one.  I had admin, www, and two other subdomains, each as
> its own Rails app.  I even had a shared_models directory that each of
> the apps added to their load paths (which means it was five things in
> subversion, not just four).  The setup became unwieldy.   Looking
> back, it was a very poor design for this application.
> 
> I can''t say there''s never a time to have separate apps,
but I would
> think long and hard about my reasoning before making that design
> decision again (especially if the apps share the same database(s)).
> 
> Ditto NSHB on looking into Engines.

-- 
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
-~----------~----~----~----~------~----~------~--~---