You could use the runEvent to run a handler to return the content into a variable.
Read the docs, the "views/layouts" section. ColdBox has content
variables like you've outlined in Fusebox.
-West
i do understand that.. what i'm getting at here, is the need to run multiple views per handler (appending view2 to view1).. example:
i call blog.detail.. which in turn renders /views/blog/detail.cfm.. i ALSO conditionally need to run comments.main, and append that to the result of the original view..
so.. i'm guessing i need to write another handler method to run / concatenate the two events.. yeh?
If it were me, I would render blog detail as the main view, and conditionally run the blog comments event from within that view in whatever location you wish for the contents to be.
You can only set one view for the main handler being called, but you can run as many additional events (with their own views) as you want and capture their output into variables for whatever use you want including outputting chunks of HTML into the main view.
Does that make sense?
After re-reading your question again, it also occurred to me that perhaps you don't want to run a secondary event, because all the necessary data is in the request collection and you simply wish to render an additional view which you have broken out into a separate file for organization or reusability. In that case, skip runEvent() and direct call renderView() either in your handler or in the main view and either capture its output in a variable or output it directly in the page.
Thanks!
~Brad
Just adding these two methods to share:
Event.renderData(type=‘html’,data=renderView(name=‘fooView’);Event.setView(name=‘fooView’,noLayout=‘true’);
Relative CB newb here, but it seems to me like another possible angle
might be that your controller calls services to retrieve the data for
all these parts of the view, then your main view cfmodules or
cfincludes other sub-views.
That would make sense if you're just breaking the view out for
readability. If it's more for reuse of the subviews, from different
controller methods, then you'd want to balance simplicity vs
encapsulation of the reusable bits, which would then have to include
not only the subviews, but the set of service calls to get the
corresponding data. For a lot of service calls reused many times, it's
pretty clear you'd want to encapsulate that into a single method that
each relevant controller method could call. In between there and a
one-off, your call.
Where I don't know how to go is when a layout needs this kind of data
support. That's when I wish for a convention that fired something
before a given layout rendered, if you needed it. Far as I know, the
only way to do that (other than making the same call(s) from each
controller method where that layout was used) would be a plugin, but
that doesn't seem bound enough to the layout. Is there anything like
this I'm not aware of?
Dave
In the blog example, I’d simply return an array of comments, and iterate over them calling renderView('comments"). In the docs, Luis mentions the overuse of contentvariables has being a performance hog. In the blog example, there is a finite number of things that will appear on the page (post, categories, comments, etc.). I’d simply write the primary view to assemble those pieces.
Jason Durham
I think your response is dead on.. My example really didn't mention that i was totally abstracting "comments" from "blogs"... so it's something that encapsulates its own set of data access, logic and views.. i'm investigating the plugin angle, but it looks almost like i'd need a plugin to handle the insertion into the layout, then a handler to run the ajax requests.. kind of bulky imo..
i'm investigating the plugin angle, but it looks almost like i'd need a plugin to handle the insertion into the layout, then a handler to run the ajax requests.. kind of bulky imo..
Either I'm missing something or you're making this too complicated. If you want the comment chunk of the page to be completely stand-alone (including the service calls to fetch the data) then simply create a handler method with all the necessary service logic to gather the data necessary to display comments, and then at the end of the handler render your comments view with renderView() and return the HTML. Now you have a nice encapsulated "package" that can be called anywhere you want with runEvent() to output the comments section for your blog. The only requirement will be that the blogID or whatever you need to identify the blog entry in question is present in your request collection before calling the event. I'm not sure why you're going off on the plug-in thing, but that sounds like a lot of extra complication.
As for your Ajax requests, I'm not sure what you have in mind, but I would recommend checking out the coldbox proxy. Your web-accessible proxy methods can turn around and run an event which returns the HTML of a rendered view-- or your if you want your proxy to simply return serialized data to your Ajax calls, it can deal with your service methods directly without an event by calling getModel() or autowiring them in. There's really so many options. The proxy isn't even required for ajax calls. I've seen some people just hit an event directly and use the event.renderData() method to return data but that's not my preferred method.
~Brad
As i mentioned earlier, i'm completely abstracting comments from "blog".. so any "thing" could be commentable so long as it can be identified by a type / id.. theres also a good bit of "display logic" involved in turning the comments on/off, for example varying user levels cannot view comments.. It really is a bit more complicated then what i laid out in my example.. the comment system exists totally independent of the content it's being used with, traditionally in my fusebox app, i was able to call the other fuseaction expecting a few predetermined pieces of information (type / id / meta) to be passed in, and it would spit out an ajax widget of comments for that type of content.. making a little more sense why i'm trying to jump thru a few hoops w/ the plugin?
The plugin seems to be the easiest way to inject a "wrapper" into my view.. I'd basically send in my event name as the "type", whatever the PK for the current record is, and some display config.. this would make the appropriate service calls, do the initial html population of the wrapper div.. comments, replies and deletes would update the DOM in real time via ajax requests..
i hope i'm making my use case a little more defined.. all that being said, am i still going to far?
the whole comment system revolves around ajax
Yeah, I understand. Everything is always more complicated than the examples we post on the list. 
That being said, I've done just what you said with a stand-alone handler-- injected an "ajax widget" into the page that would populate/manage itself via Ajax calls and could be dropped in anywhere.
~Brad