Other Framework thoughts

240 views
Skip to first unread message

John Allen

unread,
Dec 15, 2010, 3:28:44 PM12/15/10
to framew...@googlegroups.com

Hey FW/1’s

This is a theoretical question.


I do all my development in FW/1 (LOVE IT!) and I do have extensive experience with ModelGlue, ColdBox, and have built contact managers in CF-Wheels and Mach-ii.


Is there ANYONE on this list that can think of ANY reason to do new development in anything other than FW/1? MG, Mii, Wheels offer some neat features, but enough to use them?


I appreciate the “it depends” answer, team may want to use another framework… cant extend Application.cfc for some reason… bla… bla…


This is very biased question admittedly, but I just find FW/1 pretty much perfect; the “invisible framework”.


Just a question.


Thanks

John Allen

Nathan Dintenfass

unread,
Dec 15, 2010, 3:40:22 PM12/15/10
to framew...@googlegroups.com
Short answer: no.

Seems the only real arguments would be if the other, heavier frameworks
gave you functionality that you'd otherwise have to build or stitch in
some other tool for. There's some argument to be made, I suppose, that
FW1 is new enough that it's "untested" and, more importantly, has not
yet proven it will continue to have a thriving development community
over the long haul (though, arguably that's true of all the other CF
frameworks -- or even [GASP] of CF itself).


On 12/15/10 12:28 PM, John Allen wrote:
> Hey FW/1�s


>
> This is a theoretical question.
>
>
> I do all my development in FW/1 (LOVE IT!) and I do have extensive
> experience with ModelGlue, ColdBox, and have built contact managers in
> CF-Wheels and Mach-ii.
>
>
> Is there ANYONE on this list that can think of ANY reason to do new
> development in anything other than FW/1? MG, Mii, Wheels offer some neat
> features, but enough to use them?
>
>

> I appreciate the �it depends� answer, team may want to use another
> framework� cant extend Application.cfc for some reason� bla� bla�


>
>
> This is very biased question admittedly, but I just find FW/1 pretty

> much perfect; the �invisible framework�.


>
>
> Just a question.
>
>
> Thanks
>
> John Allen
>

> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/seancorfield/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one

John Allen

unread,
Dec 15, 2010, 4:09:33 PM12/15/10
to framew...@googlegroups.com
I can vouch that FW/1 is TESTED and is proving to be more awesomer and awesomer everyday! :)

On Wed, Dec 15, 2010 at 3:40 PM, Nathan Dintenfass <nat...@dintenfass.com> wrote:
Short answer: no.

Seems the only real arguments would be if the other, heavier frameworks gave you functionality that you'd otherwise have to build or stitch in some other tool for.  There's some argument to be made, I suppose, that FW1 is new enough that it's "untested" and, more importantly, has not yet proven it will continue to have a thriving development community over the long haul (though, arguably that's true of all the other CF frameworks -- or even [GASP] of CF itself).





On 12/15/10 12:28 PM, John Allen wrote:
Hey FW/1’s


This is a theoretical question.


I do all my development in FW/1 (LOVE IT!) and I do have extensive
experience with ModelGlue, ColdBox, and have built contact managers in
CF-Wheels and Mach-ii.


Is there ANYONE on this list that can think of ANY reason to do new
development in anything other than FW/1? MG, Mii, Wheels offer some neat
features, but enough to use them?


I appreciate the “it depends” answer, team may want to use another
framework… cant extend Application.cfc for some reason… bla… bla…



This is very biased question admittedly, but I just find FW/1 pretty
much perfect; the “invisible framework”.



Just a question.


Thanks

John Allen

Sean Corfield

unread,
Dec 15, 2010, 7:01:49 PM12/15/10
to framew...@googlegroups.com
On Wed, Dec 15, 2010 at 12:28 PM, John Allen <johnf...@gmail.com> wrote:
> Is there ANYONE on this list that can think of ANY reason to do new
> development in anything other than FW/1? MG, Mii, Wheels offer some neat
> features, but enough to use them?

I may be a little biased - just a little :) - but I'm working on a
large app that is built with ColdBox (a decision made before I joined
the project and, frankly, before FW/1 existed) and I wish every day I
was using FW/1 instead of ColdBox.

Sure, ColdBox has LOTS of functionality built-in but I feel I'm
fighting against it all the time because I'm doing a lot of the 20%
that ColdBox's 80% doesn't cover... and that's my general problem with
full-stack frameworks.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

Mike Henke

unread,
Dec 16, 2010, 11:20:23 AM12/16/10
to framework-one
"Is there ANYONE on this list that can think of ANY reason to do new
development in anything other than FW/1?"

Main idea is try a framework and if it doesn't fit for you, try
another. I think the key is your background, coding style, and project
details. ColdFusion has a framework that should fit for you. Please
don't roll your own framework unless for learning purposes.

Nathan Strutz

unread,
Dec 16, 2010, 1:07:46 PM12/16/10
to framew...@googlegroups.com
I like what Mike says.Your framework choice is a matter of of personal taste. You should try them all and see which one fits you and your team best.

That said, FW/1 is more than capable of handling any type of project. I've heard some people say they think it's only really suited for small projects, and I can't figure out why they would get that idea except that it's a small framework (1 file).

nathan strutz
[http://www.dopefly.com/] [http://hi.im/nathanstrutz]


Kerr

unread,
Dec 17, 2010, 1:07:32 AM12/17/10
to framework-one
I don't post much, but I read this group regularly as I'm in the
process of evaluating frameworks for my team. I'm curious about the
20%/80% issue you noted. What in particular is falling into that 20%
with your large CB project?

On Dec 15, 6:01 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Wed, Dec 15, 2010 at 12:28 PM, John Allen <johnfal...@gmail.com> wrote:
> > Is there ANYONE on this list that can think of ANY reason to do new
> > development in anything other than FW/1? MG, Mii, Wheels offer some neat
> > features, but enough to use them?
>
> I may be a little biased - just a little :) - but I'm working on a
> large app that is built with ColdBox (a decision made before I joined
> the project and, frankly, before FW/1 existed) and I wish every day I
> was using FW/1 instead of ColdBox.
>
> Sure, ColdBox has LOTS of functionality built-in but I feel I'm
> fighting against it all the time because I'm doing a lot of the 20%
> that ColdBox's 80% doesn't cover... and that's my general problem with
> full-stack frameworks.
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/

Sean Corfield

unread,
Dec 17, 2010, 2:25:52 AM12/17/10
to framew...@googlegroups.com
On Thu, Dec 16, 2010 at 10:07 PM, Kerr <hay...@gmail.com> wrote:
> I don't post much, but I read this group regularly as I'm in the
> process of evaluating frameworks for my team.  I'm curious about the
> 20%/80% issue you noted.  What in particular is falling into that 20%
> with your large CB project?

It's a fair question since my comment was somewhat inflammatory :)

