I am looking for a web framework designed to handle multiple domains
with the emphasis on sharing models, controllers, and even some views
(perhaps fragments) between the different web sites.
Is there such a thing?
Go get Mephisto and put it on rails. Can handle multiple domains, with
different logons for each domain. You can make themes that you can
share
between, and in the end, because it is on rails, you can modify it how
you
want anyway.
Takes a bit of learning, but works well. (get the edge version of
Mephisto
on Rails 2.0 and you should be fine)
I use it successfully as such a thing.
Mikel
There is also “zena”, the tool I am writing. Compared to mephisto, it
does not have an admin interface. All data insertion, editing,
publication is done directly on the site, usually with ajax. It is
also more “content” oriented : of course, you add “pages” and
“images”, but depending on your domain, you will make your own
specialized “objects” like “painting”, “scuplture”, “exhibition” if
you are an artist or “house”, “client” or “renovation”.
The official beta release is planned for the end of January (when I
have more time to write the tutorials and respond to questions).
And just a final note: the templating language in zena is very
powerfull (it is meant to handle all the site’s logic). This is a
simple example of the code to show thumbnails of the houses for sale :
(the “d_sold” stands for “dynamic attribute ‘sold’”).
2007/12/9, Tim U. [email protected]:
On Dec 9, 2007 3:06 PM, Mikel L. [email protected] wrote:
Go get Mephisto and put it on rails. Can handle multiple domains, with
different logons for each domain. You can make themes that you can share
between, and in the end, because it is on rails, you can modify it how you
want anyway.
Takes a bit of learning, but works well. (get the edge version of Mephisto
on Rails 2.0 and you should be fine)
Thanks. I will check it out.
Forgot the link: http://zenadmin.org
Template documentation: zenadmin.org/en/documentation/page142.html
2007/12/9, Gaspard B. [email protected]:
On Sun, Dec 09, 2007, Mikel L. wrote:
Go get Mephisto and put it on rails. Can handle multiple domains, with
different logons for each domain. You can make themes that you can share
between, and in the end, because it is on rails, you can modify it how you
want anyway.
Mephisto is a blogging/CMS engine, not a web framework. I doubt that it
will serve the OP’s needs particularly well.
An option is Arrow, dev(E)iate, which runs under
mod_ruby in Apache. It has a concept of dispatchers, which can be
configured differently. Each vhost in the apache config can be
configured with a different dispatcher, etc.
Check it out, it might be closer to what you need.
Ben
An option is Arrow, dev(E)iate, which runs under
mod_ruby in Apache. It has a concept of dispatchers, which can be
configured differently. Each vhost in the apache config can be
configured with a different dispatcher, etc.
Thanks for the tip. I was thinking about using mod_ruby and
erb-like-things.
What is the state of mod_ruby these days? Is it robust? Why is it that
rails, merb, etc don’t run on it?
On Dec 13, 6:52 pm, “Tim U.” [email protected] wrote:
An option is Arrow,dev(E)iate, which runs under
mod_ruby in Apache. It has a concept of dispatchers, which can be
configured differently. Each vhost in the apache config can be
configured with a different dispatcher, etc.Thanks for the tip. I was thinking about using mod_ruby and erb-like-things.
Maybe I’m missing something, but it sounds like Rails would work great
for your situation.
I’ve also heard very good things about Merb (also an MVC framework),
though I haven’t tried it myself yet.
Jeff
On Fri, Dec 14, 2007, Tim U. wrote:
What is the state of mod_ruby these days? Is it robust? Why is it that
rails, merb, etc don’t run on it?
I think it’s pretty robust. I think it always has been 
I think that
there are a lot of reasons why it’s not in common use these days. Rails
supported it (maybe still does) early on, but it didn’t work that well
because each Apache child has its own interpreter that is persistent…
contrast this with FCGI (for instance) where the state is effectively
cleared between requests. Rails just wasn’t designed to run in that
kind of environment. It’s really just philosophical differences.
As for the others, I suspect they just followed in Rails’ footsteps.
Apache has its downsides, of course… it’s big and complex (though,
once you get familiar with it, Apache totally rocks). It could be
considered overkill, particularly with things like Mongrel around.
Ultimately it’s about what works best for your app. A lot of what Rails
is is just convention. You can build exactly the same app with the same
domain models inside Arrow or merb or with pure mongrel. Just gotta
figure out what features you want to get “for free”
Ben
One day the ultimate web framework will be - ruby itself 
On Fri, Dec 14, 2007, Jeff wrote:
Maybe I’m missing something, but it sounds like Rails would work great
for your situation.
That’s true. I assumed from his first post that he meant “a new
framework” as “something different than Rails”, but maybe that’s not
right
Ben
Maybe I’m missing something, but it sounds like Rails would work great
for your situation.
If rails can work for me I don’t quite know how to do it. Let me
explain.
I am about to start a project which will involve creating several web
sites. These will be completely different web sites but for the same
company and using the same database.
I can already forsee that I want to share many (but not all) of the
models between the web sites as well as sharing some of the
controllers.
I am not sure how the views situation will work itself out yet but to
start with I would like to set a “master” template that every web site
uses and override individual sections and content using partials.
Ideally it would be a kind of a hierarchy where I had a /websites
directory with each rails app living underneath it. If I called for a
model it would look in /websites/myapp/app/models and then look up
/websites/shared/models if it could not find it. Same with
controllers, views etc.
It would also be nice to use same mongrel pool for all the web sites.
I hate to say it but something sort-of-kind-of-but-not-really-zope.
I’ve had problems with code re-use on view-level across rails apps.
plugins have their limits.
you could look at rails engines to set up a core shared app, and/or
plug-abble apps - which allows you to basically make one app a plugin
to another parent-app so you can override the needed areas on a
per-app basis.
plug-apps hasnt been active since april tho, and no support for rails
2 seems to be forthcoming. engines is similar but slightly more
active.
both have big detractors in rails community, but there is no other
obvious solution for code sharing other than building a monolithic app
with multiple entry points.
/dc
On Dec 15, 2007, at 1:54 AM, Tim U. wrote:
sites. These will be completely different web sites but for the same
It should be doable, but you’ll have to brew up some way to negotiate
a default route for each distinct site.
you should be able to reuse controllers to some extent.
Most of the trick here should be the routes and the controllers.
Sharing the same database should be no problem.
The other approach would be to build up a a simple version that
contains the shared functionality, then make 2 branches that add the
functionality unique to each one.
They can still share the same database, but if you’re using MySQL you
might as well just give them access to eachother’s databases and have
them send RESTful messages to eachother at a Ruby/Rails level. If too
many different apps are running on the same database, you might run
into some kind of race condition issues at the database level with
competition for accessing/changing shared table data. The whole idea
of ActiveRecord is to simplify the database side of things as much as
possible.
On 2007-12-14 11:59 +0900 (Fri), Marc H. wrote:
One day the ultimate web framework will be - ruby itself
Indeed, it is, IMHO. At least, that’s what our (Starling Software’s)
fairly minimal (compared to Rails) QWeb framework feels like to me.
On 2007-12-15 16:54 +0900 (Sat), Tim U. wrote:
uses and override individual sections and content using partials.
I’m thinking you might be much better off just building your app(s)
from scratch, and letting the framework you need fall out of it. (I
understand that this is how Rails was built in the first place.) I’ve
found, in my admittedly limited experience with Rails, that if you need
exactly what Rails does, it works fine; as soon as you have a different
model, you’ll spend more time battling Rails than doing any real work.
Rails is just one way of looking at the world, and quite influenced by
the PHP/ASP style of web applications. For many apps, it hurts more than
it helps.
Ideally it would be a kind of a hierarchy where I had a /websites
directory with each rails app living underneath it. If I called for a
model it would look in /websites/myapp/app/models and then look up
/websites/shared/models if it could not find it. Same with
controllers, views etc.
What about taking a “state the differences” approach, instead? Rather
than saying, “I want something slightly different than X, so I’ll
replace it with a completely separate Y that’s very similar to X,” I
find it much nicer to say, “It’s an X, but with just these changes.”
Some of the differences you could just pull up to be implicit. For your
login code, for example, you could just automatically pull out the site
name (The HTTP “Host” header) and use that as part of the information
you use to find the appropriate row in the login table.
cjs
On 2007-12-14 11:15 +0900 (Fri), Ben B. wrote:
On Fri, Dec 14, 2007, Tim U. wrote:
What is the state of mod_ruby these days? Is it robust? Why is it that
rails, merb, etc don’t run on it?…there are a lot of reasons why it’s not in common use these days. Rails
supported it (maybe still does) early on, but it didn’t work that well
because each Apache child has its own interpreter that is persistent…
contrast this with FCGI (for instance) where the state is effectively
cleared between requests.
FCGI has persistent state between requests as well.
One issue with mod_ruby might be that a Ruby interpeter really,
really likes memory, and Apache, at least in fork mode, really likes
a lot of children. Sixty apache children, each with a long-lived Ruby
interpreter, can eat up a couple of gigabytes of memory pretty quickly.
With lighttpd and Ruby FCGI backends, on the other hand, I find I tend
to run fewer Ruby interpreters (a dozen, maybe sixteen on a reasonably
busy site) because once the request is complete, the FCGI backend is
freed to process the next request even while the lighttpd is still
waiting for the client to accept the data.
cjs