Updates on dev branch for testing

Here is a list of the tickets fixed for the upcoming 3.1

The new features to test are the following:

1.Rendering local variables:
You can now pass an optional args struct to renderLayout() and
renderView() that allows you to have localized variables only for
those renderings

renderView(view="sayHello", args={name="luis", lname="majano"});

The view then can use them locally ONLY
#args.name# #args.lname#

Great flexibility

2. Request context now returns itself on calls that don't retrieve
anything, for method concatenation and readibility

3. renderData() has a location argument to set a location header if
you are building RESTful services:


4. Renderering helper: html
Every layout and view have a new variable in the variables scope: html
that is an instance of the HTMLHelper plugin already available and
ready for usage.

5. Renderlayout(layout="custom", view="email") when using an explicit
renderLayout() with a view, we needed to have a
#renderView(arguments.view)# in our layout for this to work, which was
confusing. This is now not needed so you can REALLY use any layout to
wrap view contents -> renderView() that's it.

6. Rendering Collections
This was inspired by Rails for a long time and I was too lazy to
build. You can now render views with collections. This means that
the view will be rendered as many times as the collection items. The
collection can be a query or an array of whatever you like objects,
structs, etc.


Then in the view:

Name: #user.name#
Id: #user.id#

The #user# variable placeholder is called "user" by convention since
that is the name of the view argument. You can change the name of the
collection with:

renderView(view="user",collection=qUsers, collectionAs="thisUser");

Then in the view:

Name: #thisUser.name#
Id: #thisUser.id#

This is a great technique that will allow you to render a view self-
iterating via a collection. You can also still use the "args" to have
localized arguments if needed.

Enjoy and let me know how it goes

This is just awesome Luis, great set of enhancements. I'll start
testing today but just some initial feedback:

1: This might be my favorite of the bunch. I was already doing this
since you were calling the view and layout with an argumentcollection
but I was uneasy that it wasn't officially supported.

2: Sweet. I'm going to start using the requestcontext a lot more now
when dealing with rc vars.

On this subject I was wondering yesterday why all handler functions
only ever recieved the one event argument. All my handler functions
have two setters at the top to set the rc and prc and it would be
really handy and save a ton of typing if those were passed in as
arguments too. myHandlerFun(event,rc,prc){}; Is there reasoning
behind why it doesn't work that way?

4: Very handy, I think I am going to utilize this a lot more. Along
these lines I've been thinking that nice enhancement would allow for
developers to configure plugins that get added to the variables scope
(or someway to extend framework supertype). The UDFLibraryFile just
doesn't do it for me, although it would be much better if it supported
an array rather than a single file.

6: Okay, okay. this is my favorite of the bunch. But can I make a
case that you change the placeholder convension before 3.1 is
released? I'm worried that any change to the view name will require a
lot of refactoring to change all the variable references. I also have
often have pretty long view names so I may have something like
user_formfields.cfm and I would hate to have to type
user_formfields.getName(). Even if I have user/formfields.cfm
formfields.getName() is still to much for my lazy fingers.

Why not have a generic static convention for the placeholder variable
name? We can't use "view" because that is an argument name but maybe
"$view" or maybe "item" so we'd have #$view.name# instead of #

from your example, I imagine user would have many different views, so
you'd have user_listing user_detail, user_formfields etc.

Good stuff,


Wow, GREAT new features!

I checked out the latest changes and my excitement waned a bit, in
regards to 1&6.

I had been looping over a collection and calling renderView on each
item. The problem is that my view path is dynamic - it's based off of
the item's entityName. My entities have view directories that contain
a set of views for that entity. So I have:


I had been calling renderView like:

#renderView( view = "/views/#getEntityName( item )#/listing",

And then inside listing, I'd have something like:


Obviously this doesn't work with collection rendering since the view
passed in is static. It also isn't compatible with the changes since
the renderer plugin doesn't call renderViewComposite() and
renderViewCollection() with argument collections (allowing for pass
through arguments).

I'm not sure what the solution to my dynamic entity views and the new
collection rendering support is yet... Maybe someone will have an
idea or two or is doing something similar.


What I was doing

Brett for number 6 you have the argument collectionAs where you set the variable name there instead of by convention of the view name. So you can name it as you please.

Luis Majano
Ortus Solutions, Corp
Toll free phone/fax: 1-888-557-8057
Mobile: 909-248-3408


Can you explain I do not understand you

Luis Majano
Ortus Solutions, Corp
Toll free phone/fax: 1-888-557-8057
Mobile: 909-248-3408


I think the idea of passing to a handler method event,rc,prc is a good idea


Luis Majano
Ortus Solutions, Corp
Toll free phone/fax: 1-888-557-8057
Mobile: 909-248-3408


On your number 4 question you can easily add to an objects scope by listening to when they are created and wiring more stuff to them. That is why we have

After handler creation
After plugin creation
After instance creation

So you can listen when these objects are created and manipulate them.

Luis Majano
Ortus Solutions, Corp
Toll free phone/fax: 1-888-557-8057
Mobile: 909-248-3408


Yeah with the current placeholder convention I would be be using
collectionAs 100% of the time (that is a lot of extra typing,
framework working against me not for me) and that led me to ask why
the convention was based on the view name.

Okay, that is what I am doing now. I'll stick with it. thanks.

What part doesn't make sense? How I use dynamic view paths based on
the entity name or the issue with extending the argument collections
of renderView and renderLayout no longer being supported. Or both?


Lol maybe I am slow this am but all of it. Ehe