Here are some of the problems we've run into:
* Multi-domain caching (ColdBox isn't designed for multi-domain sites
according to Luis)
* Multi-domain SES URLs (see above)
* Dependency Injection is lazy and doesn't mix well with ColdSpring
(Luis said either use ColdSpring for everything or use ColdBox
injection for everything - don't mix them) ***
* We ran into countless bugs in various areas that clearly other
people don't use (including LogBox, the MXUnit test harness, i18n...)
* Performance analysis shows nearly all the application's time is
spent in Reactor and ColdBox.

We're already working hard to move off Reactor.

Now, admittedly, we started with an early alpha of ColdBox 3 (because
we needed to implement skinning and required the plugability that CB3
supposedly provides) and we kept upgrading to new builds during the
project. We're currently on M3 and, after experiencing breakages on
each Milestone build, we have no intention of upgrading to M4 or
beyond. ColdBox is about 40k lines of code. Even after 18 months of
development, our project is only about 30k lines of code. That just
feels wrong to me. Once we have a solid migration plan, we'll migrate
to FW/1...

*** We have to use ColdSpring because we use Reactor and need to rely
on Reactor's bean injection which needs ColdSpring.


--
Sean A Corfield -- (904) 302-SEAN

Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

Smith, Douglas

unread,
Dec 16, 2010, 11:53:12 AM12/16/10
to framew...@googlegroups.com
Mike // all -

Regrettably, I've done just this. Over several years a CF app critical
to work has grown so large that I'm now researching transitioning to an
established framework. It's just too darned big. The app is a classic
hub-and-spoke model. Users will have access to some spokes ("modules"),
but not others. And within each module, standard read/add/edit/delete
privs apply. Modules range from workflow tools to reports... we've got
it all.

Just this morning I started researching FW/1. Can you recommend any
resources I could leverage to see with established framework might fit
best?

Doug

 

Arnoldworldwide
Douglas Smith
VP Director of Application Development

101 Huntington Avenue
Boston, MA 02199
617.587.8257
dsm...@arn.com

 
Arnold is a global communications company and one of the top five most creatively awarded agencies of the past decade. We are proud to represent a diverse portfolio of clients, including Aetna, Alberto Culver, Amtrak, Carnival Cruise Lines, CVS/pharmacy, Fidelity Investments, The Hershey Company, Huntington Bank, Jack Daniel’s, McDonald’s, New Balance, Ocean Spray, Panasonic, Pearle Vision, Progressive, Southern Comfort, Titleist, truth®, Tyson Foods, Vertex, Volvo and many other great brands. Arnold delivers services across all communication touch points – advertising, digital, promotions, direct, design, branded content – and is part of Havas Worldwide with offices in Boston, New York, Washington DC, Toronto, London, Amsterdam, Prague, Milan, Madrid, Moscow, Lisbon, Sydney, São Paulo and Shanghai.
www.arnoldworldwide.com
--------------------------------------------------------------------------
THIS EMAIL MAY CONTAIN CONFIDENTIAL INFORMATION AND IS SOLELY FOR THE USE OF THE INTENDED RECIPIENT. ANY REVIEW, DISTRIBUTION, DISCLOSURE OR OTHER USE OF THIS INFORMATION BY ANYONE OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED. IF YOU HAVE RECEIVED THIS COMMUNICATION IN ERROR, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DELETE THIS MESSAGE FROM YOUR SYSTEM.
-----Original Message-----

--

Sean Corfield

unread,
Dec 17, 2010, 2:41:03 AM12/17/10
to framew...@googlegroups.com
You have my sympathy Doug. Anyone with a corporate .sig that long has
all my sympathy! Netiquette suggests .sigs should be at most four
lines. When a company consciously violates that, it tends to have
deeper problems that show up across everything the company does,
including its software... :)

Sean

Smith, Douglas

unread,
Dec 17, 2010, 8:50:15 AM12/17/10
to framew...@googlegroups.com
What's worse is that I have no control over the sig! It's automatically appended to every email we send from our corporate account.

... which means I'll be re-subscribing here shortly using my home acct.


 

Arnoldworldwide
Douglas Smith
VP Director of Application Development

101 Huntington Avenue
Boston, MA 02199
617.587.8257
dsm...@arn.com

-----Original Message-----

From: framew...@googlegroups.com [mailto:framew...@googlegroups.com] On Behalf Of Sean Corfield
Sent: Friday, December 17, 2010 2:41 AM
To: framew...@googlegroups.com
Subject: Re: [framework-one] Re: Other Framework thoughts

You have my sympathy Doug. Anyone with a corporate .sig that long has
all my sympathy! Netiquette suggests .sigs should be at most four
lines. When a company consciously violates that, it tends to have
deeper problems that show up across everything the company does,
including its software... :)

Sean

On Thu, Dec 16, 2010 at 8:53 AM, Smith, Douglas <DSm...@arn.com> wrote:

> Arnold is a global communications company and one of the top five most creatively awarded agencies of the past decade. We are proud to represent a diverse portfolio of clients, including Aetna, Alberto Culver, Amtrak, Carnival Cruise Lines, CVS/pharmacy, Fidelity Investments, The Hershey Company, Huntington Bank, Jack Daniel's, McDonald's, New Balance, Ocean Spray, Panasonic, Pearle Vision, Progressive, Southern Comfort, Titleist, truth®, Tyson Foods, Vertex, Volvo and many other great brands. Arnold delivers services across all communication touch points - advertising, digital, promotions, direct, design, branded content - and is part of Havas Worldwide with offices in Boston, New York, Washington DC, Toronto, London, Amsterdam, Prague, Milan, Madrid, Moscow, Lisbon, Sydney, São Paulo and Shanghai.


> www.arnoldworldwide.com
> --------------------------------------------------------------------------
> THIS EMAIL MAY CONTAIN CONFIDENTIAL INFORMATION AND IS SOLELY FOR THE USE OF THE INTENDED RECIPIENT. ANY REVIEW, DISTRIBUTION, DISCLOSURE OR OTHER USE OF THIS INFORMATION BY ANYONE OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED. IF YOU HAVE RECEIVED THIS COMMUNICATION IN ERROR, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DELETE THIS MESSAGE FROM YOUR SYSTEM.

--

Mike Henke

unread,
Dec 17, 2010, 9:33:11 AM12/17/10
to framework-one
Honestly, transitioning any existing application to an existing
frameworking it tuff to say the least. I would start any new projects
with a framework and keep maintaining the existing projects. Once you
have several projects under your belt, then you might be able to more
quickly switch over an existing application.

Check out CFWheels also. I really love it :-)

David Burns

unread,
Dec 17, 2010, 1:28:20 PM12/17/10
to framew...@googlegroups.com
I can comment on the "only suited for small projects" perception. To be clear, I don't agree. But I understand the perception. FW/1 is extremely lightweight. There's sophistication and power there but it seems mainly about the true core of an app, e.g. conventions around service/view separation, file layout, etc. What's not there is more of the "classic" stuff people are used to getting for free once they've chosen a framework. For instance, a feature-rich logging system or a feature-rich authentication system (users, permissions, etc.). So, if I'm researching what framework is best for my next app, I see FW/1 and I think "Looks great! Wait, for logging/authentication I'm going to have to write my own or research something else to integrate and test so this thing isn't truly enterprise-ready is it?" (Remember, I'm playing devil's advocate here.) When I hear someone say FW/1 isn't suited for large projects, what I'm really hearing them say is akin to, "I want a framework that gets out of my way but I still need a system where someone has already thought about plumbing like AJAX authentication so I don't have to." I'm curious to hear what peoples' take is on that: should FW/1 grow to include that or is that so difficult to generalize well that it leads to someone going off and writing a new, single-CFC framework as a response? :-)

FW/1 is interesting to me because the mantra is being lightweight (I'm a big fan of the idea) but different people draw the line in different places and inevitably FW/1 will grow. What if I could get FW/1 with a logging system built-in that took the same lightweight design ethic? I might like that. Not sure what FW/1 will look like in 3 or 4 years.

I guess where I'm rambling to is, I'm conflicted: on the one hand, I like how small FW/1 is and I think it should stay that way. On the other hand, it'd be great to have out-of-the-box areas of functionality that I could take or leave and that follow the same mantra. Is there such a thing as logging or authentication by convention? If a CFC is placed somewhere and supports an API (sort of like "setBeanFactory") then could FW/1 log to it, auto-decorate services with logging proxies, etc.?

[ Don't mean to dwell on logging but it's an easy example. ]

db

Sean Corfield

unread,
Dec 17, 2010, 2:00:43 PM12/17/10
to framew...@googlegroups.com
On Fri, Dec 17, 2010 at 10:28 AM, David Burns <davebur...@gmail.com> wrote:
> For instance, a feature-rich logging system or a feature-rich authentication

My experience is that frameworks which provide these things either
still require you to write most of it yourself (because it provides
only 'plumbing' and extension points) or it provides 80% of what you
need but then the remaining 20% takes you 80% of your time.

LogBox is a great example of this. It's very sophisticated but there
are a lot of common use cases it doesn't support well. For example:
changing logging levels per environment. It took me several days to
get it configured the way I needed - and I had to write several custom
components that extended various logging components. Very flexible,
very sophisticated but, at the end of the day, I could probably have
run up an entire customized logging system in the time it took me to
configure and extend the base components.

I've generally found the same issues with authentication. I started
out using ColdBox's security mechanism but in the end it got in the
way of what our application needed and we stripped it back down and
wrote a custom security component.

The same story applies to caching, i18n and a number of the built-in
ColdBox features.

ColdBox is an amazing achievement and for a large number of web apps
it's "good enough" for the 80%. Once you start to need to customize
the features, you start down a path where it's often more work to do
the customization than to write your own from scratch (especially if
you find yourself fighting against the framework due to design issues
or bugs).

What I'd like to see around FW/1 is a community of small, lightweight
'plugin' components that handle these supposedly common tasks. Some
have already started appearing on RIAForge, which is great. But the
design principles of FW/1 determine that it should handle 'only' the
MVC routing / controller stuff. It provides some easily overridable
hooks for certain behaviors that people want to modify.

One thing that FW/1 will get - when I get time - is a companion DI /
IoC bean factory (called DI/1 of course) that will be a single CFC,
convention-based utility for managing CFCs.

Over time, it may get other 'official' utilities but I suspect most
will be community efforts, designed to tackle the broad range of needs
in various areas.

David Burns

unread,
Dec 17, 2010, 2:14:56 PM12/17/10
to framew...@googlegroups.com
Sean - Thank for the quick reply. I understand very much the idea that if a framework gets too ambitious in scope then, after a while, its user ends up fighting it. I've been there and that's why I like FW/1.

I'm trying reconcile two points you just made though. On the one hand you don't think generalized logging or authentication systems are general enough so they get rewritten. On the other hand you mention "small plug-ins" to handle these common tasks. Are you thinking of a convention-based approach to incorporating these plug-ins (like my example of setBeanFactory)?

Getting back to Nathan's comment about some people thinking FW/1 is not suitable for large projects, I think what people want to see is FW/1 have an ecosystem of these lightweight plug-ins that they can choose from a la carte so they can charge ahead with the business specific part of their app and not spend as much time on plumbing. Not that they won't need to customize the plumbing but at least they aren't starting from scratch.

db

larryclyons

unread,
Dec 17, 2010, 3:58:36 PM12/17/10
to framework-one
Don't we know it Mike, considering our recent mutual experience with
our former employer. ;)

