[coldbox:13418] Re: More conventions needed, have asked since 2.6.3

Communities ColdBox HMVC
1

Andrew, I won’t claim to understand 100% of how your apps are structured, but I think Aaron’s point is that WireBox is very flexible and we believe you already have the power to do everything you need.

Firstly, every convention in ColdBox is configurable. If you don’t like the folder name “models”, change your scan location or locations to wherever you want. (I use “CFC”) You can have as many scan locations set up in WireBox as you want. Whether or not they all are subfolders of one higher folder shouldn’t matter to WireBox-- only to you.

Also, to be clear, scan locations are not “scanned” as in some sort of recursive directory search, the paths are just prepended to your CFC path until it is found.

i.e. if you have three scan locations: “common.entities”, “common.services”, “common.utility” and you ask WireBox for a CFC called “products.myProduct”. WireBox will check the following three full component paths (and stop as soon as it finds it)

common.entities.products.myProduct
common.services.products.myProduct
common.utility.products.myProduct

This lookup doesn’t happen until the first time the object is requested. (And then is cached)

The only time WireBox “scans” through an entire directory and maps everything it can find is if you use the mapDirectory() method in your WireBox config. That can be time-consuming, but that is something you told WireBox to do. If you only want to map the CFCs in a specific dir, it’s up to you to instruct WireBox which directories to traverse. If you have so many CFCs that CF times out, how will a naming convention help that?

Perhaps you can help me by describing a folder structure you would like to use and specifically what roadblocks you are hitting that don’t allow you to do that with WireBox.

Thanks!

~Brad

2

Brad,

Lets forget about wirebox, for a minute shall we.

And lets look at ContentBox, the entities and models and services are stored in the same folder. I would like to know why? All I am asking is that ColdBox do this and notice how I have already name my folders something else?

conventions = {
handlersLocation = “system/controllers”,
pluginsLocation = “system/plugins”,
viewsLocation = “system/views”,
layoutsLocation = “system/layouts”,
modulesLocation = “system/modules”,
modulesExternalLocation = “user/modules”,
modelsLocation = “system/model”,

servicesLocation = “system/services”,

};

Services are not models, and every other MVC framework outside of ColdFusion separates services from models so why don’t we? And I will say it again, its good enough for the actual framework to separate the services from everything else, but its not good enough for our code to have a convention for it.

Now I am able to get around it by writing an interceptor to do this, but I strongly believe that the services convention should be included under the hood in ColdBox. That’s all I am asking.

3

Have you blogged about this Andrew? I've had a quick look and can't
see anything. A good post explaining the separation and why it's
important, especially w/ start up performance, may help your cause -
even if the convention does not enter the ColdBox core, the wisdom
could still get out there.

4

Dominic, I don’t need to blog about the separation of the model tier as it is already well documented best practices in a number of programming languages.

As for the performance, side of things, this again is well documented and why Adobe added the CFClocation to the application settings scope for ORM. I don’t think there is any more I can add to this, that is not already out there.

Now as for my request, lets look at this further. If you want me to blog more about this then I would be happy too, but there is enough information on this out there already.

First of all we all should know what MVC stands for, and this is what came about because of SoC or Separation of Concern. The M part of this is for anything that is consider application specific business logic, so when we break this down we find that M is in actual fact our Domain Model or Data Model, it is our business logic and to some degree our Service Layers.

All 3 of these should be separated again in all application design, if you want to follow best design pattern practices and is why grails has done just that, it has separated these 3 into their own directories. And it is because of this design pattern, that people have done this for many years, now Luis must also agree to this in some part as well, otherwise when he built ColdBox he would not have separated the services from the rest of the framework.

My point is I would like to see the same thing in ColdBox, now it doesn’t mean that older applications will not work, it just means that we can still have a way to continue to adopt these practices. In other words, you are not forced to place your services into the services directory, and you could still do this if you want and the application will still work the same.

However all I am suggesting is that ColdBox continue with current best practices, like grails as an example and provide the means to also allow us to separate to a service layer by convention, as well as domain / entitie if people require DI in those.

Now I am not sure what most of you know about service layers, but service layers could be a window to anything, like a database tier, web service layer or anything else that could be considered further separation from the Application Business Logic. That means one could very well write a Service Factory, that could without the Applications knowledge refer to any one of these without the Application being aware of it.

For example you may write a service factory that is to go and grab a tweet or tweets from twitter, but if that service is down you may opt to then grab a copy from the cached version or even a copy that is stored in the database.

Now although these are Service Layers, they are also not technically considered Application specific models either, which is debatable depending on who you talk too.

But the point is that this is an example of why one should consider Service layers as separate to application specific models, and also a good reason why ColdBox should adopt along the same lines of Grails.

This doesn’t mean anyone else is forced to follow this rule, it just means there is support there for those who want to continue with best practices. I am not asking for everyone else to agree on their methods of development, I am just asking for the ability to allow for it. And I used my current situation as an example, because I did follow these best practices, and I did ask 3 years ago for this to be considered and I am again asking the same thing. Only because when I do release some of my projects, it will be compatible with the framework, without people having to jump through hoops by adding more unnecessary interceptors to allow for it.

5

I think that a post detailing the features and performance benefits
that would be provided by having ColdBox know a more detailed picture
of how you layout your model would be useful (and perhaps a good
read). After all, one can still separate one's model without ColdBox
knowing about it (and I'd imagine most developers don't just stick all
there CFCs directly under the model folder). What exactly a ColdBox
developer gains from a more granular ColdBox convention would be an
interesting topic.

Dominic

6

Dominic I take it you dont know how CF-ORM works then?

7

"More conventions needed. Have asked since..." Clearly someone
disagrees or doesn't agree strongly enough - I'm just suggesting that
you use some better persuasion paths (and table manners).

8

Well Dominic, I think I have given more than plenty of reason for services to be by convention and configurable like handlers, plugins etc.

As for performance, there is no ifs or butts to it. Adobe clearly added cfclocation so that people could define paths to the entities to help reduce the time it takes for an application to search through all the components to decide whether they are entities or not, I just don’t understand why I would need to blog about that further than what is already out there?

And if you read my last message to this list, then you may also understand why I might like to see entities by convention also.

You see for the last 3 years I have been able to automatically change my entity paths, based on the fact that I use a specific directory for entities in modules. Recently I have been trying to find away to incorporate this into ColdBox, but hit a snag because of a bug in how application.cfc currently works.

But for that to even be considered to be added to core ColdBox, one would need to have the following in ColdBox.cfc

conventions = {
handlersLocation = “system/controllers”,
pluginsLocation = “system/plugins”,
viewsLocation = “system/views”,
layoutsLocation = “system/layouts”,
modulesLocation = “system/modules”,
modulesExternalLocation = “user/modules”,
modelsLocation = “system/model”,
domainsLocation = “system/domains”,
servicesLocation = “system/services”
};

In which then the moduleConfig would then follow suite, now if it was following this convention I could call my directories domains, or you or anyone else could call them entities. That’s what the beauty of ColdBox by convention is all about.

And coupled with the changes I had in mind, if one was going to be using CF-ORM then you would not have to modify your cfclocation, because ColdBox would automatically do it for you.

Now even taking conventions for entities out of the picture for a minute, I made it very clear that this did not have to be by convention, unless you wanted to DI anything into your entity. If one wanted to do this, then they would be forced to stick the entities into the model directory. And I also made it very clear that when you begin to develop a large application the less files ColdFusion has to inspect for entities the faster it will run and less likely to time out, I don’t need to blog about this its very common knowledge and why cfclocation exists in the first place.

Services is another story, and I am not going to rehash what I have already said.