The three application route does sound like the best way, but you''re right it is overkill, at least for delivering in a timely manner. In my situation I really should bring everything together under one roof, I was thinking about it on the way to work and it "feels" possible. I think the problem is that I want to have separate frontend controllers compared to my backend. I don''t like having admin actions in the same controller as the frontend actions. I know I could use a before_filter to ensure an admin is logged in etc. I would feel better If the admin controllers were wrapped up in a module and only accessible through a certain address which was locked down to our offices'' IP''s by the webserver. My only other concern with making it one application is I would like to access the admin side from a subdomain, admin.foobar.com rather than foobar.com/admin/ It''s kind of silly but I just like that setup better. Again, it should be possible I just haven''t figured out the solution, so if you know please share :) I am glad this was brought up, I have a feeling as more applications beyond just Blogs are written situations like this will arise. -Paul
have you heard of productize ? http://wiki.rubyonrails.com/rails/pages/HowtoProductizeYourApplication>From what I understand of your problem, this is the way to go for you ...jean On 9/28/05, Paul <paul.marsh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> The three application route does sound like the best way, but you''re > right it is overkill, at least for delivering in a timely manner. > > In my situation I really should bring everything together under one > roof, I was thinking about it on the way to work and it "feels" > possible. I think the problem is that I want to have separate frontend > controllers compared to my backend. I don''t like having admin actions > in the same controller as the frontend actions. I know I could use a > before_filter to ensure an admin is logged in etc. I would feel better > If the admin controllers were wrapped up in a module and only > accessible through a certain address which was locked down to our > offices'' IP''s by the webserver. > > My only other concern with making it one application is I would like > to access the admin side from a subdomain, admin.foobar.com rather > than foobar.com/admin/ > > It''s kind of silly but I just like that setup better. Again, it should > be possible I just haven''t figured out the solution, so if you know > please share :) > > I am glad this was brought up, I have a feeling as more applications > beyond just Blogs are written situations like this will arise. > > -Paul > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Hi ! Jean Helou said the following on 2005-09-28 11:28:> have you heard of productize ? > > http://wiki.rubyonrails.com/rails/pages/HowtoProductizeYourApplication > >>From what I understand of your problem, this is the way to go for you ...In my original E-Mail, I thought of mentionning productize, but wasn''t sure if it would fit my needs. Just reading up on it, I believe I can/should use that instead. If you read my other mail, you''ll see I am currently using svn:externals to share as much code as possible. One thing I''d like to know about productize is whether it needs any work done to use on Edge Rails ? Thanks for the tip ! François
On 9/28/05, François Beausoleil <fbeausoleil-IQIa899fVSs@public.gmane.org> wrote:> One thing I''d like to know about productize is whether it needs any work > done to use on Edge Rails ?I haven''t tried, but I don''t think so. There is a generator too : http://wiki.rubyonrails.com/rails/pages/RailsProductGenerator The generator works with 0.13.1 and I don''t play with no edge stuff, I am too afraid of blood :) However, it is regularly said that all that worked with 0.13.1 is supposed to work with 1.0 Now that might not be true for generators (I don''t follow the list nearly closely enough) but I definitely think it is worth a try. Please let us know the result of such experimentation. jean
On Sep 28, 2005, at 6:16 AM, Paul wrote:> The three application route does sound like the best way, but you''re > right it is overkill, at least for delivering in a timely manner.In my case, I have one big schema that can be grouped as A, B, C, and D, totaling 45 entities. Ultimately, these are all stored in one physical database; the partitioning is a logical partitioning for function grouping. I have an app A that needs only schema A (where the people relations are, thus everything else pretty much depends on this schema). App B needs only some of the functions of app A, but needs schemas A and B. App C needs schemas A and C, a hook into minimal functionality of App A. App D needs schema D only and has no code in common with app A, B, or C. It''s the open-facing part of App E, really, but it gets put up and taken down at different times of year than E, thus making it a separate app makes sense. App E needs schemas A, C, and D and needs to print a report of anything in schema B. It does have overlap with App D. Fortunately, three of these five apps (A, C, and D) are very small. E is the behemoth. So, I''ve put schema A into app A''s repository, with svn:externals for the shared parts. So far, so good.