larry

Kerr

unread,
Dec 17, 2010, 4:30:45 PM12/17/10
to framework-one
Thanks to all for your prompt and candid replies. This is very good
discussion here. Like "Smith, Douglas" (sorry, had to ;) ), my
corporate e-mail sig is saddled with an inordinate amount of
legalese. Our environment is very similar to Douglas' in that we have
the hub/spoke model with myriad applications performing about every
business purpose imaginable. About five years ago, I wrote a custom
"framework" to support half a dozen developers. That has since grown
to 15 on my team alone, and an additional 60 or so outside my direct
organization. At the time, I could not convince the powers that be to
go down the then relatively nascent CFC path.

I was painted into a corner in that I wanted to take advantage of
things like Application.cfc OnXStart/OnXEnd methods, yet I still had
to construct a system that was used by developers in a completely
procedural manner. All told, it has served us relatively well,
although it is lacking in the flexibility we need today. I'll
acknowledge that this is in part due to my inexperience with OO and
being new to CFCs at the time. I've learned a lot in the ensuing
years, and have in personal projects used various MVC frameworks like
Yii, Django, CakePHP and RoR. There are things I like and also wish
were different with them all, though some frameworks definitely seem
to be less "in my way" than others.

Also like Douglas, my organizations applications are critical to our
day to day business operations. We frankly cannot afford to be in the
business of identifying and reporting bugs, and any decision made now
will have profound effects five years down the road. That said, I
have kept a relatively keen eye on Coldbox because it offers many
features we find desirable. Having read this group practically from
day one, I would see Sean sometimes mention his work on a large CB app
and the associated frustrations. I gathered that FW/1 was partially a
reaction to his experience with CB, but I could be wrong on that point
and don't wish to put words in his mouth. Sean, I'm glad you've
offered some specific insight about the source of your troubles.
Understanding the decision was made before you joined the team,
developing a large scale application on an alpha/beta foundation is
bound to be its own source of trouble. I'm most interested in
stability coupled with functionality like IOC, logging, and integrated
test harness to name a few.

The discussion about how to add additional and commonly used
functionality to FW/1 is interesting. Strategic direction on this
front will play out as very important for FW/1 a few years down the
road. I also would like to see "official" plugins that provide some
of the functionality we've been talking about.

Back to the general point, which is that of selecting a framework that
best fits one's needs. I've not seen any real thorough , deep dive
comparisons of the various frameworks out there as of late. If there
are resources such as this available, please point me in the right
direction. I have done *a lot* of reading in the past year or so.
I've played with FW/1, CFWheels and Coldbox, but not to the depth
required to come to a decision. At this point I need to really dig
into the guts of each, and ponder the consequences and possibilities.
Thanks again for the good discussion.

@Mike - I would be quite alarmed if you didn't love CFWheels. ;)

OT - Has anyone seen / going to see TRON: Legacy? I'm going with a
bunch of friends tonight to see it in 3D. I've heard a wide variance
of opinion, though as always I'm going in with an open mind.

Have a great weekend,
Kerr

David Burns

unread,
Dec 17, 2010, 4:42:58 PM12/17/10
to framew...@googlegroups.com
Kerr -

If you haven't already, I recommend checking out the section on frameworks in the Adobe ColdFusion Anthology book. It describes most of the well known CF frameworks one after the other. It gives "light" recommendations on which to use in different circumstances but there are no strong opinions/guidelines/rules nor can there be since every situation varies. It is also a great book all around - recommended.

db

Nathan Strutz

unread,
Dec 17, 2010, 5:19:55 PM12/17/10
to framew...@googlegroups.com
So let's make a list of these things we can add onto the framework in a fw/1 type of way.

Kerr started it, he says IOC, Logging and an integrated test harness. 

By IOC I take it we mean IoC/DI bean factory type of toy which Sean calls DI/1 and I'm sure is coming "soon."
Logging - I've never understood what was wrong with cflog, but I haven't seen what Louis' does.
A testing harness, I guess I'd have to see it. Are we talking a mocking/testing framework? I personally would hate to reinvent this one. Maybe some kind of plugin for MXUnit instead?
Sean mentioned security. I can imagine something pretty cool that would map roles to controllers & controller.methods, but security tends to be such a creative space, I wonder what other people would come up with.

So far this looks like we want ColdBox. Yeah, I said that. So how about some real creativity? What tasks do we commonly do?

We do some database table management, so maybe a scaffolder would be nice.
We write unit tests. What if we could generate them?
We try to understand applications - can't my FW/1 app SHOW me the structure of my app?
We try to remember paths to static content (images, css), maybe something that automates and integrates that.
We try to come up with perfect architecture, maybe a var scoper type style check for FW/1 conventions.
We move our old legacy apps into FW/1 because it's better. How about a converter?

And that list doesn't even cover any real applications.

Kerr

unread,
Dec 17, 2010, 5:21:44 PM12/17/10
to framework-one
@David - Thanks very much for the recommendation, I didn't know about
this book. Based on the Amazon reviews it seems somewhat akin to SQL
Server MVP Deep Dives, which has been an indispensable resource for me
on the database side.

Matthew Currier

unread,
Dec 17, 2010, 5:58:08 PM12/17/10
to framew...@googlegroups.com
Hello,

    I have to say that one of the reasons I use FW/1 is because it doesn't do a lot of the extra things mentioned above.  In the interest of splitting hairs just because I can: it's not so much "lightweight" as "elegant"; leveraging ColdFusion instead of trying to make it act like Java or something else.  Also, it facilitates MVC and nothing else: the else is what I do.

    As far as plugins: the notion of FW/1 sub-systems almost directly parallels Django (python framework) "apps".  They maintain a wiki page the simply lists available "apps".  The primary issue that comes to mind with plugins that handle things like authentication or logging is storage: there is nothing like a standard storage mechanism between RDBMS, ORM, and Schemaless DBMSs.  One of the things that makes Django "apps" so useful is that most developers use/extend the built-in ORM.  How would a FW/1 plugin developer approach that?
    Does the plugin developer have to write an adapter for each target system? or, only target certain types of systems?  Some of the things you mentioned could be rolled into a ColdFusion Builder extension...but then what percentage of CFers have you then excluded...


Matt

Dave Anderson

unread,
Dec 17, 2010, 10:23:10 PM12/17/10
to framework-one
LOL!
That's a marketing dept coup, you can just tell. "Isn't this great?
Every email sent by every employee now tells the world how freakin'
awesome and professional we are!" Wankers.

Sean Corfield

unread,
Dec 17, 2010, 11:19:58 PM12/17/10
to framew...@googlegroups.com
On Fri, Dec 17, 2010 at 11:14 AM, David Burns <davebur...@gmail.com> wrote:
> I'm trying reconcile two points you just made though. On the one hand you
> don't think generalized logging or authentication systems are general enough
> so they get rewritten. On the other hand you mention "small plug-ins" to
> handle these common tasks. Are you thinking of a convention-based approach
> to incorporating these plug-ins (like my example of setBeanFactory)?

