Should be pretty straight forward. In the handler for your viewlet, instead of doing event.setView(“menus/vwToolkit”), render it right then and return the output like so:
return renderView(“menus/vwToolkit”);
Then in the main view/layout, just do #runEvent(“menu/toolkit”)#
This also makes it very easy cache just that viewlet.
Thanks!
~Brad
I like to do #runEvent('handler/method')# in the containing view or
layout as Brad suggested. Once you do this though you'll probably
start to wonder if this is the right way to do it since ColdBox uses
the request collection to pass arguments and results for the main
event and also for any sub-events. In theory you could get some
collisions, especially if you are using the same sub-event more than
once per page. If you don't like having #runEvent('handler/method')#
in your main layout / view you can return that into a content variable
within the main event handler and then just output that content
variable in the view.
I've been thinking about this a bit lately and I played around with
namespacing the sub-events within the request collection, but I'm not
entirely satisfied with that.
You're on the right track though.
I'm thinking about implementing backbone.js to handle the client side
of things.
I've been struggling a bit with how to structure my handlers and views
directories to make it clear that some content is a new page versus a
simple block.
It makes sense when having events like User.userDetails and
User.userDetailsBlock, but when performing actions like save and
delete, determining what to return is tricky.
I've been thinking about using the 'format' parameter to differentiate
between full-HTML (including layout), block HTML, and JSON.
When I have return renderView(...) in a handler, if I access that
handler through the browser will it render the return value???
Just some thoughts....
I went about this another way. I created a ViewletManager which was responsible for holding a series of “ViewletContainers” for each request. A container was something like “left-sidebar” or “sub-masthead”. The controller was responsible for placing viewlets in these containers (array of paths to the viewlets). When the layout (or main view) was executed, it called the ViewletManager to render any views added during the request.
This ended up being more useful than I imagined when I initially wrote it. If the layout doesn’t call for a specific container, it doesn’t get rendered. I intended to blog about it and share it but I never found the time.
Jason Durham
You mentioned namespacing the response context data. Any luck with that?
When dealing with Ajax calls I always return a structure, that might look something like this.
Result = {
Status = ‘failed’,
Message = ‘’
};
This is the minimum I setup, when the ajax is returned I check for result.status being ok. I actually use true/false here though. Then I do what I have to do get the data, and then add that as an associate array to the result struct. So it might end up like this if successful.
If(record.recordCount) {
Result[‘Status’] = ‘ok’;
Result]’datat’] = someData;
};
}
This way you have a defined result set, that will hold good or bad news and is consistent. The other side of the coin here is that I use try/catch blocks to provide extra information. So unless the machine is down, network disconnected or power outage, the information will always return something to tell the client who called exactly what is happening.
I wrote a blog on this a long time ago when I find it I will post it.
Regards,
Andrew Scott
Nothing to share on this front yet. Im fiddling with a custom request
context. If that approach works out i'll post it to forgebox.