parts and controllers

[Ben Nevile]

Dear Dr. Merbles,

1. bbn <3 merb

2. 

let's say you have an interface element that shows up all over the place.  seems like a natural candidate for merb-parts.  but I was saddened to learn that merb-parts aren't equipped to handle requests from the intarwebs.  

in other words, if I want to handle some kind of user interaction with the part, I first have to route the request through a real controller, then to the part, then back out through the controller.  is this correct?

3.

so given that I am developing an app with many such widgets, rather than littering my app's controller folder with many meta-controllers I am considering building a generic "parts" controller that simply calls the part action that's requested and returns the result.  does this seem reasonable?

4. 

potentially_contributable_idea_to_include_in_merb_parts if 3.yes?

Ben

[Paul Barry]

I would say no, if you controller is getting called directly by a request, then it isn't a part, it's a controller.  Are you saying you have controllers that get used as a part and as a controller?

[Ben Nevile]

I would say no, if you controller is getting called directly by a request, then it isn't a part, it's a controller.  Are you saying you have controllers that get used as a part and as a controller?

I'm saying there are logical blocks of my application that I would like to be able to 

A. call from a view, like a part and

B. respond to external stimulus, like a controller.

So one possible solution to my problem would be if I were able to call a controller from within another controller's rendering.  ie,

1. controller A receives a request

2. controller A renders view A

3. view A calls controller B

4. controller B renders back into view A

5. view A finishes rendering and is returned by controller A

Ben

[Michael Klishin]

2008/5/28 Ben Nevile <ben.n...@gmail.com>:

> So one possible solution to my problem would be if I were able to call a
> controller from within another controller's rendering. ie,
> 1. controller A receives a request
> 2. controller A renders view A
> 3. view A calls controller B
> 4. controller B renders back into view A
> 5. view A finishes rendering and is returned by controller A

Then if A is your controller and B is part controller, you can call it
from A's action,
make it render something and return result back to A, then use it in
your "A view"
the way you want it.

So #3 from your original messages makes sense unless you have really many
actions in controller that proxies to parts.
--
MK

[Ben Nevile]

So #3 from your original messages makes sense unless you have really many
actions in controller that proxies to parts.

Yes, there are many.

I know I can make it work the way I want, so mostly what I was fishing for was some kind of design/philosophical reason why parts could not be considered "first-class" controllers.  Don't know if that makes any sense.

Ben

[Julian Leviston]

Slices?

Julian.

[Ben Nevile]

maybe!

[Ezra Zygmuntowicz]

Yeah if you want web routable controllers then slices is what you
want. Parts are explicitely not web routable as an optimization, by
not having the overhead of them dispatching like normal web
controllers they are fast. So you have to make a tradeoff, is what you
want an embeddable Part? Or do you want a slice that can be routed to?

Cheers-
-Ezra

- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ez...@engineyard.com
-- EngineYard.com

[Ben Nevile]

So you have to make a tradeoff, is what you
want an embeddable Part? Or do you want a slice that can be routed to?

but i want both!!  :)

srsly, I want to be able to embed thing thing in my view, but I also want to be able to route web requests directly to this thing.  

guess I can always roll up my sleeves and make this thing myself, huh?

[Julian Leviston]

You've described slices, as far as I can see.

Merb controllers just return strings, so therefore their results
(rendered views) can be embedded just fine... no?

Julian.

[Ben Nevile]

You've described slices, as far as I  can see.

Merb controllers just return strings, so therefore their results
(rendered views) can be embedded just fine... no?

With a part I can say "part MyPart => :index".  Is there an equivalent syntax for embedding controller actions?  And would it pass all parameters, etc?

[Julian Leviston]

Clearly I don't know what I'm talking about.

For some reason I thought you could have a part simply be the result
of a called controller's action... The way I originally thought Rails
worked hehe.

Maybe I'm deluded.

[Matthijs Langenberg]

Ben, you'll probably need to wrap a Part from a Controller. So if you
want to embed a part (like 5 most recents posts) in a view, call it
from a template. If you just want to display the those 5 most recent
posts, create a controller which calls the part from the controller
action.

Would that be a workable solution?

- Matt

[Ben Nevile]

Hi Matt!

Yes, wrapping a part with a controller is a workable solution.  I have taken the approach of creating a meta-action that lives in my Application controller and passes the args through to the appropriate part... basically no different than defining a route for my parts!

Ben

[Matthijs Langenberg]

Great! Let me know how that works out on the long run. Perhaps you
could write a blog post about it?

[Ben Nevile]

sure, I will write something somewheres about whatever ends up working best for me.

Ben