LOL! Yeah, my point is that I think we will see *multiple* logging
plugins that work different ways and *multiple* authentication plugins
and so on. Some people will like one, some will like another, others
will write their own.

The root question tho' is: what would a FW/1 plugin look like?

Right now, I don't know for sure. It's something I'm hoping to address
in FW/1 2.0 but I don't yet have a clear picture in my mind of how it
might look...

Sean Corfield

unread,
Dec 17, 2010, 11:24:37 PM12/17/10
to framew...@googlegroups.com
On Fri, Dec 17, 2010 at 1:30 PM, Kerr <hay...@gmail.com> wrote:
> and the associated frustrations.  I gathered that FW/1 was partially a
> reaction to his experience with CB, but I could be wrong on that point
> and don't wish to put words in his mouth.  Sean, I'm glad you've
> offered some specific insight about the source of your troubles.

Well, to be entirely truthful, I started FW/1 *before* I joined the
project that is using ColdBox and I didn't start to encounter the
problems for several months, as we really began to push the framework.
That just added to me feelings about frameworks having gotten too big,
bloated and complex - which was why I'd started FW/1 in the first
place :)

Sean Corfield

unread,
Dec 17, 2010, 11:32:03 PM12/17/10
to framew...@googlegroups.com
On Fri, Dec 17, 2010 at 2:19 PM, Nathan Strutz <str...@gmail.com> wrote:
> By IOC I take it we mean IoC/DI bean factory type of toy which Sean calls
> DI/1 and I'm sure is coming "soon."

Right.

> Logging - I've never understood what was wrong with cflog, but I haven't
> seen what Louis' does.

Logging to DB, multiple levels (debug, info, warning, error) having
different logging behaviors etc etc.

> A testing harness, I guess I'd have to see it. Are we talking a
> mocking/testing framework? I personally would hate to reinvent this one.
> Maybe some kind of plugin for MXUnit instead?

I'd prefer something that worked with MXUnit since that's the de facto
CFML standard these days.

> Sean mentioned security. I can imagine something pretty cool that would map
> roles to controllers & controller.methods, but security tends to be such a
> creative space, I wonder what other people would come up with.

Yeah, I generally have users & groups & roles / permissions at the
core of whatever I build but every app uses it differently.

> We do some database table management, so maybe a scaffolder would be nice.

Built-in ORM and Terry Ryan's Apptacular would be my vote. (I'm not a
fan of scaffolding)

> We write unit tests. What if we could generate them?

Sounds like an IDE plugin to me...?

> We try to understand applications - can't my FW/1 app SHOW me the structure
> of my app?

Easy enough to write an app that generates documentation based on the
controller / view folder structure I think.

> We try to remember paths to static content (images, css), maybe something
> that automates and integrates that.

I see this sort of request a lot with all frameworks but I just don't
get it: why is this at all complicated? I see Mach-II adding HTML
helpers etc for this but I just don't understand the problem...

> We try to come up with perfect architecture, maybe a var scoper type style
> check for FW/1 conventions.

Interesting.

> We move our old legacy apps into FW/1 because it's better. How about a
> converter?

Legacy apps are very varied. I don't think it can be automated. I do
plan eventually to have some migration guides on the wiki (and would
welcome contributions).

> And that list doesn't even cover any real applications.

Amen!

Dave Burns

unread,
Dec 17, 2010, 11:36:58 PM12/17/10
to framew...@googlegroups.com
Re what's wrong with cflog, my main complaint is that it won't take complex types out of the box like cfdump does and to me it should because they are conceptually analagous - just different output destinations. But I have a wrapper that deals with that so I've moved on.

Dave Burns

unread,
Dec 18, 2010, 12:08:15 AM12/18/10
to framew...@googlegroups.com
>> We try to remember paths to static content (images, css), maybe something that automates and integrates that.

> I see this sort of request a lot with all frameworks but I just don't get it: why is this at all complicated? I see Mach-II adding HTML helpers etc for this but I just don't understand the problem...

Whether or not it's hard, I think the FW/1 philosophy kicks in here. My take is that something shouldn't go into the core framework unless that's the only way to make it work well. If people want something built-in simply because it's convenient or because they want someone else to show them what best practices are, that's probably not reason enough. It's a great case though for an external, decoupled class that the community recommends using as a de facto standard.



Dave Burns

unread,
Dec 18, 2010, 12:33:32 AM12/18/10
to framew...@googlegroups.com
I'd say that the even rootier ( :-) ) question is, what are the cases that justify a plug-in at all? Thinking about what I wrote above about how something should go into the framework only if that's the only way to make it work well, I wonder about my logging and security topics.

For logging, is it useful to have the internal behavior/decisions of the framework logged? If not, it seems like the code the framework invokes is on its own. There's still a need for a nice logging system but it's not necessarily the responsibility of the framework. If someone still wants to log FW/1's behavior and doesn't want to instrument all calls to before() and after(), the framework could still only offer to call one simple (i.e. take a string and nothing else) API and leave it up to the app writer to wire that up to an external logging library which logs it to whatever log destinations and levels. In this case, what you might want is an example or two from FW/1 of what libraries have been shown to work well with some sample code to show how to wire them in.

For security, I think whether the framework takes part in it depends on the granularity desired and what viable options are out there for something that can easily be wired in. If AJAX security, sub-system security, section security, etc. is all handled easily by using existing hooks in the framework, maybe I stand corrected and the framework itself doesn't need it.

Assuming that's the case, what that means is that if someone walks up to FW/1 "cold" and has a checklist of things they need for a new app, if the framework core doesn't have it, the best thing would be to have doc to know what other OSS things out there people have integrated well and what things need to be provided. Otherwise, people who don't "get" FW/1's reason for being will think the framework comes up short compared to other more "complete" frameworks.

Curt Gratz

unread,
Dec 17, 2010, 6:04:10 PM12/17/10
to framework-one
I would have to disagree with Sean on some of his comments about
ColdBox.

* Performance analysis shows early all the application's time is spent
in Reactor and ColdBox.

I have used ColdBox on several large scale project (1 million plus
requests per day) and found that it does very well handling load and
scaling without an issue.

* Dependency Injection is lazy and doesn't mix well with ColdSpring

I have used both interchangeably on projects without an issue. I
probably wouldn't recommend it as more frameworks introduced doesn't
make sense if they do the same thing, but it can certainly be done.
And yes, ColdBox/WireBox DI can be lazy, but it can also be cached
reducing any performance hit after its first used.

* We ran into countless bugs in various areas that clearly other
people don't use (including LogBox, the MXUnit test harness, i18n...)

Ah pre-releases.

* Multi-domain caching

This can now be done now with CacheBox, you can also setup distributed
cache using ehCache as a provider. Pretty sweet stuff.

Just my two cents.

Thanks,
Curt Gratz

Luis Majano

unread,
Dec 17, 2010, 5:18:22 PM12/17/10
to framework-one
Hi everybody I dont usually answer to things like this but i am making
an exception today:

Here are some facts for you:
ColdBox was developed on the fact of performance when I worked for
Sandals and Beaches resorts. It sustained over 1.5 million requests
per server per day on a cluster of 20 servers. So saying that
ColdBox's performance is lacking or not achieveing the 80%, then I beg
to differ. It has been a solid core powering mission critical
applications for over 5 years now. 5 years of investment in
performance, tuning and what works when you need stability,
extensibility and performance. This is not a brand new concept or an
itch I scratched. It was built for performance and fill the gap.
Unfortuantely, in your job you mention, you where using a very early
build of 3.0 where things where in flux and in development, with that
comes issues like any other project, buggy builds and concepts that
are still forming. So misleading your group by saying its buggy and
not extensible, is saying that something that is not fully cooked
tasted like crap.

* Multi-domain caching (ColdBox isn't designed for multi-domain sites
according to Luis)
It is since M4 as it was a ticket since the beginning of 3.0 and you
knew that, so again, why misrepresent, Also, tell me what caching
libraries exist in ColdFusion that can accomplish as much as CacheBox
does within ColdBox? Event caching, partial caching, purging
mechanisms, etc?

* Multi-domain SES URLs (see above)
Also since M4 as it was a ticket since the beginning of 3.0, I even
gave you a solution for it. What other library offers the ability to
do URL mappings in ColdFusion like ColdBox does, with REST enabled
services, extension detection and more? Again, why misrepresent it.

