It is interesting to me that this isn't really on anyone's radar. I'm not sure why this would be. I know there are alot of "single function" websites out there. You know: "online store", "forums", "wiki-thingie", "share your picture", etc. Then there are full-blown CMS-es (some written in ruby, some even on rails), but typically there is way to much stuff there for my taste, and I don't want all of it (or most of it).
I think I'll investigate approach 3 a bit more. I'm guessing there is some reasonable code structure that can make a light-weight widget-set functionality possible that fits in with the typical rails way of thinking. If so, I'll need more help than "use libs". I see for example how acts as authenticated does things, but it still relies on code in the main controller to deal with request & response portion of user interaction.
Like most people -- I'm new to ruby and rails (newbie on rails!), but I've done a lot of software architecture. So I kind of know what I want (and why I want it), but not sure what the most sane way of going about it is. I hope I can bounce some ideas off of people here.
Approach 3, sounds like a good idea, though I'll need to understand this a bit more. It seems to me a controller is ultimately responsible for assembling the information together, and the view is responsible for formatting the information. Partials, used via render :partial, can grab any information that the controller prepared for it (along with session and the typical browser headers).
The question then is how do you organize the interplay between partials and controller code residing in libs that grant me a reasonable level of isolation / abstraction, and how do you structure the "main" controller that decides which "widgets" will be getting displayed, and then run the respective widget controller code, which in turn interact with model code if required, to pull data together for eventual display (via render :partial).
The same question should be asked with the response side of things. Controllers are responsible for responding to actions, and updating the views.
I'm not interested in complicating things too much. I want to fully embrace the "rails way", and I want to ensure that I can pull in plug-ins or whatever else others come up with, without requiring adjustments simply to be able to use the components in a "widget".
At the same time, it seems completely silly to me to require all controller code to essentially reside in the same object, simply because it might be displayed in the same browser page. If you're dealing with a "single application" per page style of website, that makes fine sense. But the minute you want to mix it up, it makes very little sense.
People say (rails book rev2) that instead of using render_component, it's "cleaner" to use partials and before_filters. I need to understand where the before_filters come in, and how that concept could be leveraged to clean things up I guess. I know that code associated with a before_filter is run before any method of the controller is run, but I fail to see how that really improves anything from a clean architecture stand point. I'm probably missing something.
So let's say I've got a set of widgets that may or may not need displaying on a page. Would it make sense to have a master controller that first decides what content needs to be displayed, and then calls a subset of the widget controllers, each of which might call a render :partial?
If the user manipulated something on one of the widget, how would the ajax call (or normal post request) be made to the main-widget controller so that it would know which widget method to call?
Is this essentially what engines try to solve? I hear engines are "not sanctioned" by the core team, though I'm not sure about that. It's just the feeling I get from reading some articles on Rails Engine: http://rails-engines.org (http://rails-engines.org/news/2006/08/3
There is so much to love about rails. But the website I want to implement does have many functional components that are logically seperate (they may have some underlying shared models / connections). To give you an idea, it's a game related website, and it will have:
* wiki-like manual and player-guides
* community driven artwork collective
* top-10 / statistics listings across many different categories including: in-game stuff, advertising stuff, contribution stuff
* server-listings that you can launch the game from
* online chat area
* squad wars (admin, reminders, top-squads, etc)
* dueling stats and top-duelers
Most of the above can easily be handled in the typical main-application page per controller, but the sticky point is how can I throw in other information and "widgets" that really ought to reside on other main-application controllers? For example, the forums will mostly just be about posting and replying to other posts. But at the same time I may also want to mix-in other information. Top-10 players, who is in the game servers, etc. Or maybe if there is an outstanding request for duel.
I don't want to be limited with what information I can put up on a single page. For example, I'd like to have an "ego" page, that is all about the player. Say the user is already authenticated and they go to base URL of the website... I'd like to throw up a page that is just about them: Where do they stand, what's their stats like? But also, have a list of messages that got responded to in the forums, Also some quick-links to launch the game right away, and on the same page, maybe have a few top-10 lists of other players.
I don't want the architecture to limit how I can mix the information together to the end user. If I wake up one morning, and want to add quick-links to launch the game from the forums page, why shouldn't I be able to just add a single line of code to get that "widget" in there?
Last edited by Slurpy (2006-11-18 15:14:03)