Exit Handlers Tip

Communities ColdBox HMVC
1

I like to group my exit handlers together in a structure. I also don’t like having a lot of event.setValue() statements in my events.

If you’re on ColdFusion 8, you can do the following (in your event) to clean things up:

var xh = {one=‘main.action1’, two=‘main.action1’, three=‘main.action1’};
event.setValue(‘xh’, xh);

Then, in your views, you can reference your exit handlers as event.getValue(‘xh.one’)

Yeah, I know it’s only two lines of code, as opposed to three, but I think it’s easier to read as opposed to:

event.setValue(‘xh.one’, ‘main.action1’);
event.setValue(‘xh.two’, ‘main.action2’);
event.setValue(‘xh.three’, ‘main.action3’);

The other advantage is that I initially specify my exit handlers in the var scope, which allows me to actually set and view what my exit handlers are at the top of the vent declaration.

-Dutch

2

Hi Dutch,

I even don't like too many unnecessary setValue() stuff.

Easy peasy in event handler
var rc = Event.getCollection(); All request scope is in rc now
var xh = structNew();
xh-one = 'main.action1';
xh-two = 'main.action2';
xh-three = 'main.action3';

in views very simple rc.xh-one is available automatically. This
really save lot of typing and clean approach.

3

Sorry me bad.... ahh copy / paste

var rc = Event.getCollection(); All request scope is in rc now
rc.xh-one = 'main.action1';
rc.xh-two = 'main.action2';
rc.xh-three = 'main.action3';

4

Sana,

Thanks for the tip about ‘rc’ being available in my views.

I was able to do #event.buildLink(rc.xh.continue)# and it worked!

Thanks!

-Dutch

5

I was able to condense it once again

var rc = event.getCollection();
rc.xh = {btnCancel=‘login.new’, errors=‘account.new’, next=‘account.create’};

6

that is a very nice approach. Here is a question for you.

Would it make sense to create a private scope for the request collection?? And create some exit handler api:

event.getPrivateCollection()
event.addxeh()
event.getxeh()
event.getxehCollection()

Just ideas?

7

Luis,

I think its cool ideas but as long as RC scope should be available to views. Without touching current behaviour I am in favour of adding more helper methods.

If event.addxeh() put things in RC scope then may be its cool and will be backward compatible.

Thanks
Sana

8

that is a very nice approach. Here is a question for you.

Would it make sense to create a private scope for the request collection?? And create some exit handler api:

event.getPrivateCollection()

So this is sort of funny. I have already created a “private” collection in my Request Collection Decorator localContext instead of privateContext.

Here are the methods I’m using:
function Configure() {
instance.localContext = StructNew();
instance.localContext.xeh = StructNew();
}

function getLocalCollection() {
return instance.localContext;
}

function getLocalValue(name) {
return Evaluate(“instance.localContext.#arguments.name#”);
}

function setLocalValue(name, value) {
“instance.localContext.#arguments.name#” = arguments.value;
}

function localValueExists(name) {
return isDefined(“instance.localContext.#arguments.name#”);
}

function paramLocalValue(name, value) {
if ( not localValueExists(arguments.name) ) {
setLocalValue(arguments.name, arguments.value);
}
}

event.addxeh()
event.getxeh()
event.getxehCollection()

I just added the above methods (to my Request Context Decorator), but used setXeh() to be consistent

function setXeh(name, value) {
“instance.localContext.xeh.#arguments.name#” = arguments.value;
}

function getXeh(name) {
return Evaluate(“instance.localContext.xeh.#arguments.name#”);
}

function getXehCollection() {
return getLocalCollection().xeh;
}

you can do

var xeh = getXehCollection()
xeh.next = ‘handler.action’;
event.setXeh(‘next’, ‘handler’);
event.getXeh(‘next’);

Just ideas?

I think the real value would be if you make ‘xeh’ available to the view, just like ‘rc’.

So we could do
event.buildLink(xeh.next)
instead of
event.buildLink(event.getXeh(‘next’))
or

-Dutch

9

Luis,

It would be nice to have a private requestCollection, which we can
extend through the requestContectDecorator.

So you could say: event.getPrivateCollection().getValue() or
event.getPrivateCollection().valueExists
The vars could be scoped 'prc' in views ( without calling
event.getPrivateCollection() ) .

Ernst

10

All great and interesting ideas, please keep them coming. I like the addition of a private context to the already event() object.

Keep em coming.

11

I like the idea of a private collection, we’ve discussed the need for something like this for viewlets here.

providing another scope available to the request without interferring with existing params in the rc, would be very useful

12

Ok, so apart from what Dutch wrote in terms of an API for a private collection, can somebody lay out a spec of functions

13

clearCollection()
collectionAppend()
getCollection()
getValue()
setValue()
paramValue()
valueExists()

...Sleepy Ernst

14

Some ideas on methods:
getPrivateCollection()
setPrivateValue()
getPrivateValue()
paramPrivateValue()
privateValueExists()
privateCollectionAppend()

Does that sound good?

Other Idea: Now, should this be in the event object as part of the event object or as another object called: PrivateContext()

So something like this:

event.getPrivateContext().setValue();
event.getPrivateContext().getValue();
prc = event.getPrivateContext().getCollection();

What do you think? Or too much. IDeas??

15

Can we offer mutiple collections?

so we could do
prc = event.getPrivateContext().getCollection();
prc = event.getPrivateContext().getCollection(‘viewlet’);

or even better, piggy back off the existing infastructure and allow

rc = event.getCollection() - would get default context collection or the base RC
prc = event.getCollection(‘private’)
vrc = event.getCollection(‘viewlet’)

just some more ideas

16

Thinking about it some more, should this be something in the core?
Dutch already has a decorator that does the same and well, the decorator was the idea for the context, where ANYBODY could extend it to meet their needs. I am just hesitant to add something to the core that might not be used. Anyways, I am always paranoid when touching core elements, but please make your cases?

Luis

17

Luis,

Why we need to add in core ?

Just this could be done with additional plugin/decorator. Anybody need it use otherwise no need to touch core.
OR
A new setting which may be enable/add request context decorator to load on-demand

Thanks
Sana

18

Luis,

You make a good point. ColdBox offers plenty of ways to extend the core functionality. The request context decorator came in very handy for me when I wanted to create a private scope. It may be handy to others, but not every body will want to use it.

Just like you have a Code Depot for 3rd party interceptors and plugins, maybe we can have a place for folks to put what they’re using in their rc decorators. Maybe this could be as simple as a new category in the forum?

-Dutch

19

Hi Dutch,

If you like to contribute the decorator, then I am more happy to add into code-depot.

Mainly I really like the ideas and we will consider all options.

Thanks
Sana

20

Luis,

I prefer to have a private Collection in the core. It's like the
'normal' event request collection, but then private.
So nothing more than that....

Sure, they can use the requestDecorator example above.....

Ernst