I''m looking into the best way to go about sectioning the different areas of a large application we''re building. The application would have a public facing area as well as customer care and admin sections, the latter two needing logins. The urls for these would look something like: http://www.mydomain.com http://care.mydomain.com http://admin.mydomain.com I found an earlier thread on this list concerning separating public and admin areas which was quite informative and considering the potential size of the application it would seem that creating separate Rails apps for each section would be a good idea. There were a couple of points not raised in the thread that I''d need to know about though before deciding. (All applications would be referencing the same database) 1/. Common models - Is it possible to store models in a directory shared between the apps rather than the default load path? Is this a good practise? 2/. Caching - Many pages/actions/fragments in the public domain will need to be cached for peformance, but the majority of the actions that would expire these caches will occur in the admin section. Is it possible to a) programmatically expire and b) use Rails'' cache sweepers across Rails applications? Another option would be to separate the sections in the same way it''s done with Typo (http://typo.leetsoft.com/trac/), although given the size we expect this project to be, the separate applications would be preferable if we can get round those two points. If anyone has any thoughts on the points above, or on other methods, I look forward to reading them. Cheers Matt
We started down the multiple application path and...> > > 1/. Common models - Is it possible to store models in a directory > shared between the apps rather than the default load path? Is this a > good practise? >just had all the models in one directory and then used symlinks as required ( simple is best no?... ) one thought we had was that... given that the public facing end should never modify most models... we could actually do different models and have the public be ''crippled''. i.e. unable save etc.> 2/. Caching - Many pages/actions/fragments in the public domain will > need to be cached for peformance, but the majority of the actions > that would expire these caches will occur in the admin section. Is it > possible to a) programmatically expire and b) use Rails'' cache > sweepers across Rails applications? >store cached objects in memory using memcached then have each application interact with the same memcache... we have implemented this yet so i can''t say how well it works in practice... but its the theory we are working off of. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
You probably want to look into the excellent Productize extension - search the list here or on the Wiki. Cheers, Colin On 10/08/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote:> We started down the multiple application path and... > > > > > > > 1/. Common models - Is it possible to store models in a directory > > shared between the apps rather than the default load path? Is this a > > good practise? > > > just had all the models in one directory and then used symlinks as > required ( simple is best no?... ) > > one thought we had was that... given that the public facing end should > never modify most models... we could actually do > different models and have the public be ''crippled''. i.e. unable save etc. > > > 2/. Caching - Many pages/actions/fragments in the public domain will > > need to be cached for peformance, but the majority of the actions > > that would expire these caches will occur in the admin section. Is it > > possible to a) programmatically expire and b) use Rails'' cache > > sweepers across Rails applications? > > > store cached objects in memory using memcached then have each > application interact with the same memcache... > we have implemented this yet so i can''t say how well it works in > practice... but its the theory we are working off of. > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >