Sub-applications or "portlets"

[go94022]

Hope to use Ramaze to support an application with several sub-
applications. Sort of like portlets, althought the arrangement of sub-
applications will *not* be under user control. Each sub-application
will be developed independently by different teams.

Looking for some guidance on the best approach.

Currently considering a directory organization like:

app-root/
app/
subapp1/
# separate directories for each sub-application
controller/
view/
layout/
init.rb
subapp2/
controller/
view/
layout/
init.rb
helper/
layout/
# Shared overall layout for all sub-applications
model/
subapp1/
# Parallel model directories -- the reason is that subapp2
might
# need (read-only) access to the model for subapp1 and
vice-versa.
subapp2/
public/
# Common assets, particualry JS frameworks like YUI, jQuery,
etc.
view/
# Any shared views, not clear this is needed
start.rb

The start.rb code will load each sub-application with something like:
$:.push "app/subapp1"
require "init.rb"
$:.pop

$:.push "app/subapp2"
require "init.rb"
$:.pop

Each sub-applicaiton is responsible to doing all configuraiton/
initialization inside their init.rb file. This will likely be driven
by a configuration file instead of explicit code in start.rb.

The big question is whether any one on this forum has done something
similar. Is there sample code lying around? Any suggestions on the
best way to do this?

Is playing with the load path dynamically a good idea? The reason is
that since each sub-application is developed independently, and want
to avoid problems if different teams "require" files with the same
name or use views with the same name. If different teams use the same
view name, how would their sub-apps load the right view?

Because all the sub-applicaitons are being developed within the same
company (just different teams), still want to share helpers, layouts,
views, etc. as common technology under the app-root.

Thanks, Glen.

[Gavin Kistner]

On Nov 16, 2009, at 12:56 AM, go94022 wrote:

Hope to use Ramaze to support an application with several sub-
applications. Sort of like portlets, althought the arrangement of sub-
applications will *not* be under user  control. Each sub-application
will be developed independently by different teams.

Looking for some guidance on the best approach.

I use a common setup that meets your development desires but not actual requirements. Instead of "an application with several sub-applications", develop actual independent applications. You can have have them share model, helper, template and other code via hard or soft-links between the applications, and share access to the same DB. You 'just' need a web server in front of them acting as the common interface and reverse-proxy.

(The applications run on various ports like 9001, 9002, 9003. The web server handles all requests on port 80. Based on domain and/or path criteria, it passes certain requests on to the correct application transparently to the web client.)

I suppose one downside of this approach is that the combination of applications uses more resources than a single one running would. What other reasons would make one choose sub-applications over separate applications?

[go94022]

Sure this would work, though there are "reasons" why we are looking at
a more monolithic approach. Turns out the deployment needs to run on a
range of platforms from small embedded boxes to Windows. Resource use
is a consideration, and want to avoid cross-platform (well, Windows)
indiosyncrasies with filesystem links. There's also developer
discipline to force using shared components that might go awry if
folks start to link individual files at their convenience (yes, also
aware that rigid sharing has downsides too, but it's a choice). There
also may be cases where sub-applications might be dynamically
deployed, and we don't want to fiddle with automated re-configuration
of Apache (or whatever) on-the-fly -- and again making this work cross-
platform is evil. This is a 24x7 app that needs to stay up during
reconfiguration.