Rails - Aug 2006 - Need architectural help avoiding render :component

I''m writing a CMS/portal system, and I''m having trouble coming
up with
a way of routing requests that feels right without using render
:component (which I''ve read should never be used).  The system works
like this:

Each user has a set of "pages" which are shown as navigation tabs on
the page.  The user may rename, reorder, add, or delete pages for a
custom view of the site.  Pages can be of a number of types (calendars,
blogs, links pages, to do lists, etc).

If the user, joe, makes a page called "My Calendar" it''s URL
would be
http://thesiteurl/joe/my-calendar

Once a request comes in for that URL, I need to hit the database in
order to figure out how to route it.  I have to figure out what type of
page "my-calendar" maps to and ensure that joe has permission to view
that page.  As far as I can tell, it''s not possible to handle this in
routes.rb, so I put it in a controller, PageController.

Once the app determines what kind of controller is required, it needs
to pass on the request to the appropriate controller (a
CalendarController, BlogController, ToDoController, etc).  It seems
like the most straightforward way of doing this is to have the last
line of PageController''s routing function be "render :component
=> ..."

I have managed to use what I consider to be a gigantic hack to get
around this.  PageController figures out which controller needs to
handle the final request, instantiates it, calls the appropriate
function on it, reflects all of that function''s local variables into
its own, and then calls the appropriate render :action.  The code for
this is pretty ugly, and reflecting private variables like that makes
the software engineer part of me want to cry.

So, what''s the proper way of handling this without using render
:component?  What am I doing wrong?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi~-

On Aug 30, 2006, at 6:51 PM,
inkieminstrel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>
> I''m writing a CMS/portal system, and I''m having trouble
coming up with
> a way of routing requests that feels right without using render
> :component (which I''ve read should never be used).  The system
works
> like this:
>
> <snip>
> I have managed to use what I consider to be a gigantic hack to get
> around this.  PageController figures out which controller needs to
> handle the final request, instantiates it, calls the appropriate
> function on it, reflects all of that function''s local variables
into
> its own, and then calls the appropriate render :action.  The code for
> this is pretty ugly, and reflecting private variables like that makes
> the software engineer part of me want to cry.
>
> So, what''s the proper way of handling this without using render
> :component?  What am I doing wrong?
Hey there-

	I am working on a plugin for this exact purpose. render_component  
does suck hard and is way slow because it has to instantiate a whole  
new request/response and controller object. But I do think there is a  
need for a light weight way of making small ajax applets or page  
parts that can get rendered in a view in a similar way to  
render_component without all the baggage but also need to be able to  
handle ajax callbackls in the controller. So I have a plugin called  
''cells'' that aims to solve this problem. I haven''t
released it
anywhere yet but you can grab it form svn and see what you think.

	It works by piggybacking off of ActionController::Base or  
ActionView::Base depending on whether its handling a request or  
whether it is being rendered within another view sort of like a  
component. Keep in mind that this plugin is not about sharable  
betweek apps reusable high level components that everyone hates.  
Cells are about encapsualting small page parts and giving them a way  
to remain independent from other controllers. Using this technique  
you can accomplish something akin to render_component in a view, only  
its around 21 times faster ;) It also makes you add only one  
ActionController c lass to you app. This controller is a dispatcher  
for all your cell controllers. Each cell is a small MVC stack that  
lives in its own folder. So in your app you add a directory called  
RAILS_ROOT/app/cells. And in cells/ you can have your cell''s views,  
models and mini controller.

	Here is the svn url. It is a full rails app with a small todolist  
sample ''cell'' included so you can see how it works. PLay with
it and
lt me know how it works for you. When i get some more time I will  
make a it a more genrally available plugin. I am getting a lot of  
good use out of it and I think it solves a problem that a lot of folk  
struggle to do in a clean way with rails.

svn co http://svn.devjavu.com/cells


Cheers-
-Ezra



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---