* Dependency Injection is lazy and doesn't mix well with ColdSpring
(Luis said either use ColdSpring for everything or use ColdBox
injection for everything - don't mix them) ***

I said don't mix them because of consistency like in any other
project, this was more a lack of architecture in the project that a
problem with the libraries. Large enterprise applications use ColdBox
DI (wirebox) and have no issues as much as you guys did due to lack of
knowledge in it. At ESRI, which is no small shop, we discarded
ColdSpring due to its performance, and have been using WireBox for
over 2 years now with incredible success.

* We ran into countless bugs in various areas that clearly other
people don't use (including LogBox, the MXUnit test harness, i18n...)
That's what happens when you are in early alphas of new 3.0 and those
are features that are widely used since those inception days. So
saying that early versions of LogBox of enhaned i18n are buggy seems
to me to misrepresent things. Also, what other libraries offer as
much testing facilities as ColdBox for itnegration testing, model
testing, mocking, etc? Again, its ok to comment on finished products,
but don't misrepresent unfinished products.

* Performance analysis shows early all the application's time is spent
in Reactor and ColdBox.

I refer to point number 1 and the concept that performance is where
ColdBox shines, plus the majority of the time is not the framework
that adds performance issues, but developer code. And all the time
spent in coldbox from that analysis was getting and putting values
into the request. Plus Reactor is a hog. I can refer to you over 20
different clients with over 100 times the traffic your project had,
with extreme success and even third party evaluations of the core.
IBM consultants even did a report on ColdBox and was amazed at its
stability and extensibility and this was in version pre 1.0

>LogBox is a great example of this. It's very sophisticated but there are a lot of common use cases it doesn't support well

You where testing a very early version of LogBox and you also helped
in the realization of much of its features. There are no libraries in
the cf space that can provide as much as LogBox and if improvements
can be made, they can be made, but discarding it like you say, really
seems to me that you dislike anything ColdBox as it does not fit your
palatte, more than what the software provides or can provide in the
future.

>ColdBox is an amazing achievement and for a large number of web apps
it's "good enough" for the 80%. Once you start to need to customize
the features, you start down a path where it's often more work to do
the customization than to write your own from scratch (especially if
you find yourself fighting against the framework due to design issues
or bugs).

I think that if this where true, then I would not be in business
Sean. Flexibility in the core is what makes it shine and flexibility
is where most consulting is done at Ortus Solutions. Benefits of
extensibility and customizations is what drives business, so I guess
if this were not true, then I would not be doing well.

Sometimes I feel like you really dislike ColdBox, and its ok, I am not
in a popularity contest but in the business of driving innovation and
creativity for ColdFusion. I never speak badly or comment like you
have about any other frameworks, projects or memebers . I respect
their teams and all the personal time involved in them. To me all
frameworks are achievements in the CF community that deserve respect
and encouragement, like machII, fusebox, wheels, model glue,
coldspring, etc. I think that innovation is driven by healthy respect
between peers and solid but tasteful criticism. So I finally break my
silence of responding on threads because I think its time to
concentrate on being productive rather than speaking illfully about
other projects. I respect you as a developer and a friend, but I
think that your misrepresentations are not cool. I can totally
understand not being able to work in the framework of your choice, I
would feel the same if I did a project in FW1, I would not like it
even thought its FW1 concepts come from ColdBox!, because I am the
author of ColdBox. That doesn't mean that FW1 is not good or lacks,
it is because of your personal attachment to it. I think your
framework is great and I commend you for your time invested in it,
your dedication to it and your wanting of popularize it.

Thank you for your time.

Luis

Scott Stroz

unread,
Dec 17, 2010, 9:46:00 AM12/17/10
to framew...@googlegroups.com
On Wed, Dec 15, 2010 at 3:28 PM, John Allen <johnf...@gmail.com> wrote:

> Is there ANYONE on this list that can think of ANY reason to do new

> development in anything other than FW/1? MG, Mii, Wheels offer some neat
> features, but enough to use them?

I can think of a really good one. Familiarity with the given
framework. If a developer is more familiar with MG or Mii, they will
likely be more productive than if they choose to use a framework in
which they are not as familiar. Depending on the project, that could
influence the 'bottom line' quite a bit.

--
Scott Stroz
---------------
You can make things happen, you can watch things happen or you can
wonder what the f*&k happened. - Cpt. Phil Harris

http://xkcd.com/386/

Sean Corfield

unread,
Dec 18, 2010, 2:20:36 AM12/18/10
to framew...@googlegroups.com
On Fri, Dec 17, 2010 at 3:04 PM, Curt Gratz <gra...@compknowhow.com> wrote:
> * Performance analysis shows early all the application's time is spent
> in Reactor and ColdBox.
>
> I have used ColdBox on several large scale project (1 million plus
> requests per day) and found that it does very well handling load and
> scaling without an issue.

I'm not saying it doesn't scale nor that it can't handle a lot of
traffic. The 3rd party analysis on our app showed most time spent is
in Reactor and ColdBox. I didn't even say that it caused a performance
problem. I just that in an average request, more time was spent in the
frameworks than in our own code.

> * Dependency Injection is lazy and doesn't mix well with ColdSpring
>
> I have used both interchangeably on projects without an issue.

Luis himself advised us to either use ColdBox's DI or use ColdSpring's
DI but not to mix them. We're an edge case: we're using Reactor and
relying on the bean injector, which in turn relies on ColdSpring, and
because of the DI strategy in ColdBox, the two systems do not mix
well. That's an unfortunate fact for us. If we weren't using Reactor
(or Transfer - since that also uses a similar bean injector I suspect
we'd hit the same problem), we could mix ColdBox and ColdSpring just
fine I expect. However, we don't like the way ColdBox DI leaks into
the model with ColdBox-specific annotations - that's an architectural
decision on our part.

> And yes, ColdBox/WireBox DI can be lazy, but it can also be cached
> reducing any performance hit after its first used.

Those are orthogonal - and not actually relevant to my point.

> * We ran into countless bugs in various areas that clearly other
> people don't use (including LogBox, the MXUnit test harness, i18n...)
>
> Ah pre-releases.

Indeed. And we won't with Luis on the bugs and submitted patches back.
ColdBox 2.x didn't support multi-domain applications and so we had to
deal with the usual pre-release issues on the 3.0 series of builds -
and since 3.0 isn't gold yet, the whole thing is pre-release. It's a
trade off. We worked thru pre-release builds of Scala 2.8 and we're
now working thru pre-release builds of Clojure 1.3 (Scala is now on
2.8.1 gold).

> * Multi-domain caching
>
> This can now be done now with CacheBox, you can also setup distributed
> cache using ehCache as a provider.  Pretty sweet stuff.

Features were added to support multi-domain caching as part of the
work we were doing with Luis.

Also, on a number of these points, we wanted our model to be
completely independent of our MVC framework. That means not getting
wired into a number of ColdBox features. We chose to use ColdBox's
environment management (although we wrote our own hostname control
CFC, per Luis's recommendation) but we've not reached a point where we
have some very low level components in our model having to depend on
the ColdBoxFactory. Architecturally, that's a very poor fit for what
we're trying to do. We're in the process of moving all the environment
control stuff over to Clojure so it's possible to reuse in Scala,
Clojure and CFML, independent of the MVC framework we're using.

Sean Corfield

unread,
Dec 18, 2010, 2:26:02 AM12/18/10
to framew...@googlegroups.com
On Fri, Dec 17, 2010 at 6:46 AM, Scott Stroz <boy...@gmail.com> wrote:
> I can think of a really good one. Familiarity with the given
> framework.  If a developer is more familiar with MG or Mii, they will
> likely be more productive than if they choose to use a framework in
> which they are not as familiar. Depending on the project, that could
> influence the 'bottom line' quite a bit.

Excellent answer!

A team very familiar with Model-Glue, or Mach-II (or ColdBox) is
almost certainly going to be better off sticking with the framework
they know.

The adobe.com team still use Mach-II as far as I know because that's
what they're familiar with. The ERP team had a Model-Glue application
that I built for them - new development on a new team so switching
frameworks was reasonable - but that app, like all the other ERP work
I was involved with there, got replaced by Adobe after the acquisition
(because they had a corporate ERP solution in place).

Changing frameworks is a big deal. For all that I grumble about
ColdBox on my current project, our goal of replacing it with FW/1 is
very long-term (and somewhat low priority).

Sean Corfield

unread,
Dec 18, 2010, 2:52:58 AM12/18/10
to framew...@googlegroups.com
On Fri, Dec 17, 2010 at 2:18 PM, Luis Majano <lma...@gmail.com> wrote:
> ColdBox was developed on the fact of performance when I worked for
> Sandals and Beaches resorts. It sustained over 1.5 million requests
> per server per day on a cluster of 20 servers.  So saying that
> ColdBox's performance is lacking or not achieveing the 80%, then I beg
> to differ.

As I said in response to Curt, I didn't say that ColdBox didn't
perform well - just that on any given request, most of the time was
spent in the frameworks. Given that the codebase of the frameworks
outweighs our own codebase by a factor of 2x or 3x, that shouldn't be
surprising but it speaks to my concerns about the inherent simplicity
of ColdFusion and how complex most frameworks have become over recent
years.

> * Multi-domain caching (ColdBox isn't designed for multi-domain sites
> according to Luis)
> It is since M4 as it was a ticket since the beginning of 3.0 and you
> knew that, so again, why misrepresent,

You yourself said ColdBox wasn't originally designed for multi-domain
applications. I can probably pull up the conversations we had about
that. I know you said it was a goal for 3.0 and I know that the bugs
and patches we submitted helped achieve that. As you know, we
stabilized on M3 after a bit of a bumpy ride thru the pre-release
builds (and that's no criticism: working on pre-release builds is
always a trade off). As I recall, there were some breaking changes in
M4, compared to M3, for our use cases (again, I'm pretty sure I can
pull up the conversations we had about this), which meant that we
couldn't upgrade at the time because we expected to be going to
production 'soon'. As it happens, we've made a lot of changes since
before going to production and, with hindsight (wonderful stuff), we'd
have had time to move to M4 and deal with the issues.

We ran into some order of initialization problems in plugin loading
and in order to fix those, we've had to make some changes that would
make upgrading beyond M3 harder than necessary.

> Again, its ok to comment on finished products,
> but don't misrepresent unfinished products.

I can only comment on the versions we were using, sorry. There were a
lot of things that we ran into that other people were not using - I
think at one point you even said that ColdBox wasn't designed to do
several of the things we were trying to do - and you were very
responsive to our issues and offered a number of workarounds and we
offered a number of patches for the problems we hit, where a generic
solution was possible for the framework for other users. Folks can go
search the ColdBox mailing list archives for the threads I started
covering those issues.

> I refer to point number 1 and the concept that performance is where
> ColdBox shines, plus the majority of the time is not the framework
> that adds performance issues, but developer code.

The majority of time _in our application_ is spent in the frameworks.
As I noted above, that doesn't mean there's a problem with
performance, just that there's more framework code being executed than
developer code.

> Plus Reactor is a hog.

Oh it's horrible, yes! It wouldn't have been my choice at all. But
it's intrusive and getting the app off Reactor will be a lot of work.

> You where testing a very early version of LogBox and you also helped
> in the realization of much of its features.

Yes, as noted above, I can only comment on the software as it was at
the time. But I still stand by my general position that the more
comprehensive and flexible any given solution is, the more complexity
is introduced and the steeper the learning curve, configuration and
code extension becomes. It runs counter to the simplicity of
ColdFusion itself, IMO.

> I respect you as a developer and a friend, but I
> think that your misrepresentations are not cool.

I don't think I've misrepresented anything. I've shared my experience.
I know a lot of people love ColdBox and are very successful with it -
I think you've done an amazing job creating _and documenting_ it. But
philosophically we have very different views of what a framework
should do and be. And that's as it should be - otherwise we'd all be
programming the same way and it would be a very boring world :)

> I can totally
> understand not being able to work in the framework of your choice,

FW/1 didn't exist when I started this project :)

Dutch Rapley

unread,
Dec 18, 2010, 11:51:35 AM12/18/10
to framew...@googlegroups.com
For logging, is it useful to have the internal behavior/decisions of the framework logged? If not, it seems like the code the framework invokes is on its own. There's still a need for a nice logging system but it's not necessarily the responsibility of the framework. If someone still wants to log FW/1's behavior and doesn't want to instrument all calls to before() and after(), the framework could still only offer to call one simple (i.e. take a string and nothing else) API and leave it up to the app writer to wire that up to an external logging library which logs it to whatever log destinations and levels. In this case, what you might want is an example or two from FW/1 of what libraries have been shown to work well with some sample code to show how to wire them in.

My thoughts, exactly. I only use controllers to set up services and handle flow of the application. An errors that happen there, you can use FW/1's build in error handling. Now, I realize not everyone is using an IoC/DI framework. I do use ColdSpring. For no particular reason other than it's easy to setup and use and is pretty much the de factor standard for CF applications. All my services are controlled by a ColdSpring bean factory. I bring up ColdSpring because it supports Aspect Oriented Programming (AOP). With AOP, you can easily add logging and error handling to your services. If you're using ColdSpring, it's worth taking a look into how AOP works and how you can benefit from it to implement simple solutions to potentially complex problems.

 
-Dutch
Message has been deleted

Sami Hoda

unread,
Dec 18, 2010, 2:59:47 AM12/18/10
to framework-one
Sean,

Like Luis, I have yet in all my years to get involved in a
conversation like this.

In reading your post however, the only thought that ran through my
head was: Is this really Sean?

You always stand up for frameworks in general, and always put people
in their place who make strange or unqualified comments about
frameworks. I'm not saying your comments are unqualified, but in the
past, whenever you've had criticism, I've seen you be the first to
offer up fixes and get involved in the projects themselves.

Your comments really caught me as uncharacteristic. Perhaps something
has changed?

I've been following Luis' work since he made it public. I've seen him
add amazing stuff, and my discussions with him have proven him to be
very humble and insightful.

Could ColdBox still use some work? Sure. Does it have bugs? Yes. I
follow his Assembla project, and see him fixing and improving stuff on
a daily basis. Luis tends to dream big, and that is why so much
changes from milestone to another.

But you know all this... and what comes from working with pre-release
software...

Sorry - just felt like some line was crossed. I pushed you to look
into ColdBox a while back via IM, and I remember telling Luis that
Sean is going to take a look, and we both were really excited for the
frameworks and the suggestions you'd offer, thats why I felt obliged
to chime in here.

Sami

denstar

unread,
Dec 18, 2010, 3:22:48 AM12/18/10
to framework-one
On Dec 15, 1:28 pm, John Allen wrote:
> Hey FW/1’s
>
> This is a theoretical question.
>
>  I do all my development in FW/1 (LOVE IT!) and I do have extensive
> experience with ModelGlue, ColdBox, and have built contact managers in
> CF-Wheels and Mach-ii.
>
> Is there ANYONE on this list that can think of ANY reason to do new
> development in anything other than FW/1? MG, Mii, Wheels offer some neat
> features, but enough to use them?
>
> I appreciate the “it depends” answer, team may want to use another
> framework… cant extend Application.cfc for some reason… bla… bla…
>
> This is very biased question admittedly, but I just find FW/1 pretty much
> perfect; the “invisible framework”.
>
> Just a question.

LOL!

If you've done extensive development in those other frameworks, you
should already have a good idea of why folks might use them.

ColdBox is rich. Wheels is fast. Model-Glue is self-documenting.
Etc..

In sum, I can think of *lots* of reasons why someone would want to use
something other than FW/1, and I'm sure you can too.

It's cool that you *really* like FW/1-- you could have probably said
"I love FW/1!" and left it at that though. =)

I agree with Mike about doing research (not so much about not rolling
your own =)), finding something that fits you and your team's style,
etc.. I'll second the "Buy the Adobe ColdFusion Anthology book"
comment (shameless plug for friends).

