Other Framework thoughts

253 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