Luis, the issue is that he doesn’t want to render the same view for each item in the collection. He wants to render a DIFFERENT view (potentially) for each item in the collection.
Look at his code sample for how he currently renders views while looping over a collection with a dynamic view path: #renderView( view = “/views/#getEntityName( item )#/listing”,entity=item)#
Personally, my take on this would simply be don’t use it. It’s a shortcut for the simple scenarios-- if you want to get fancy just do your own loop.
~Brad, Yep that was exactly what I was explaining. A downside for how
I'm handling rendering collections is that renderView() announces pre/
postViewRender each time I call renderView so I am probably taking a
performance hit from that. I think a prepostExcempt argument for
renderView and renderLayout would be handy, like controller has for
runEvent.
Luis - The other thing I was explaining was that last night's changes
created a compatibility issue with renderView
Before last night's changes I could call renderView like:
renderView("user/detail", user=MyUserEntity);
That user argument would be passed all the way through to my view
where I could access it like:
#user.getUserName()#
The changes last night broke this, since Render now passes rendering
off to renderViewComposite or renderViewCollection but does not
include the extended arguments I called renderView with.
yeah I guess I'll have to rework all the code or write something
else. Not a big deal. I do feel pretty strongly that the collection
placeholder variable convention is not the way to go.
I don't have an opinion on this one really, but I'd be interested in your expounding a bit on how you would rather it work. Would you just like for the additional arguments to just be in the variables scope?
My first thought was that it seemed like the extra arguments should be in the request collection where everything else lives. That would seem especially useful because then you could override request collection variables only for that view. Using the args struct means that the view has to be aware of where its data is coming from which precludes you from being able to re-use a view and change how you pass in data since the view has to "know" whether to look in rc or args. That doesn't seem like the view logic is de-coupled enough from how it is getting its data.
If renderView() did something like this:
var tmpStruct = {};
structAppend(tmpStruct,event.getCollection());
structAppend(tmpStruct,additionalArgs,true);
// Now set tmpStruct as the rc for the duration of this view being rendered.
That would allow the extra args to be part of the rc for that view (and even override existing values in the rc), but you wouldn't modify the actual request collection.
