New option: suppressImplicitService
Sean Corfield
If true, the implicit service call will be suppressed. Folks who are
managing their own service calls may want to set this to true to
ensure services are not called accidentally by FW/1 while they are
developing.
In FW/1 2.0, this option will default to true - the implicit call of
services/section.cfc:item() will not occur unless you explicitly set
it to false.
Those who were at the CFUnited FW/1 BoF participated in the discussion
that led up to this decision and will not be surprised to see this new
feature!
Also, populate() has had a couple of tweaks thanx to suggestions from
Henry Ho...
--
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
Nando
Thanks for the suppressImplicitService modification and message about them. Are these mods only available in the "source" download or are they included in the v1.1.1 release?
Thanks,
Nando
--
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
--
Nando M. Breiter
The CarbonZero Project
CP 234
6934 Bioggio
Switzerland
+41 91 606 6372
na...@carbonzero.ch
www.carbonzero.ch
Sean Corfield
> Thanks for the suppressImplicitService modification and message about them.
> Are these mods only available in the "source" download or are they included
> in the v1.1.1 release?
Only in the BER (source) download.
1.1.1 is exactly 1.1 with the error handling patch.
1.2 RC1 should appear soon. Just two more tickets to go before I lock it down.
Julian Halliwell
Julian.
Matt Quackenbush
Mike Rankin
with their service calls. I'm not sure I like the change of the
default in 2.0, though. Shouldn't the default reflect the most common
choice? Is there some theoretical reason I should be calling my
services directly? I can't think of any. Plus, shouldn't there be a
heavier weight given to options that don't break existing code? Not a
big deal, really, but updating the framework could cause problems for
existing apps if a lot of apps are using a single framework instance
on the server.
Matt Quackenbush
It is obviously a matter of opinion and architecture, but in my opinion, hell yes, there is a damn good reason you should be calling your services directly. While the implicit calls are nice and convenient for a small application, as your application grows - and I am assuming that everyone's goal is for their app to grow - you will undoubtedly run into more and more and more difficulties with implicit service calls. I am also of the opinion that the developer should be the one in control of the application, and not the framework. This goes a long way in shoring up that "hole" with FW/1.
Again, this is my opinion - not a fact. To that end, the only facts are:
- There are countless people whose opinion agrees with mine.
- There are countless people whose opinion does not agree with mine.
Jamie Krug
minor security concern to me. Not huge deal, but I really like this
implementation, and I think default to false for now but default to
true in FW/1 2.0 is perfect as well.
Cheers,
Jamie
On Aug 8, 7:37 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> Default: false
>
> If true, the implicit service call will be suppressed. Folks who are
> managing their own service calls may want to set this to true to
> ensure services are not called accidentally by FW/1 while they are
> developing.
>
> In FW/1 2.0, this option will default to true - the implicit call of
> services/section.cfc:item() will not occur unless you explicitly set
> it to false.
>
> Those who were at the CFUnited FW/1 BoF participated in the discussion
> that led up to this decision and will not be surprised to see this new
> feature!
>
> Also, populate() has had a couple of tweaks thanx to suggestions from
> Henry Ho...
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
Sean Corfield
> Hmmmmm... Obviously a handy feature for those running into issues
> with their service calls. I'm not sure I like the change of the
> default in 2.0, though.
FW/1 2.0 will not be entirely backward compatible with 1.x. I need to
tighten up the APIs, remove / rename a bunch of deprecated stuff and
generally try to clean stuff up. I'll provide a migration guide but I
expect some level of minor changes to be required to move an
application from FW/1 1.x to 2.0.
In addition, FW/1 2.0 will *require* CF9.0.1 / Railo 3.2 / OpenBD 1.4
(as will DI/1). FW/1 1.x will continue to get bug fixes and security
patches but will get no new features after 1.2.
> Shouldn't the default reflect the most common choice?
The default for 1.2 reflects the original expectations for common
practice but I'm not sure that the majority of current FW/1 users are
relying (entirely) on implicit service calls already...
But best practice for 2.0 will dictate that you explicitly call
service( 'section.item' ); in your controller - or perform direct
calls to your model (via explicit object creation or via a bean
factory).
> Is there some theoretical reason I should be calling my
> services directly? I can't think of any.
Most people are finding that as their applications grow in complexity,
they need to take control of their services because they're making
multiple service calls and need that flexibility. If the current setup
is working for you, that's great and you need make no change for 1.2.
If / when you're ready for a upgrade to 2.0, you can either set the
suppressImplicitService setting false in Application.cfc or add
explicit service() calls into your controllers (possibly adding
controller methods to do that if you'be omitted them). I suspect
changing the setting will be less work (but who knows what other
subtle API changes you may need to react to - if you're doing anything
that is deprecated).
On deprecated, everything marked deprecated in 1.x *will* change in
2.0. I will rename methods and request scope variables to *ensure* no
one is relying on deprecated APIs. The reason for that is that in
order to clean up the framework as part of the 2.0 rewrite, I need the
freedom to refactor anything not defined as a callable API. Where I
plan to introduce new API methods to access current request variables,
I will probably create a 1.x release that includes the new API methods
(but keeps the old variables) as a migration path - but it depends on
how much clean up I need to do.
I'm giving everyone plenty of notice so no one gets surprised. And
I'll be looking for lots of feedback on the new APIs over the next few
months.
> Plus, shouldn't there be a
> heavier weight given to options that don't break existing code?
We've worked hard to ensure 1.x releases are backward compatible but
I've stated several times that 2.0 *will break code*. In the
particular instance of implicit service calls, 2.0 will offer a
backward compatibility option because it's breaking something that
isn't technically deprecated. This decision has been made on the back
of a *lot* of community feedback, both on this list and in private
discussions with FW/1 users - and at the BoF at CFUnited (we had about
40 people present and spent quite a bit of time on this issue).
> Not a
> big deal, really, but updating the framework could cause problems for
> existing apps if a lot of apps are using a single framework instance
> on the server.
I agree - but since it's one CFC that can live in any folder and the
only dependency is the extends= in your Application.cfc, it's much
easier to migrate one app at a time with FW/1 than many other
frameworks.
Anyone here been working with ColdBox 3.0? Most every M release has
broken existing code. Now, I know it's prerelease software but I'm
putting it up as a comparison point. ColdBox 2.x -> 3.0 is a big jump
with lots of breakages / changes in existing applications and even
within the 3.0 stream, each milestone has brought new breakages /
changes.
Mike Rankin
putting the framework file in the app root to deal with possible work
that needs to be done upgrading the framework. Works like a charm and
lets you work on an app when you're ready.
Come to think of it, I often wish that Adobromediallair had made the
same decision regarding cflocation and addToken.
On Aug 9, 6:25 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> An Architect's View --http://corfield.org/