Needs for 4.5

Communities ColdBox HMVC
21

Hey Andrew

"Can you explain more on the CFC based viewlets? Personally cfm templates should be for views and CFC for everything else."

Yeah .cfm being the convential way of doing MVC views. Referencing the ColdBox Doc a Viewlets can be defined as:-

“…a self sufficient view. A view that can live on its own, its data is pre-fetched and can just be renderer as is.”
http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbLayoutsViewsGuide#Viewlets

My argument is, what’s the difference between these and how a CFC works in the model? ColdBox has Plugin support I know but what I’m talking about is taking something like a JS DataGrid, encapsulating that in a Viewlet CFC and giving a user Coldbox support for something like :-

event.setView(jsData.displayByQuery(myQuery)).

With ColdBox looking for a View CFC of the name jsData.

"I just don’t see how a CFC viewlet would be beneficial."

Aside from the points I mentioned in the previous post?

It’s maybe not beneficial over what’s there just now in terms of View management but it could be looked at as an alternative convention-based approach.

Taking the theory a step further. Normally you’re handler / view folder structure would look something like this:-

Handlers
– handler1
– handler2
Views
– handler1
— view1
— view2
— view3
– handler2
— view1
— view2
etc.

A View CFC approach could see things slimmed down into a structure like this…

Handlers
– handler1
– handler2
Views

  • handler1.cfc
  • handler2.cfc

With each view .cfc matching a handler and containing methods view1,view2 etc.

I know HTML is a bit of a Taboo when it comes to CFCs but seeing how loose / open to abuse our project’s views currently sit I could see this as a benefit in controlling what’s actually passed in and used in the views.

Cheers,
James

22

Hi guys,

there’s some serious dialogue going on for a some in-depth needs for 4.5. would it be valuable to create some sub-threads so larger discussions around a particular “need” can remain in their own thread? Just a thought because I don’t want to hijack this topic

i’m going to sneak this “need” into this thread …

Perhaps there is already a way to accomplish this…

In routes, and in handlers you can set method security to protect the HTTP actions that execute an event. It would be great if there is a framework method that can be accessed higher up in the request scope to determine if the executing event validates against the allowedMethod rules. Its is my understanding that currently this can only be trapped in Main.cfc onError() by evaluating the type of error. It would be great to be able access this within a preProcess() or aroundHandler() before it gets far down the chain.

Thanks.

Nolan

23

Sorry James, I don’t see the benefit…

24

No it can also be part of the security interceptor, but I like where you are leading. There is attributes that can be applied to events that can be sort of used this way. But if you are referring to role based security then this will need to be handled by the security interception and how it works to your rules.

Is that what you were meaning or am I off base?

25

Hi Andrew,

I agree that it could be added to the security interceptor, but it may be valuable to evaluate the invalid request at the handler level (in an aroundHandler) if the app wasn’t using the security interceptor.

I don’t think this relates to role based security, but rather route security and method security.

i.e in routes:

addRoute(pattern="/users/:userid",handler=“User”,
action={
GET = “getUser”,
PUT = “updateUser”
});

and in User.cfc handler:

// HTTP Security
this.allowedMethods = {getUser=‘GET’,createUser=‘POST’,updateUser=‘PUT’};

so, essentially i’d like to determine that a POST is trying to be executed on a route that only allows GET’s and handle accordingly further up in the request as opposed to an error being thrown and have to handle in onError()

Thanks.

Nolan

26

Out of curiosity what type of error is thrown?

27

<h3>Application Execution Exception</h3>` `` Error Type: SES.405 : 405
`` ```<strong>Error Messages:</strong>
Invalid HTTP method: GET<br />` The HTTP method used: GET is not valid ``for the current executing resource. Valid methods are: {POST={createUser}}`

````

28

This will eventually get lost in the sea of ideas, but I would really
love to see more capabilities in the BaseORMService.

Namely, more with criteria queries, dealing with projections and group
by - I'm a big fan of this.

29

I suggest expanding Forgebox. The framework core is already pretty feature rich.

Jason Durham

30

I agree with Nolan.

This may help us? http://coldbox.uservoice.com/

31

On this topic of views, this already exists with the concept of renderView(args={}) and passing name value pairs that are evaluated in the views. So you could technically apply #args.username# or #args.name# and call your views much like how you call a method.

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

Social: twitter.com/lmajano facebook.com/lmajano

32

On viewless you have the olds docs link, this is the new docs: http://wiki.coldbox.org/wiki/Layouts-Views.cfm#Viewlets_(Portable_Events)

You can create viewlets as CFC event handlers now in 3.0

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

Social: twitter.com/lmajano facebook.com/lmajano

33

Nolan, this is a little contradictory also because you have this:

addRoute(pattern="/users/:userid",handler=“User”,
action={
GET = “getUser”,
PUT = “updateUser”
});

Which splits the routes on the http verbs, so if you add the “allowedMethods” into the User handler, that exception will not be thrown at the handler level but the route level. So in reality since your route defines the HTTP verbs, then only those work, then ones local to the handler are never reached.

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

Social: twitter.com/lmajano facebook.com/lmajano

34

Namely, more with criteria queries, dealing with projections and group
by - I’m a big fan of this.

I totally agree Don, I think what we have in the base and virtual services is a great place to start. We can just get better and improve this more. I have been using criterias and projects and there is definitely room for improvement. I am thinking of extending this to a criteria DSL language so you don’t have to deal with some convoluted hibernate methods.

Maybe we can create a new thread about all the ideas and then come up with a roadmap for them.

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

Social: twitter.com/lmajano facebook.com/lmajano

35

Aaron, I didn’t quite get your enhancement, are you saying create constraints for event caching? Maybe like:

function show(event,rc,orc) cache=“true” cacheTimeout=“50” cacheAllowedRC=“cats,hello”{

}

And event caching permutations are only allowed on the existence of CATS OR HELLO or CATS AND HELLO?

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

Social: twitter.com/lmajano facebook.com/lmajano

36

ForgeBox additions should definitely be something we all contribute to also. I am thinking of maybe taking all the core ColdBox debugger panels, timers, etc and converting them into a module and removing from the core. Thoughts?

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

Social: twitter.com/lmajano facebook.com/lmajano

37

Hi Luis,

Thanks for the info. Regardless of which is used though, is there a framework method that can be accessed to determine if the verb being used on a method is invalid? If not this would be a great enhancement.

Nolan

38

I am still wondering if it would be better to have this caught by an onInvalidEvent?

39

Hi Luis,

I’ve had a few conversations with Aaron about this so I’ll add my two cents. Correct me if i’m wrong please Aaron.

If it were implemented as an attribute i would say it should be called … allowedRC=“cats,hello”. The cache is a secondary part that is handled at the end of the request (in Aaron’s case). The idea would be that the “allowedRC” variables are the only vars allowed in that method, and all others should be stripped out of the RC (…this is just my assumption…aaron should clarify).

The point he makes around ordering the vars alphabetically is also important and perhaps is another feature or a setting that can be added. this can be particularly important when hashing and caching the request.

Thanks.

Nolan

40

I think it’s too far down the chain at that point.

i’m thinking of this from a REST API standpoint…

In the same way I would validate API keys or authorization credentials In my security interceptor I would also want to be able to call a method like event.isHTTPmethodAllowed() or something like that to determine that someone is trying to to a POST on a GET method and then send back the appropriate error response / override the event.

Nolan