Theoretically, there probably shouldn't (couldn't?) be an "end all, be
all" type deal.

:Den

--
Let us hold our discussion together in our own persons, making trial
of the truth and of ourselves.
Protagoras

Aaron Greenlee

unread,
Dec 18, 2010, 2:02:50 PM12/18/10
to framew...@googlegroups.com
This thread is an example of something tragic within our community. It is unfortunate that as a CF-community we continue to further fragment. Ruby on Rails has incredible momentum because it is a feature-packed framework that most Ruby developers have united to support for their Web based projects. When everyone can get behind a framework that offers 80% of your needs, download gems or plug-ins that add the missing 10% and finally write the last 10% that is unique to your needs, something magical happens for everyone. Especially if the unique need is contributed back to the community.

We still have lots of challenges no one has solved within our community and I wish the time was invested to expand our existing solution--not duplicate. If we could have organized and invested the time it took to read/post a reply to this thread we could have solved one of those challenges! 

I propose this thread be closed as I do not see it as being productive for FW/1, other frameworks or the CF community. I respect the opinions shared--I just don't think anyone has really added any value to our community here. 

Respectfully,

Aaron Greenlee

John Allen

unread,
Dec 18, 2010, 2:29:13 PM12/18/10
to framew...@googlegroups.com
Interesting read.

