Sharing Filters Between Controllers Needs to be Redesigned

[ColeFusion]

I just found cfwheels today and I'm extremely excited about finding
it. Oddly, I have been looking for a framework that I liked, for
ColdFusion, for the past few weeks and had trouble finding one. I just
wanted a framework that had a good MVC implementation and reminded me
of Django. I think it's safe to say that cfwheels is that extact
framework.

I do have one complaint at the moment, though. I was reading over the
docs like any new user, and I came across the filters section. I was
excited to see that filters existed, their functionality and
usefulness is apparant right off the bat. But, then when I got to the
part about sharing filters between controllers I was completely
shocked. The suggested way of doing this is to add my own functions to
the framework's base Controller class!? I had to read over it a few
times to make sure I understood correctly.

In my opinion, this is pretty poor design. This couples an entire site
to a single instance of cfwheels. In no scenario should it be
suggested that a developer modify the frameworks code to do something
like this. What if a user is using a subversion copy of cfwheels, and
updates the code and the Controller class file changed? It'll remove
the custom functions. What if a user is migrating to a different
server, and different install of ColdFusion / Wheels? Remembering to
grab your code out from the framework's Controller class isn't
something that should be necessary.

I'm not telling people not to use Wheels, because it looks simply
amazing. I'm going to be using it for a long time to come. But I'd
like to bring this point to light so maybe it gains some attention and
gets changed. Something that allows for a more decoupled way of doing
this would be much, much better.

[Per Djurner]

It may be just semantics but I don't consider
controllers/Controller.cfc part of the framework.
It extends Wheels.cfc which I consider part of the framework though.

If you're just referring to the fact that Controller.cfc is
pre-created for the user then you'll be disappointed to see that there
are quite a few of those files actually (and folders as well).
It has its advantages though; makes it easy to get up and running
quickly without having to read lots of documentation of what files to
create, what they need to extend etc.

If you have any suggestions for changes I'd love to hear them :)

/ Per

> --
>
> You received this message because you are subscribed to the Google Groups "ColdFusion on Wheels" group.
> To post to this group, send email to cfwh...@googlegroups.com.
> To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cfwheels?hl=en.
>
>
>

[Per Djurner]

Oh, and welcome to Wheels btw :)

[Randy Johnson]

I went in and check the Controller.cfc

It has in it:

<!---

This is the parent controller file that all your controllers should extend.

You can add functions to this file to make them globally available in all your controllers.

Do not delete this file.

--->

<cfcomponent extends="Wheels">

</cfcomponent>

So I would think that this isn't really adding stuff to the frame work code, all of that resides in the Wheels directory right?

Randy

[Per Djurner]

Depends on how you look at it I guess but, yes, all the code that
actually does anything is all in the "wheels" folder.
All files that are part of the distribution but not inside the
"wheels" folder are either placeholders for developer code or just
includes or extends into the "wheels" folder.

[John C. Bland II]

ColeFusion, I had the same issue when I first saw Wheels. As pointed out, Controller.cfc isn't part of the framework. It is there for you to use as a base class.

Per, I don't think the implementation needs to change just the docs. Having watched the threads (and commented on or started a few) there seems to be a lot of repetitive confusion about a few things. Cleaning up the docs and making these painfully clear will help resolve a bunch of the issues.

For instance, clarify why the Controller.cfc exists for each article/page in the docs where it is referenced or at a minimum link back to a page explaining the file.

Just a suggestion.

---
John C. Bland II
http://www.johncblandii.com
http://www.johnandseason.com
http://www.twitter.com/johncblandii
---
Suggested sites:
http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them"
http://www.sportsmatchmaker.com - "What are you doing today?"

[Mike Henke]

I think John's suggestion is great. Maybe ColeFusion could draw up a
small rewrite since he is new and after this thread might have a
better phrasing for newbies.

@ColeFusion - Could you expand on this, "This couples an entire site

[Andy Bellenie]

I think ColeFusion is referring to the fact that the Base Controller
file, seemingly part of wheels, means that your application specific
controllers to the wheels code. I don't think he realised it's there
explicitly as a base class, and that it merely extends the actual
wheels code in the wheels folder.

Personally I'm very much in favour of having all the wheels code as a
mapping instead, then you remove any of this confusion, and can run
multiple sites of a single code base, and quickly switch between code
for testing purposes (and I've a personal hatred of relative paths...)

I think this is something to be considered for a later version -
although I don't know if any decisions have been taken on it yet.



2009/12/9 Mike Henke <henk...@gmail.com>:

[ColeFusion]

Well, ok. I guess I was a little unclear as to what exactly
Controller.cfc, itself, was. Now that I understand that it is
basically a placeholder for you to use in your site project, it makes
more sense. I like to hear that all of the "important" code relative
to Wheels resides in the Wheels directory. Since this is the case, the
implementation is fine. As John said, maybe the docs need to reflect
this point. I read through the docs page a few times earlier today and
didn't feel hinted at the fact that it's just an extension, and that
it's there *for* us to edit. I was under the impression that it was a
framework-related file and contained code relative to the underlying
Controller functionality. Because of the docs, I didn't even inspect
the file itself. If I had, I might have understood that its' purpose
is for us to actually add our shared filters there. I think the
wording of the docs makes it sound it's a fall back option, and not
the actual intention of that file.

@Mike Henke: Sure. My original assumption, earlier today, was that the
Controller.cfc file contained code that provided the underlying
functionality for the Controllers. I thought it was a vital, important
part of the Wheels framework. I didn't bother to actually inspect the
file's contents, because of the way the docs described it, I think.
(entirely my fault. I was at work and neglected to view the actual
file in question) Had I inspected the file I would have probably drawn
up a different conclusion. You can see, though, that under my original
thinking, adding my project specific code to a vital framework code
file would tie my site's code to that installation of the framework.
Meaning, my code would be coupled with that single Wheels instance in
a bad way. I don't think developer code should mingle with framework
code very closely. In fact, I really like the way the Controller.cfc
file works now. Now that I understand that it's basically a medium
between Wheels and the developers Controllers, I am liking that a lot.

Sorry for any confusion or anything. Now that I'm clear on this,
Wheels is sounding too good to be true. :P

Thanks for all the replies.

[ColeFusion]

Ok, after working with this more today, I do have a suggestion.

It looks like Wheels.cfc, in the Controllers directory, is slightly
more important to the framework than Controller.cfc. Perhaps the
Wheels.cfc file could just be relocated into the wheels directory?
Then, Controller.cfc could just extend it from there. This would clean
up the Controllers directory and developers wouldn't have to be aware
of that Wheels.cfc file in the Controllers directory. Unless the
Wheels.cfc file also offers some kind of functionality to the
developers.

[Per Djurner]

It used to be that way actually but a bug in Railo related to mappings
forced us to move it out for now.
We'll probably move it back at some point in the future.