Other Framework thoughts
John Allen
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
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
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
Sean Corfield
> 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
development in anything other than FW/1?"
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
nathan strutz
[http://www.dopefly.com/] [http://hi.im/nathanstrutz]
Kerr
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:
> > 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
> An Architect's View --http://corfield.org/
Sean Corfield
> 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
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
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
... 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
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
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
> 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
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
our former employer. ;)
larry
Kerr
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
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
Kerr
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
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
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
> 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
> 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
> 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
Dave Burns
> 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
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
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
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...)
* 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
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)
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)
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
injection for everything - don't mix them) ***
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...)
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.
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
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).
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
> 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
Sean Corfield
> * 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
> 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
> 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
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.
Sami Hoda
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
> 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?
>
> 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
John Allen
>framework.
Curt Gratz
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
<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
> 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
@ 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
Aaron Greenlee
--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
AJ Mercer
Baz
Sean Corfield
> 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
Baz
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.
Sean Corfield
> 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
--
denstar
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
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
Dave Burns
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.
Sean Corfield
> You vote for Apptacular but are not a fan of scaffolding. Curious what label
> you put on Apptacular?
I only meant: if you want scaffolding, check out Apptacular.
It's flexible, standalone, and as I recall can generate different
architectures (separate DAO/gateway, combined DAO/gateway, active
record, raw SQL, ORM etc).
> 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?
If I'm not using an ORM, yes, I hand code the data access layer.
> 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).
Illudium generates a DAO (and a gateway CFC I believe) for every bean
which can (and usually does) lead to an anti-pattern where for every
bean (domain object) you have a DAO and a gateway and a service object
and... You get an explosion of CFCs to maintain and you lose a lot of
the benefits of moving to objects.
First off, I combine DAO/gateway (it was always an artificial
separation and one you won't find outside the CFML world). Secondly, I
tend to have one data access object for each tightly related set of
domain objects. Third, I try to ensure my domain objects contain most
of the business logic in a system - service CFCs only need to exist
where there is a collaboration between objects that needs some
external (non-domain object) entity to orchestrate that interaction.
Finally, controllers follow the lines of the user-facing application
(sections of the application) rather than the implementation (the
domain objects) so there's typically no 1:1 mapping between
controllers : services : DAOs : beans in my applications.
That's my goal - it doesn't always turn out as cleanly as that! :)
As Peter notes, another approach is metaprogramming which I quite
like. You generally take a small hit at runtime, compared to
hand-rolled or generated code, but you encapsulate all the metadata
handling complexity in a few library components and you do away with a
lot of boilerplate code. Changes to your architecture can usually be
managed by a few small metadata changes. One downside is that you are
usually forced into a one DAO per bean (anti-)pattern because a
generic DAO can only deal with one bean/table (unless you really jump
thru some hoops and I'm not sure those trade offs are worthwhile).
With code snippets and good code assist / insight from an IDE (such as
ColdFusion Builder), hand coding can be pretty fast - and with the
auto-generated get/set methods now in Adobe ColdFusion / Railo, that's
a lot of boilerplate you don't even need to worry about (although FW/1
does not yet fully support property-based get/set methods - coming in
FW/1 2.0!). Also, onMissingMethod() can save you from a _lot_ of
boilerplate code with only minimal additional runtime overhead.
Dave Burns
Sean Corfield
> If it's not FW/1's job to solve these (I think I agree now) then now I'm
> back to wondering not what a plug-in API looks like but what a plug-in API
> is meant to solve in the first place - need to know the latter first, right?
> Is there something that that level of integration facilitates that is not
> solvable otherwise?
That's the key question: what does the framework really need to
provide in order for people to be able to write and use such plugins?
I'm happy to provide an API or a set of extension points for plugins -
if they're really necessary. I just don't know what that should look
like (yet).
For logging / debugging, if you want to be able to trace the
framework's execution, you need support inside the framework - or at
least an API that is called every time the framework calls a
controller/service method or renders a view/layout (and there's an
argument for before/after API calls on all of those). To me, that
seems like a lot of additional mainline code for the relatively small
percentage of time you actually want such logging (compared to the
vast majority of time spent in production mode). However, I can see
valid arguments for such an API and a reasonably low impact way to do
it would be to introduce wrapper methods for calling controllers /
services and rendering views / layouts which users could override to
provide logging (essentially hand-rolled AOP via the Template Method
design pattern).
The big downside to using Template Method (which several parts of the
FW/1 API already rely on) is that chaining multiple plugins together
on the same hooks (API points) is artificially harder than ideal. But
then, how many plugins would an average app use and how much overlap
would there be between the plugins. This is why plugins often follow a
registration (Observer) pattern but then you need a lot more machinery
to support them. If you go with a convention-based registration
pattern (the 'obvious' choice for FW/1), you lose control over the
order of plugins (but, perhaps, plugins should not depend on each
other - a problem I saw crop up in the Fusebox world from time to
time).
Peter Bell
> . Third, I try to ensure my domain objects contain most
> of the business logic in a system - service CFCs only need to exist
> where there is a collaboration between objects that needs some
> external (non-domain object) entity to orchestrate that interaction.
That's the classic pattern (and as an aside, there's really nice coverage of some of this in Eric Evans Domain Driven Design book). One other use case is to replicate Static methods which we don't have in CF.
In other languages I might use static methods as a factory and as an interface to a repository, so I'd have
User.find( id )
User.new() (when creation of user is non-trivial)
User.getByEmail( email )
In CF, I typically put those into a UserService singleton. It does reinforce the anti-pattern of one service class per domain object instead of one per meaningful collaboration between domain objects, but I haven't found a better place to put what is really a set of static class methods yet, so that's how I code things in CF.
(Does anyone else have a better place to put those methods?!)
Best Wishes,
Peter
Peter Bell
Peter - Are those two base class abstractions generally available or something you've crafted yourself?
Dave Burns
Sean Corfield
> So that I don't retread certain topics, is there a thread or discussion
> somewhere about what's planned for 2.0?
I don't think there's a single thread that sums it up and I haven't
(yet) created a roadmap document on the wiki. I can sum it up in a
handful of bullets tho':
* Rewrite codebase to pure cfscript - and thus require Adobe
ColdFusion 9 / Railo 3.2 / Open BlueDragon 1.5 (I don't think 1.4
supports everything I'll need)
- this is mostly for consistency and maintainability
* Clean up API per various notes in the reference manual (most things
marked deprecated will disappear - a 1.3 release will provide a
migration path to the new APIs)
- mostly this will be to remove direct access to request scope and
provide API methods to access data instead raw variable access
* Clean up extension points for consistency - this may expose some new
lifecycle hooks for plugins
* Disable implicit service execution by default (in 1.2,
suppressImplicitService defaults to false, in 2.0 it will default to
true)
- the migration path is to explicitly specify it in your
Application.cfc's variables.framework structure
- setting it false in 2.0 will preserve 1.x behavior (considered
deprecated), setting it true today will mimic future default behavior
(recommended)
> Is the time-line for DI/1 related?
Not entirely but I would like to get an early build of DI/1 1.0 out in
time for FW/1 2.0 so that the FW/1 sample apps can include an example
of DI/1 usage.
For those who've missed mention of DI/1 before, it's a bean factory
and my intent is that DI/1 is to DI / IoC as FW/1 is to MVC: a single
CFC, convention-based, lightweight and simple to use. The goal is that
you create an instance of DI/1 (ioc.cfc) and initialize it with a list
of folders and DI/1 will recursively discover all the CFCs in those
folders and manage their dependencies (specified by setters - either
explicit or via property declarations). CFCs under a 'beans' folder
will be treated as transients, otherwise CFCs will be treated as
singletons (thanx to Pat Santora for the deep discussion about
conventions that led to that realization).
John Allen
--
Dave Burns
> - this is mostly for consistency and maintainability
Sean Corfield
>> * Rewrite codebase to pure cfscript
> at a customer but they are on CF8. Does this just feel good or are there
> features this enables (other than maintainability)?
You'll be able to use the 1.x stream which will continue in
maintenance with a 1.3 release (definitely; and maybe a 1.4 release).
Support will continue there for folks on older releases of ACF / Railo
/ OpenBD at least until ACF10/X is released.
The rewrite will happen before any new functionality is added and,
from my point of view, for maintainability, is very high priority.
Also DI/1 is already pure cfscript and will require ACF9.0.1 / Railo
3.2 / OpenBD 1.4 (or 1.5). As I add new modules / plugins over time,
those will also be pure cfscript. I expect other folks will provide
plugins that run on 1.x and support earlier releases of ACF / Railo /
OpenBD...