>I can think of a really good one. Familiarity with the given
>framework.

That's a really good point.

About features for FW/1, I would never want to couple my logging, authentication, or much of anything with my MVC framework, it just feels bad.

>I have to say that one of the reasons I use FW/1 is because it doesn't do a lot of 
>the extra things mentioned above.  In the interest of splitting hairs just because 
>I can: it's not so much "lightweight" as "elegant"; leveraging ColdFusion instead
>of trying to make it act like Java or something else.  Also, it facilitates MVC and 
>nothing else: the else is what I do.

This is a very well written explanation, and answers the original question posted. 

I freak-out-love FW/1 because it dose what is dose and nothing else. Seriously, how much bigger should a MVC API be than view(), redirect(), getConfig(). My logging, authentication and other stuff are domain objects/services, and portable between the various frameworks. A populate() method is handy, but I never use them in any MVC framework because my business objects are responsible for that themselves, they have the populate() logic.  

<cfajaxproxy> handles all asynchronous requests, not my MVC framework.

>The root question tho' is: what would a FW/1 plugin look like?

>Right now, I don't know for sure. It's something I'm hoping to 
>address in FW/1 2.0 but I don't yet have a clear picture in my 
>mind of how it might look...

Plug-ins are the bees-knees when implemented well. 

I really like the idea. Currently I just use a frameworkwrapper.cfc which extends framework.cfc to address specific use cases.

If FW/1 had some 'hook' for unit testing controllers, that might be a time saver, but mocking the RC isn't a super big deal.

Real good read.

Curt Gratz

unread,
Dec 18, 2010, 2:50:26 PM12/18/10
to framework-one
@Aaron Greenlee,

Very well stated. Thats one of the things that first drew me to
ColdFusion and the CF community. Everyone was also so encouraging of
eachother and there projects and other projects that did similar
things. They all wanted to see the language expand and push the
boundaries and be creative. Not that the community isn't still that
way to a point, but I don't want to see us get fragmented.

@Scott Stroz

Excellent point. Not only does experience help but choosing a
framework, but it is also very personal. What do you like/not like.
What is your and your teams style. What features are you looking
for. Try them all and see what you fall in love with and use that.
Then try them again and see if it what you like has changed. To me
its much like if your a Christian and your choosing where to go to
church. As long as its a bible believing church with sound doctrine,
the rest is preferences. Or thats my opinion.

@Sean,

Thanks for your response. I also was just sharing my experience with
ColdBox which seem to have been more positive then yours.

Curt

Sean Corfield

unread,
Dec 18, 2010, 4:07:27 PM12/18/10
to framew...@googlegroups.com
On Sat, Dec 18, 2010 at 11:02 AM, Aaron Greenlee
<aarong...@gmail.com> wrote:
> This thread is an example of something tragic within our community. It is
> unfortunate that as a CF-community we continue to further fragment.

Part of the problem is that we, as a community, have somewhat of a
'victim mentality' and that means we can't easily hear criticism
without jumping vehemently to the defense of whatever we find
precious. When the macromedia.com team adopted Mach-II, some members
of the community were outraged, seeing it either as a slight to
Fusebox (the only other framework at the time) or 'no-framework'
(seeing it as a commandment from the mothership that 'thou shalt use a
framework'). The reality of course was far less conspiratorial: I had
a team of Java / C++ developers who were suddenly presented with CFML
and a mandate to learn and use it. They naturally wanted a framework
and they wanted something that leant toward what they were familiar
with: OO.

For a while I was lead developer on Mach-II. Then I took on a new
project and Mach-II's architecture didn't fit it well enough for my
taste - but Model-Glue did. Some people were outraged at my
'abandoning' Mach-II. I contributed a bunch of stuff to Model-Glue
around the Transfer ORM adapter. I contributed a bunch of stuff to
ColdSpring. After Adobe bought Macromedia, my new team used Model-Glue
and Reactor (and ColdSpring) but found Reactor didn't meet our
performance needs (CFC creation was relatively expensive back then and
Reactor did a *lot* of that) so we switched to Transfer and worked
extensively with Mark Mandel to track a memory leak we were
experiencing. During that time, I took over the Fusebox project and
spent two years working on that. Since I wasn't getting projects that
used Fusebox, I offered up project lead to someone more invested in
Fusebox (although during that time I built a jumpstart Mach-II
application for a client and then they asked me to rebuild it in
Fusebox 'no-XML' - the only client that ever asked me to use Fusebox).

Last year I finally got to work with ColdBox commercially. So far no
client has given me an opportunity to work commercially with cfWheels.

I consider myself to be pretty inclusive and I find it very strange to
see developers align themselves so strongly with one framework - or
one technology. But it's that strong alignment that leads to religious
wars when they feel their framework / technology has been slighted.

We're all CFML developers. We're all 'on the same side'. These
ultra-defensive responses to any perceived criticism does no one any
good. Mostly it just further entrenches people in 'opposing' camps and
creates divisions within the community.

I use whatever tool - framework, technology - suits the job in hand
(or whatever the client has specified). Part of why I took on this
current project was because it offered me an opportunity to learn and
use ColdBox!

But apparently, turning round and saying "I don't framework X" is a crime :)

I can find lots to like - and dislike - in every framework. The same
as I can find lots to like - and dislike - in every language /
technology.

I don't like Ruby but lots of people do. I like Clojure but lots of
people don't. Some people are adamant that Scala is 'too complex' for
the average programmer. Lots of people 'out there' think CFML is a toy
language. I happen to like it a lot for the View-Controller portion of
an application - I don't think any other technology can touch it in
that area.

The CF community really needs to get along. If you see something that
offends you, count to ten, take a chill pill and put yourself
objectively in the shoes of the person who wrote it. How they feel is
real. You can't reason away feelings and you shouldn't try to
invalidate them with logic. Their experience is different to yours.
It's what makes the world such a wonderfully diverse place.

Unless you don't like diversity, of course...

