Trying to convert a large application from our home brew PHP framework
to Ruby on Rails. I’ve built small things, like blogs and other CMS’s
with Rails, but am having a hard time thinking of a better way to
impliment some of our specific needs.
The big issues if our file overriding. We have a base application
that we start with and then do custom work per client on top of that.
We never change the base application though. Right now how it works
with our PHP framework is with the modules we have a “default” folder
with the base modules and a company specific folder that just inherits
from the base and overrides methods as needed. But the trickiest part
is the views. We didn’t want to duplicate all of the views just to
change one or two things. So it also has a default folder and a
company specific folder. If the file isn’t in the company specific
folder then it looks in the default. So we only have to duplicate and
modify a handful of files for each client.
I was hoping to use plugins or engines to accomplish this with Rails,
but the more I look into it the more it seems it wont go that far. In
fact, it seems it works the opposite of what I would like. Ideally we
would make the default app the “engine”, then create models,
controllers, and views to override the engine.
I highly doubt this is a unique problem. What would the Golden Path
with Rails be for this?
Eric
Soabirw wrote:
Trying to convert a large application from our home brew PHP framework
to Ruby on Rails. I’ve built small things, like blogs and other CMS’s
with Rails, but am having a hard time thinking of a better way to
impliment some of our specific needs.
The big issues if our file overriding. We have a base application
that we start with and then do custom work per client on top of that.
We never change the base application though. Right now how it works
with our PHP framework is with the modules we have a “default” folder
with the base modules and a company specific folder that just inherits
from the base and overrides methods as needed. But the trickiest part
is the views. We didn’t want to duplicate all of the views just to
change one or two things. So it also has a default folder and a
company specific folder. If the file isn’t in the company specific
folder then it looks in the default. So we only have to duplicate and
modify a handful of files for each client.
I was hoping to use plugins or engines to accomplish this with Rails,
but the more I look into it the more it seems it wont go that far. In
fact, it seems it works the opposite of what I would like. Ideally we
would make the default app the “engine”, then create models,
controllers, and views to override the engine.
I highly doubt this is a unique problem. What would the Golden Path
with Rails be for this?
Eric
Does every version of your application have to be deployed to the one
place? If it doesn’t, I’ve heard of people writing apps and implementing
customer specific stuff using subversion branches, not a Rails solution,
but a solution!
RYan.
http://yeahnah.org/
On May 9, 10:18 pm, Ryan A. [email protected]
wrote:
Does every version of your application have to be deployed to the one
place? If it doesn’t, I’ve heard of people writing apps and implementing
customer specific stuff using subversion branches, not a Rails solution,
but a solution!
It used to. The root basically looked like:
modules/
company_def/
company_one/
company_two/
web/
company_def/
company_one/
company_two/
Then I came along. Now each company has it’s own section of the
repository. So the trunk only contains company_def, which we use when
we create a new application. Then we add company_specific as needed.
But the problem is view overriding. We have multiple packages as
well. So here is the typical search pattern. When a request comes
in, look for the view in company_one/package_admin. If it isn’t in
there look in company_one/package_def. If it isn’t in there, look in
company_def/package_admin. If it isn’t in there, look in company_def/
package_def. Even if we lose the packages, it will still look in
company_one then in company_def.
I don’t really like this. But it allows us to re-use our views unless
we actually need them to be different. It also allows us to make
changes to company_def and then have that automatically work for every
single client. Very handy way of adding new features. This is the
only system I’ve seen something like this done and I need to be able
to some how retain this.
Eric
Was re-reading my post and just wanted to point out, that even though
I sound like I want to keep the feature exactly as it is in our
current frame work, that is not the case. I need the functionality,
but want to do it the RoR way. If there is one. I read the HowTos on
plug-ins hoping they would be the answer, but it didn’t look like it.
Especially since it didn’t seem to support views. And maybe I’m
mistaken in that? My hope was to start up a basic RoR app and then
apply the default package plugins as needed, then override them. Or
alternatively check out the default RoR app and make the client
specific stuff plugins. But from my reading it didn’t seem like
that’s what plugins were intended for.
Eric