Interesting, so how would you determine it, from the routes or from the event metadata? I guess I don’t quite see it yet.
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Hmmm. that’s a great question.
My gut tells me that it should be at the event metadata level. routing should just handle routing. this.allowedMethods={} is more for the security of those methods so if you evaluating event.isHTTPmethodAllowed() or event.isValidHTTPMethod() then it should be looking at the meta data that defines those rules.
I’m open to discussion though. Is there functionality overlap with both of the code snippets I outlined below? Or rather is there a need to define a rule within the route if there is also a rule at the handler level?
Thanks.
Nolan
Yes. Except, I would go so far as to not allow the RC variables not in the list.
function show(event,rc,orc) cache=“true” cacheTimeout=“50” acceptedRC=“cats,hello” { return; }
So, if cats and/or hello exist in the URL/FORM scope they would be copied into RC on requestCapture. However, if someone provides “dogs” in the URL/FORM scope they will be ignored completely.
Now are we talking about event caching or any event?
Wouldn’t RC get confused with Request Context?
Both. If this setting is applied ColdBox will only “import” known and accepted variables into the Request Context (RC). This serves to ensure caching can’t be messed up by junk variables and provides some documentation about the expectations of the handler/action.
kk, now I see the benefit of this.
Would that also mean that the cache would re-get these or that is just wishful thinking?
Andrew, Not sure what you mean by re-get. If the output of the event is cached ColdBox would simply flush that to the output stream and avoid any processing of the Handler/Action.
Yes, but any variables will be cached as well. That is what I meant there…
Also another addition to 4.5 on a side note would be this.
event.RenderNoLayout();
I know you can do it in the view, but if I have the view as the same name as the handler it sort of defeats the purpose of having to retell the framework the name of the view to use. Or is this already capable of being done?
Ccan you expand on this layout thing I didn’t get it
At the moment if we write code like this
public function testHandler() {
}
We can have a view called testHandler.
If we want this handler to have no layout, we are forced to write
public function testHandler() {
event.setView(name="testHandler’, layout=false);
}
my question is why can’t we just type
public function testHandler() {
noLayoutRender();
}
Yah, I'd like to be able to do that too.
Malik
Ask and you shall receive: event.noLayout() is now online
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
For what it’s worth, I modified setView() in my request context decorator to default the noLayout argument to getValue(“nolayout”,false).
That allows me to override the layout adhoc anywhere on my site at runtime by adding ?noLayout=true to the URL. Especially useful if I want to be able to stick a stand-alone event into an iframe or a popup and not have the layout right then. Not quite what you guys were talking about, but it’s along the same vein and might make a nice addition. Of course, if only kicks in if you have an event.setView() call. There might be a “higher” place to implement that so it always works.
~Brad
Just an FYI because I saw someone mention it earlier. Hyrule can work with contexts so you don’t have to validate an entire bean.
validator.validate(user,“password,passwordConfirm”);
I think its a really strong core project now and the only reason more people are not using it is because it lacks documentation + tutorials. I am extremely tied up in side work right now but when I get a breather I will focus on that.
Dan,
Maybe we need to talk then to maybe see how we can make it part of the core with some updates we have in mind, and I will document it.
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
I am still with a lot of the people on here in that I don’t think it should be part of the core. I would like to make it really easy to use in ColdBox though. We should def talk and figure out what is the best way to accomplish this.
My thoughts on this, whilst late to the conversation:
I think out of the box validation within ColdBox would be awesome, without doubt. I mean, the grand vision has always been to build a full stack, right? Validation is something that is so fundamental in day-to-day development that in my eyes, it becomes an integral part of a full stack.
However, I can also appreciate that people like flexibility, and the benefits of using a framework they’re familiar with.
So, what about some form of adaptor pattern. Where we have a validation API, baked into the core of ColdBox, where the underlying library could be switched out, HyRule, ValidateThis etc etc.
This would allow ColdBox to deliver validation as part of it’s core library, with functionality built right into the handlers but remain flexible for developers who want to use their library of choice.
Further to that, it allows us to path-find what people want, if we find a large number of users using the HyRule adaptor then we might decide to consume HyRule into the CB core development, but as the default adaptor, rather than the ‘only’ way of doing things.
Exactly! Great points. Plus I will be honest I haven’t got a ton of feedback on Hyrule… maybe its a huge pile of junk and nobody likes it? I don’t know a ton about validateThis so I am not sure how hard it will be to create an adapter that we can both use.
Yeah, I think it could certainly be a potential approach.
I’m sure it has plenty of challenges that would have to be overcome, however, we would only need to provide the basic usage at an adaptor level, just access to the ‘validate()’ method and perhaps a normalised results object.
I don’t know. Probably worth exploring in more detail with a few use cases.