Finally, both Luis and Curt publicly said they were moderated on this
list (on Luis's blog) - because their posts in defense of ColdBox
didn't appear immediately. Sean must be suppressing opposing views!
Conspiracy! This just reinforces the 'victim mentality' I mentioned at
the start of this post. The reality? This list is open for anyone to
join (and read) but all posters have their first post moderated to
keep spammers at bay. This was the first time Luis or Curt had posted.
Their first posts were held by Google groups for a short while until I
checked Gmai, when I immediately set their status to "Always Allow".
And, yes, I get a steady stream of spammers trying to join and post to
this list so the moderation policy is worthwhile (and it's common on
Google Groups).

Sean Corfield

unread,
Dec 18, 2010, 4:12:41 PM12/18/10
to framew...@googlegroups.com
On Sat, Dec 18, 2010 at 11:50 AM, Curt Gratz <gra...@compknowhow.com> wrote:
> Thanks for your response.  I also was just sharing my experience with
> ColdBox which seem to have been more positive then yours.

Yup, and ColdBox has a large (and loyal) developer community who all
(mostly) have positive experiences with the framework. I'm definitely
in the minority and discussions with Luis made it clear that our
application was an unusual edge case that wasn't covered by ColdBox's
original design goals so it's no surprise we ran into issues. I
strongly suspect we'd have run into issues with most of the richer MVC
frameworks because they all try to cater for the 80-90% of mainstream
requirements and we're in that 10-20% which is just our bad luck. A
smaller, simpler framework would probably have suited us better
because we wouldn't have been fighting against it in some areas or
having to workaround its default behaviors.

Matt Quackenbush

unread,
Dec 18, 2010, 4:25:47 PM12/18/10
to framew...@googlegroups.com
Unbelievable.

@ Those who believe that X framework is the only "right" framework - Pull your head out and look around.  You are **not** correct.

@ Scott Stroz - True that!

@ Sean - Thank you.  Given the absurdity that has been going on in the last 24-ish hours, your post is well needed and 100% accurate.  It's nice to see that _someone_ has a level head on their shoulders.

AJ Mercer

unread,
Dec 18, 2010, 6:58:32 PM12/18/10
to framew...@googlegroups.com
I love the idea of a 'kitchen sink' framework, but love the simplicity of FW/1 so am really looking forward to the FW1 2.0 discussion around plugins.

Over the silly season break I am planning on messing around with cfWheels and WordPress so will take notes on how they deal with plugins.
The one thing I was not too keen on with something I read about wordpress plugins is when one becomes really popular it is added to the core. I think that is how frameworks become bloated. 80% of the people may use them 80% of the time, but what about the time when you just need a bare bones framework?

Aaron Greenlee

unread,
Dec 18, 2010, 7:10:57 PM12/18/10
to framew...@googlegroups.com
Do you consider a framework bloated when it offers features within the core--not requiring additional installation--or--when things are actually read from disk into memory that you are not using?

-A

--



--
Aaron J. Greenlee
/*
www.aarongreenlee.com
aarong...@gmail.com
*/

AJ Mercer

unread,
Dec 18, 2010, 8:16:29 PM12/18/10
to framew...@googlegroups.com
I am using the word 'bloat' is its most generic form - stuff that is there but not used (for a particular application)

But I guess if you take that to it's logical (and perhaps silly) conclusion, controller,services,subsystems and populate() are all bloat if you are just using FW/1 to relive the Fusebox 2 'glory days'; that is just using the views.

You may argue that if there is no performance hit or memory wastage with having the extra 'stuff' then there is no harm in having it in there.


I love being able to find open source solutions that have already solved an issue I have, but I would like to be able to optionality add them as I need them. 

Baz

unread,
Dec 19, 2010, 4:40:38 AM12/19/10
to framew...@googlegroups.com
How does FW/1 solve the problems found in LogBox or i18n? By just not offering a solution?

Sean Corfield

unread,
Dec 19, 2010, 3:56:29 PM12/19/10
to framew...@googlegroups.com
On Sun, Dec 19, 2010 at 1:40 AM, Baz <b...@thinkloop.com> wrote:
> How does FW/1 solve the problems found in LogBox or i18n? By just not
> offering a solution?

It is not part of FW/1's job to solve those problems. FW/1 is focused
on being a lightweight MVC framework. Most ppl don't seem to be
building multi-lingual apps yet and those that are probably already
use Paul Hastings' excellent i18n utilities. As for logging, again,
most ppl don't seem to need anything very sophisticated there.

For comparison, look at Fusebox, Mach-II and Model-Glue - which also
don't offer solutions for these*** and many other problems - because
they are focused on doing a specific job and doing it well. When I
designed Fusebox 5.5's no-XML mode, what I'd really wanted to create
was something like FW/1 but I had to drag along all the Fusebox 4 /
Fusebox 5 backward compatibility stuff. That said, I probably couldn't
have created FW/1 in its current form without those two years spent on
Fusebox :)

*** Mach-II 1.6 introduced a logging package based on tracing the
internals of the framework, to which you could add your own logging
output, similar to what I created in Fusebox but I wouldn't really
consider either to be in the same category as LogBox (although perhaps
the Mach-II logging is more sophisticated than I realize?).

At one point in the history of frameworks, the Mach-II folks called
out their purity and focus and their desire not to become a "kitchen
sink" framework (there was a lawn mower reference, as I recall). Each
framework has a vision, a goal that drives its design. That's why
folks choose different frameworks.

Almost every language has multiple frameworks. Ruby actually has
multiple frameworks but Rails is very much the 800lb gorilla in that
arena. Some frameworks are "full stack", some are small and focused.
Folks pick what suits them best.

FWIW, in the Agile world, when frameworks come up, most experienced
practitioners are either against frameworks or prefer
micro-frameworks. The general feeling in the Agile world is that full
stack frameworks work against agility (because they proscribe how you
build apps and limit your choices). That said, of course there are
agile shops using Rails... go figure!

John Allen

unread,
Dec 19, 2010, 4:33:10 PM12/19/10
to framew...@googlegroups.com
>FWIW, in the Agile world, when frameworks come up, most 
>experienced practitioners are either against frameworks 
>or prefer micro-frameworks.

I totally agree. JQuery, FW/1, Swiz, ColdSpring, Hibernate: dreams do come true.

Baz

unread,
Dec 19, 2010, 5:47:59 PM12/19/10
to framew...@googlegroups.com
I love everything about FW/1 from the philosophy to the implementation, and it is my preferred framework, but in all fairness, the comparison should be:

FW/1 + Hastingsi18n + Some Loggin Library + hundreds of other libs to match what Coldbox provides

VS.

Coldbox


Then the comparison of lines-of-code or especially where the majority of the processing lies, will be quite different. If Coldbox wrote everything for you, it seems obvious that most of the processing would be in there.


I totally agree. JQuery, FW/1, Swiz, ColdSpring, Hibernate: dreams do come true.

That's my exact favorite stack: Flex - Swiz, CF - FW/1 - Coldspring, JQuery (Hibernate is very over-rated in my opinion, but that's a different conversation)

Baz




Sean Corfield

unread,
Dec 19, 2010, 7:16:50 PM12/19/10
to framew...@googlegroups.com
On Sun, Dec 19, 2010 at 2:47 PM, Baz <b...@thinkloop.com> wrote:
> the comparison should be:
>
> FW/1 + Hastingsi18n + Some Loggin Library + hundreds of other libs to match
> what Coldbox provides
> VS.
> Coldbox
>
> Then the comparison of lines-of-code or especially where the majority of the
> processing lies, will be quite different.

Well, that's true if you're using everything in ColdBox. If you're
mostly just using ColdBox for the simple, convention-based MVC core,
you'll still have a lot more code 'present' and executed compared to a
micro-framework. That's about philosophy: full stack vs a la carte
micro-frameworks in combination.

Every time I add a feature - or even a hook - to FW/1 that causes
additional code on the main execution path, I wince a little :) That's
where the rubber of practicality meets the road of principle!

> (Hibernate is very over-rated in my opinion, but that's a different
> conversation)

LOL! When John posted that, my first reaction was: Hibernate? That's
not a micro-framework :)

Hibernate is an enterprise-ready ORM - with all the pros and cons that
go with "enterprise-ready" software.

John Allen

unread,
Dec 19, 2010, 8:07:33 PM12/19/10
to framew...@googlegroups.com
Oops. I was meaning the CFML Hibernate API, and it's super singular focus.
Hibernate is a big one.

--

denstar

unread,
Dec 19, 2010, 8:25:34 PM12/19/10
to framew...@googlegroups.com
Different frameworks have different goals. If Rails was a sucky
paradigm, I doubt it would be so popular.

FWIW, I see "agile" as being about process, more than implementation.

One could argue that CFML itself does "too much". Maybe you *like*
having to write your own error handling, etc..

Not I... but to each their own. =)

:Den

--
There are two sides to every question.
Protagoras

Dave Burns

unread,
Dec 20, 2010, 11:22:36 AM12/20/10
to framew...@googlegroups.com
Sean -

You vote for Apptacular but are not a fan of scaffolding. Curious what label you put on Apptacular?

If you're not a fan of scaffolding, I'm also looking to learn what you do to create DAO and bean code - do you hand code them? I've always found it easier to have Illudium crank them out but have heard people say the default templates there aren't great (without specifics though). I'd like to learn if there's a better way (even if subjective).

db

Peter Bell

unread,
Dec 20, 2010, 11:28:20 AM12/20/10
to framew...@googlegroups.com
Well, one way of handling DAO/bean code is metaprogramming.

All of my DAO's extend an AbstractDAO and all of my beans extend an AbstractBusinessObject. Those have the generic CRUD functionality and I use metafdata in my beans to describe properties, validation rules, and the like so that I can get rich behavior without writing (or generating) boilerplate code.

If you *do* generate code, at the very least, use an active generator so as your definitive source of metadata changes (whether that's an XML file, metadata in your beans or your db schema) you can re-generate the code without blowing away any custom code. For cfc's, simplest solution is the "generation gap" pattern where you have a UserDAO that extends GeneratedUserDAO. You passively one time gen UserDAO and can edit it. GeneratedUserDAO can be regenerated whenever the metadata is updated.

Best Wishes,
Peter


Dave Burns

unread,
Dec 20, 2010, 11:31:34 AM12/20/10
to framew...@googlegroups.com
On Sunday, December 19, 2010 3:56:29 PM UTC-5, Sean Corfield wrote:
On Sun, Dec 19, 2010 at 1:40 AM, Baz <b...@thinkloop.com> wrote:
> How does FW/1 solve the problems found in LogBox or i18n? By just not
> offering a solution?

It is not part of FW/1's job to solve those problems. FW/1 is f