however when I set this, I get a VAR_NOT_FOUND exception. Is there
anyway I can do this? Would I need to move my interceptor config above
my custom settings config block?
why I'm attempting this, is because I need to be able to generate a
URL in a model for an email notification.
> however when I set this, I get a VAR_NOT_FOUND exception. Is there
> anyway I can do this? Would I need to move my interceptor config above
> my custom settings config block?
> why I'm attempting this, is because I need to be able to generate a
> URL in a model for an email notification.
> > however when I set this, I get a VAR_NOT_FOUND exception. Is there
> > anyway I can do this? Would I need to move my interceptor config above
> > my custom settings config block?
> > why I'm attempting this, is because I need to be able to generate a
> > URL in a model for an email notification.
> > > however when I set this, I get a VAR_NOT_FOUND exception. Is there
> > > anyway I can do this? Would I need to move my interceptor config above
> > > my custom settings config block?
> > > why I'm attempting this, is because I need to be able to generate a
> > > URL in a model for an email notification.
> > > > however when I set this, I get a VAR_NOT_FOUND exception. Is there
> > > > anyway I can do this? Would I need to move my interceptor config above
> > > > my custom settings config block?
> > > > why I'm attempting this, is because I need to be able to generate a
> > > > URL in a model for an email notification.
> didn't know I had scope to the getSetting() method within a model???
> but yes, I get the error when trying to retrieve the custom setting.
> On Jul 8, 3:04 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > Oh, wait, nevermind.
> > Can you give me some more details about what you're doing? Do you get
> > the VAR_NOT_FOUND error when you set it or when you try to retrieve
> > it?
> > If you just want htmlBaseURL, why aren't you just using getSetting
> > ('htmlBaseURL') in your model?
> > On Jul 8, 1:48 pm, salomoko <salomon.valve...@gmail.com> wrote:
> > > > > however when I set this, I get a VAR_NOT_FOUND exception. Is there
> > > > > anyway I can do this? Would I need to move my interceptor config above
> > > > > my custom settings config block?
> > > > > why I'm attempting this, is because I need to be able to generate a
> > > > > URL in a model for an email notification.
> On Jul 8, 2:38 pm, salomoko <salomon.valve...@gmail.com> wrote:
> > didn't know I had scope to the getSetting() method within a model???
> > but yes, I get the error when trying to retrieve the custom setting.
> > On Jul 8, 3:04 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > > Oh, wait, nevermind.
> > > Can you give me some more details about what you're doing? Do you get
> > > the VAR_NOT_FOUND error when you set it or when you try to retrieve
> > > it?
> > > If you just want htmlBaseURL, why aren't you just using getSetting
> > > ('htmlBaseURL') in your model?
> > > > > > how would I get the htmlBaseURL setting as a replacement setting? ie.
> > > > > > I want to be able to have this custom setting available...
> > > > > > however when I set this, I get a VAR_NOT_FOUND exception. Is there
> > > > > > anyway I can do this? Would I need to move my interceptor config above
> > > > > > my custom settings config block?
> > > > > > why I'm attempting this, is because I need to be able to generate a
> > > > > > URL in a model for an email notification.
> > > > Can you give me some more details about what you're doing? Do you get
> > > > the VAR_NOT_FOUND error when you set it or when you try to retrieve
> > > > it?
> > > > If you just want htmlBaseURL, why aren't you just using getSetting
> > > > ('htmlBaseURL') in your model?
> > > > > > > how would I get the htmlBaseURL setting as a replacement setting? ie.
> > > > > > > I want to be able to have this custom setting available...
> > > > > > > however when I set this, I get a VAR_NOT_FOUND exception. Is there
> > > > > > > anyway I can do this? Would I need to move my interceptor config above
> > > > > > > my custom settings config block?
> > > > > > > why I'm attempting this, is because I need to be able to generate a
> > > > > > > URL in a model for an email notification.
> > > > > Can you give me some more details about what you're doing? Do you
> get
> > > > > the VAR_NOT_FOUND error when you set it or when you try to retrieve
> > > > > it?
> > > > > If you just want htmlBaseURL, why aren't you just using getSetting
> > > > > ('htmlBaseURL') in your model?
> > > > > > > > how would I get the htmlBaseURL setting as a replacement
> setting? ie.
> > > > > > > > I want to be able to have this custom setting available...
> > > > > > > > however when I set this, I get a VAR_NOT_FOUND exception. Is
> there
> > > > > > > > anyway I can do this? Would I need to move my interceptor
> config above
> > > > > > > > my custom settings config block?
> > > > > > > > why I'm attempting this, is because I need to be able to
> generate a
> > > > > > > > URL in a model for an email notification.
Well, I'm writing an article about it right now. I plan to make a very
good case for CFML as a stable and rapid deployment platform,
particularly using the emerging open source tools and app engines. I
think we'll see a lot more of ColdBox in enterprise production
environments soon.
So, with that aside, I think ColdBox is the most flexible and most
powerful CF framework out right now, at least for my needs. Others may
be sufficient for specific needs, but for a flexible, scalable and
FAST solution, ColdBox works perfectly for me. I know a lot of people
consider their framework the "best", I think there is the best for
certain jobs. I can see uses for others, but none of them do anything
ColdBox does not. I cannot say the same applies in reverse...
Some points:
It's easy to get started with. You can pick it up and quickly begin
developing apps, but if you want complexity, it's also there from the
very beginning. If you don't fully understand MVC or some other
elements of OO web development, ColdBox is still very natural to use
and introduces you to many concepts in a new way, this has been
something many people that have worked with it have said.
It gives you SO much built-in functionality, but leaves the door wide
open for your own integrations. The layer separation is great, and
with the addition of standalone modules (something I suggested in
enhancements, unaware that Luis was already working on it) and the
Hibernate interceptor (which I am working on) so much complex work is
done for you, but you still get a grip on exactly what's going on
underneath.
Things like the Groovy loader, Transfer and Reactor integration,
Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
which will be standalone also), Security, Interceptors, CONVENTION
(this is huge, the ability to have convention over configuration,
while configuration is still an OPTION, not forced)
There is a LOT of documentation (600+ pages, plus a full API guide
online, trac, wiki, tutorials, forums, etc). The information is not
sparse like with many frameworks.
For a skin and bones application, ColdBox is very light and easy to
launch. It allows you to add on easily without weighing you down from
the beginning. With built-in dependency management, AOP via
interceptors, etc it's really amazing how it runs so fast.
Security is handled in a great way, and leaves open hooks for your own
validators and logic.
Debuggins is a breeze.
The caching system alone is worth switch for, I haven't seen quite
this much attention applied. It's very slick and thinks ahead.
There is an Illudium PU-36 template set, as well as an Eclipse plugin
for code generation and easy development.
I'm running ColdBox on Railo and seeing (literally) 10 times the
performance vs. CF8 in many cases.
I have pages that are 284 milliseconds on CF8, while the exact same
code runs in 29 milliseconds on Railo.
The same handlers, all configured optimally using ModelGlue or FuseBox
are not as fast as they are in ColdBox.
> > > > > > Can you give me some more details about what you're doing? Do you
> > get
> > > > > > the VAR_NOT_FOUND error when you set it or when you try to retrieve
> > > > > > it?
> > > > > > If you just want htmlBaseURL, why aren't you just using getSetting
> > > > > > ('htmlBaseURL') in your model?
> > > > > > > > > how would I get the htmlBaseURL setting as a replacement
> > setting? ie.
> > > > > > > > > I want to be able to have this custom setting available...
> > > > > > > > > however when I set this, I get a VAR_NOT_FOUND exception. Is
> > there
> > > > > > > > > anyway I can do this? Would I need to move my interceptor
> > config above
> > > > > > > > > my custom settings config block?
> > > > > > > > > why I'm attempting this, is because I need to be able to
> > generate a
> > > > > > > > > URL in a model for an email notification.
Oh, and the remote proxying is amazing as well. You can set up a proxy
cfc (examples provided) that can tie in and execute any method within
the system remotely. (So from Flex, AJAX, etc) ColdBox basically
morphs into a remote facade for the ENTIRE application. This means
your handlers can server views and layouts, but also have detection if
the request is remote and provide a return as well. You don't have to
duplicate. You can serve beans from your IoC (ColdSpring, etc), get
model objects, do anything really, without changing your code at all.
Just set up a ColdBoxProxy.cfc (you can have multiple, I have
FlexProxy.cfc also) and your entire site is automatically ready for
remote methods.
On Jul 8, 4:44 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> Well, I'm writing an article about it right now. I plan to make a very
> good case for CFML as a stable and rapid deployment platform,
> particularly using the emerging open source tools and app engines. I
> think we'll see a lot more of ColdBox in enterprise production
> environments soon.
> So, with that aside, I think ColdBox is the most flexible and most
> powerful CF framework out right now, at least for my needs. Others may
> be sufficient for specific needs, but for a flexible, scalable and
> FAST solution, ColdBox works perfectly for me. I know a lot of people
> consider their framework the "best", I think there is the best for
> certain jobs. I can see uses for others, but none of them do anything
> ColdBox does not. I cannot say the same applies in reverse...
> Some points:
> It's easy to get started with. You can pick it up and quickly begin
> developing apps, but if you want complexity, it's also there from the
> very beginning. If you don't fully understand MVC or some other
> elements of OO web development, ColdBox is still very natural to use
> and introduces you to many concepts in a new way, this has been
> something many people that have worked with it have said.
> It gives you SO much built-in functionality, but leaves the door wide
> open for your own integrations. The layer separation is great, and
> with the addition of standalone modules (something I suggested in
> enhancements, unaware that Luis was already working on it) and the
> Hibernate interceptor (which I am working on) so much complex work is
> done for you, but you still get a grip on exactly what's going on
> underneath.
> Things like the Groovy loader, Transfer and Reactor integration,
> Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
> which will be standalone also), Security, Interceptors, CONVENTION
> (this is huge, the ability to have convention over configuration,
> while configuration is still an OPTION, not forced)
> There is a LOT of documentation (600+ pages, plus a full API guide
> online, trac, wiki, tutorials, forums, etc). The information is not
> sparse like with many frameworks.
> For a skin and bones application, ColdBox is very light and easy to
> launch. It allows you to add on easily without weighing you down from
> the beginning. With built-in dependency management, AOP via
> interceptors, etc it's really amazing how it runs so fast.
> Security is handled in a great way, and leaves open hooks for your own
> validators and logic.
> Debuggins is a breeze.
> The caching system alone is worth switch for, I haven't seen quite
> this much attention applied. It's very slick and thinks ahead.
> There is an Illudium PU-36 template set, as well as an Eclipse plugin
> for code generation and easy development.
> I'm running ColdBox on Railo and seeing (literally) 10 times the
> performance vs. CF8 in many cases.
> I have pages that are 284 milliseconds on CF8, while the exact same
> code runs in 29 milliseconds on Railo.
> The same handlers, all configured optimally using ModelGlue or FuseBox
> are not as fast as they are in ColdBox.
> > > > > > > Can you give me some more details about what you're doing? Do you
> > > get
> > > > > > > the VAR_NOT_FOUND error when you set it or when you try to retrieve
> > > > > > > it?
> > > > > > > If you just want htmlBaseURL, why aren't you just using getSetting
> > > > > > > ('htmlBaseURL') in your model?
> > > > > > > > > > how would I get the htmlBaseURL setting as a replacement
> > > setting? ie.
> > > > > > > > > > I want to be able to have this custom setting available...
> > > > > > > > > > however when I set this, I get a VAR_NOT_FOUND exception. Is
> > > there
> > > > > > > > > > anyway I can do this? Would I need to move my interceptor
> > > config above
> > > > > > > > > > my custom settings config block?
> > > > > > > > > > why I'm attempting this, is because I need to be able to
> > > generate a
> > > > > > > > > > URL in a model for an email notification.
> Oh, and the remote proxying is amazing as well. You can set up a proxy
> cfc (examples provided) that can tie in and execute any method within
> the system remotely. (So from Flex, AJAX, etc) ColdBox basically
> morphs into a remote facade for the ENTIRE application. This means
> your handlers can server views and layouts, but also have detection if
> the request is remote and provide a return as well. You don't have to
> duplicate. You can serve beans from your IoC (ColdSpring, etc), get
> model objects, do anything really, without changing your code at all.
> Just set up a ColdBoxProxy.cfc (you can have multiple, I have
> FlexProxy.cfc also) and your entire site is automatically ready for
> remote methods.
> On Jul 8, 4:44 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > Well, I'm writing an article about it right now. I plan to make a very
> > good case for CFML as a stable and rapid deployment platform,
> > particularly using the emerging open source tools and app engines. I
> > think we'll see a lot more of ColdBox in enterprise production
> > environments soon.
> > So, with that aside, I think ColdBox is the most flexible and most
> > powerful CF framework out right now, at least for my needs. Others may
> > be sufficient for specific needs, but for a flexible, scalable and
> > FAST solution, ColdBox works perfectly for me. I know a lot of people
> > consider their framework the "best", I think there is the best for
> > certain jobs. I can see uses for others, but none of them do anything
> > ColdBox does not. I cannot say the same applies in reverse...
> > Some points:
> > It's easy to get started with. You can pick it up and quickly begin
> > developing apps, but if you want complexity, it's also there from the
> > very beginning. If you don't fully understand MVC or some other
> > elements of OO web development, ColdBox is still very natural to use
> > and introduces you to many concepts in a new way, this has been
> > something many people that have worked with it have said.
> > It gives you SO much built-in functionality, but leaves the door wide
> > open for your own integrations. The layer separation is great, and
> > with the addition of standalone modules (something I suggested in
> > enhancements, unaware that Luis was already working on it) and the
> > Hibernate interceptor (which I am working on) so much complex work is
> > done for you, but you still get a grip on exactly what's going on
> > underneath.
> > Things like the Groovy loader, Transfer and Reactor integration,
> > Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
> > which will be standalone also), Security, Interceptors, CONVENTION
> > (this is huge, the ability to have convention over configuration,
> > while configuration is still an OPTION, not forced)
> > There is a LOT of documentation (600+ pages, plus a full API guide
> > online, trac, wiki, tutorials, forums, etc). The information is not
> > sparse like with many frameworks.
> > For a skin and bones application, ColdBox is very light and easy to
> > launch. It allows you to add on easily without weighing you down from
> > the beginning. With built-in dependency management, AOP via
> > interceptors, etc it's really amazing how it runs so fast.
> > Security is handled in a great way, and leaves open hooks for your own
> > validators and logic.
> > Debuggins is a breeze.
> > The caching system alone is worth switch for, I haven't seen quite
> > this much attention applied. It's very slick and thinks ahead.
> > There is an Illudium PU-36 template set, as well as an Eclipse plugin
> > for code generation and easy development.
> > I'm running ColdBox on Railo and seeing (literally) 10 times the
> > performance vs. CF8 in many cases.
> > I have pages that are 284 milliseconds on CF8, while the exact same
> > code runs in 29 milliseconds on Railo.
> > The same handlers, all configured optimally using ModelGlue or FuseBox
> > are not as fast as they are in ColdBox.
> > ColdBox is very powerful and comes with a ton of example applications,
> > including examples integrated with Transfer and alot more.
> > Luis and the CB guys are always prompt in responding and try very hard
> > to help.
> > ColdBox + Railo = fast fast fast
> > This was typed up in casually, my article will make the case more
> > clearly and properly.
> > Anyway, ColdBox is my framework of choice for the foreseeable future.
> > I can write in all Groovy if I like and use ColdBox as a glue layer.
> > I have other apps in MG, one in mach-ii, some tests in FB, but none
> > have been as much fun, nor as easy and powerful to work with as
> > ColdBox.
> > On Jul 8, 4:24 pm, Dorioo <dor...@gmail.com> wrote:
> > > "...I think more people will start to realize its power soon"
> > > Care to elaborate a little on that? Or was it just a general tease :-)
> > > - Gabriel
> > > On Wed, Jul 8, 2009 at 7:20 PM, whostheJBoss <
> dotfus...@changethings.org>wrote:
> > > > No problem :)
> > > > Glad you have found a suitable solution!
> > > > ColdBox is my hero right now, I think more people will start to
> > > > realize its power soon...
> > > > Let me know if you have any other problems.
> > > > On Jul 8, 4:17 pm, salomoko <salomon.valve...@gmail.com> wrote:
> > > > > YOU ARE DEFINITELY the JBoss!! :-)
> > > > > thanks much, I surely do appreciate your efforts...
> > > > > I'll be definitely using coldbox's native injector.
> > > > > > > > Can you give me some more details about what you're doing? Do
> you
> > > > get
> > > > > > > > the VAR_NOT_FOUND error when you set it or when you try to
> retrieve
> > > > > > > > it?
> > > > > > > > If you just want htmlBaseURL, why aren't you just using
> getSetting
> > > > > > > > ('htmlBaseURL') in your model?
> > > > > > > > > > > how would I get the htmlBaseURL setting as a
> replacement
> > > > setting? ie.
> > > > > > > > > > > I want to be able to have this custom setting
> available...
> thank you. exciting stuff especially with 3.0 on the horizon.
> - Gabriel
> On Wed, Jul 8, 2009 at 7:49 PM, whostheJBoss <dotfus...@changethings.org>wrote:
> > Oh, and the remote proxying is amazing as well. You can set up a proxy
> > cfc (examples provided) that can tie in and execute any method within
> > the system remotely. (So from Flex, AJAX, etc) ColdBox basically
> > morphs into a remote facade for the ENTIRE application. This means
> > your handlers can server views and layouts, but also have detection if
> > the request is remote and provide a return as well. You don't have to
> > duplicate. You can serve beans from your IoC (ColdSpring, etc), get
> > model objects, do anything really, without changing your code at all.
> > Just set up a ColdBoxProxy.cfc (you can have multiple, I have
> > FlexProxy.cfc also) and your entire site is automatically ready for
> > remote methods.
> > On Jul 8, 4:44 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > > Well, I'm writing an article about it right now. I plan to make a very
> > > good case for CFML as a stable and rapid deployment platform,
> > > particularly using the emerging open source tools and app engines. I
> > > think we'll see a lot more of ColdBox in enterprise production
> > > environments soon.
> > > So, with that aside, I think ColdBox is the most flexible and most
> > > powerful CF framework out right now, at least for my needs. Others may
> > > be sufficient for specific needs, but for a flexible, scalable and
> > > FAST solution, ColdBox works perfectly for me. I know a lot of people
> > > consider their framework the "best", I think there is the best for
> > > certain jobs. I can see uses for others, but none of them do anything
> > > ColdBox does not. I cannot say the same applies in reverse...
> > > Some points:
> > > It's easy to get started with. You can pick it up and quickly begin
> > > developing apps, but if you want complexity, it's also there from the
> > > very beginning. If you don't fully understand MVC or some other
> > > elements of OO web development, ColdBox is still very natural to use
> > > and introduces you to many concepts in a new way, this has been
> > > something many people that have worked with it have said.
> > > It gives you SO much built-in functionality, but leaves the door wide
> > > open for your own integrations. The layer separation is great, and
> > > with the addition of standalone modules (something I suggested in
> > > enhancements, unaware that Luis was already working on it) and the
> > > Hibernate interceptor (which I am working on) so much complex work is
> > > done for you, but you still get a grip on exactly what's going on
> > > underneath.
> > > Things like the Groovy loader, Transfer and Reactor integration,
> > > Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
> > > which will be standalone also), Security, Interceptors, CONVENTION
> > > (this is huge, the ability to have convention over configuration,
> > > while configuration is still an OPTION, not forced)
> > > There is a LOT of documentation (600+ pages, plus a full API guide
> > > online, trac, wiki, tutorials, forums, etc). The information is not
> > > sparse like with many frameworks.
> > > For a skin and bones application, ColdBox is very light and easy to
> > > launch. It allows you to add on easily without weighing you down from
> > > the beginning. With built-in dependency management, AOP via
> > > interceptors, etc it's really amazing how it runs so fast.
> > > Security is handled in a great way, and leaves open hooks for your own
> > > validators and logic.
> > > Debuggins is a breeze.
> > > The caching system alone is worth switch for, I haven't seen quite
> > > this much attention applied. It's very slick and thinks ahead.
> > > There is an Illudium PU-36 template set, as well as an Eclipse plugin
> > > for code generation and easy development.
> > > I'm running ColdBox on Railo and seeing (literally) 10 times the
> > > performance vs. CF8 in many cases.
> > > I have pages that are 284 milliseconds on CF8, while the exact same
> > > code runs in 29 milliseconds on Railo.
> > > The same handlers, all configured optimally using ModelGlue or FuseBox
> > > are not as fast as they are in ColdBox.
> > > ColdBox is very powerful and comes with a ton of example applications,
> > > including examples integrated with Transfer and alot more.
> > > Luis and the CB guys are always prompt in responding and try very hard
> > > to help.
> > > ColdBox + Railo = fast fast fast
> > > This was typed up in casually, my article will make the case more
> > > clearly and properly.
> > > Anyway, ColdBox is my framework of choice for the foreseeable future.
> > > I can write in all Groovy if I like and use ColdBox as a glue layer.
> > > I have other apps in MG, one in mach-ii, some tests in FB, but none
> > > have been as much fun, nor as easy and powerful to work with as
> > > ColdBox.
> > > > > > > > > Can you give me some more details about what you're doing? Do
> > you
> > > > > get
> > > > > > > > > the VAR_NOT_FOUND error when you set it or when you try to
> > retrieve
> > > > > > > > > it?
> > > > > > > > > If you just want htmlBaseURL, why aren't you just using
> > getSetting
> > > > > > > > > ('htmlBaseURL') in your model?
> Yes, I am going to switch to bleeding edge from the SVN tomorrow to
> start preparing for the 3.0 release.
> On Jul 8, 5:10 pm, Dorioo <dor...@gmail.com> wrote:
> > thank you. exciting stuff especially with 3.0 on the horizon.
> > - Gabriel
> > On Wed, Jul 8, 2009 at 7:49 PM, whostheJBoss <dotfus...@changethings.org>wrote:
> > > Oh, and the remote proxying is amazing as well. You can set up a proxy
> > > cfc (examples provided) that can tie in and execute any method within
> > > the system remotely. (So from Flex, AJAX, etc) ColdBox basically
> > > morphs into a remote facade for the ENTIRE application. This means
> > > your handlers can server views and layouts, but also have detection if
> > > the request is remote and provide a return as well. You don't have to
> > > duplicate. You can serve beans from your IoC (ColdSpring, etc), get
> > > model objects, do anything really, without changing your code at all.
> > > Just set up a ColdBoxProxy.cfc (you can have multiple, I have
> > > FlexProxy.cfc also) and your entire site is automatically ready for
> > > remote methods.
> > > On Jul 8, 4:44 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > > > Well, I'm writing an article about it right now. I plan to make a very
> > > > good case for CFML as a stable and rapid deployment platform,
> > > > particularly using the emerging open source tools and app engines. I
> > > > think we'll see a lot more of ColdBox in enterprise production
> > > > environments soon.
> > > > So, with that aside, I think ColdBox is the most flexible and most
> > > > powerful CF framework out right now, at least for my needs. Others may
> > > > be sufficient for specific needs, but for a flexible, scalable and
> > > > FAST solution, ColdBox works perfectly for me. I know a lot of people
> > > > consider their framework the "best", I think there is the best for
> > > > certain jobs. I can see uses for others, but none of them do anything
> > > > ColdBox does not. I cannot say the same applies in reverse...
> > > > Some points:
> > > > It's easy to get started with. You can pick it up and quickly begin
> > > > developing apps, but if you want complexity, it's also there from the
> > > > very beginning. If you don't fully understand MVC or some other
> > > > elements of OO web development, ColdBox is still very natural to use
> > > > and introduces you to many concepts in a new way, this has been
> > > > something many people that have worked with it have said.
> > > > It gives you SO much built-in functionality, but leaves the door wide
> > > > open for your own integrations. The layer separation is great, and
> > > > with the addition of standalone modules (something I suggested in
> > > > enhancements, unaware that Luis was already working on it) and the
> > > > Hibernate interceptor (which I am working on) so much complex work is
> > > > done for you, but you still get a grip on exactly what's going on
> > > > underneath.
> > > > Things like the Groovy loader, Transfer and Reactor integration,
> > > > Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
> > > > which will be standalone also), Security, Interceptors, CONVENTION
> > > > (this is huge, the ability to have convention over configuration,
> > > > while configuration is still an OPTION, not forced)
> > > > There is a LOT of documentation (600+ pages, plus a full API guide
> > > > online, trac, wiki, tutorials, forums, etc). The information is not
> > > > sparse like with many frameworks.
> > > > For a skin and bones application, ColdBox is very light and easy to
> > > > launch. It allows you to add on easily without weighing you down from
> > > > the beginning. With built-in dependency management, AOP via
> > > > interceptors, etc it's really amazing how it runs so fast.
> > > > Security is handled in a great way, and leaves open hooks for your own
> > > > validators and logic.
> > > > Debuggins is a breeze.
> > > > The caching system alone is worth switch for, I haven't seen quite
> > > > this much attention applied. It's very slick and thinks ahead.
> > > > There is an Illudium PU-36 template set, as well as an Eclipse plugin
> > > > for code generation and easy development.
> > > > I'm running ColdBox on Railo and seeing (literally) 10 times the
> > > > performance vs. CF8 in many cases.
> > > > I have pages that are 284 milliseconds on CF8, while the exact same
> > > > code runs in 29 milliseconds on Railo.
> > > > The same handlers, all configured optimally using ModelGlue or FuseBox
> > > > are not as fast as they are in ColdBox.
> > > > ColdBox is very powerful and comes with a ton of example applications,
> > > > including examples integrated with Transfer and alot more.
> > > > Luis and the CB guys are always prompt in responding and try very hard
> > > > to help.
> > > > ColdBox + Railo = fast fast fast
> > > > This was typed up in casually, my article will make the case more
> > > > clearly and properly.
> > > > Anyway, ColdBox is my framework of choice for the foreseeable future.
> > > > I can write in all Groovy if I like and use ColdBox as a glue layer.
> > > > I have other apps in MG, one in mach-ii, some tests in FB, but none
> > > > have been as much fun, nor as easy and powerful to work with as
> > > > ColdBox.
> > > > > > > > > > Can you give me some more details about what you're doing? Do
> > > you
> > > > > > get
> > > > > > > > > > the VAR_NOT_FOUND error when you set it or when you try to
> > > retrieve
> > > > > > > > > > it?
> > > > > > > > > > If you just want htmlBaseURL, why aren't you just using
> > > getSetting
> > > > > > > > > > ('htmlBaseURL') in your model?
We do have plan to implement like RSpec but at the moment other most
important feature are under dev.
Hopefully in coming versions we will baked this feature in core code
base.
> I really wanna start using cfspec for my CB apps. anyone spec-ing
> their cb apps?
> On Jul 8, 6:12 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > Yes, I am going to switch to bleeding edge from the SVN tomorrow to
> > start preparing for the 3.0 release.
> > On Jul 8, 5:10 pm, Dorioo <dor...@gmail.com> wrote:
> > > thank you. exciting stuff especially with 3.0 on the horizon.
> > > - Gabriel
> > > On Wed, Jul 8, 2009 at 7:49 PM, whostheJBoss <dotfus...@changethings.org>wrote:
> > > > Oh, and the remote proxying is amazing as well. You can set up a proxy
> > > > cfc (examples provided) that can tie in and execute any method within
> > > > the system remotely. (So from Flex, AJAX, etc) ColdBox basically
> > > > morphs into a remote facade for the ENTIRE application. This means
> > > > your handlers can server views and layouts, but also have detection if
> > > > the request is remote and provide a return as well. You don't have to
> > > > duplicate. You can serve beans from your IoC (ColdSpring, etc), get
> > > > model objects, do anything really, without changing your code at all.
> > > > Just set up a ColdBoxProxy.cfc (you can have multiple, I have
> > > > FlexProxy.cfc also) and your entire site is automatically ready for
> > > > remote methods.
> > > > On Jul 8, 4:44 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > > > > Well, I'm writing an article about it right now. I plan to make a very
> > > > > good case for CFML as a stable and rapid deployment platform,
> > > > > particularly using the emerging open source tools and app engines. I
> > > > > think we'll see a lot more of ColdBox in enterprise production
> > > > > environments soon.
> > > > > So, with that aside, I think ColdBox is the most flexible and most
> > > > > powerful CF framework out right now, at least for my needs. Others may
> > > > > be sufficient for specific needs, but for a flexible, scalable and
> > > > > FAST solution, ColdBox works perfectly for me. I know a lot of people
> > > > > consider their framework the "best", I think there is the best for
> > > > > certain jobs. I can see uses for others, but none of them do anything
> > > > > ColdBox does not. I cannot say the same applies in reverse...
> > > > > Some points:
> > > > > It's easy to get started with. You can pick it up and quickly begin
> > > > > developing apps, but if you want complexity, it's also there from the
> > > > > very beginning. If you don't fully understand MVC or some other
> > > > > elements of OO web development, ColdBox is still very natural to use
> > > > > and introduces you to many concepts in a new way, this has been
> > > > > something many people that have worked with it have said.
> > > > > It gives you SO much built-in functionality, but leaves the door wide
> > > > > open for your own integrations. The layer separation is great, and
> > > > > with the addition of standalone modules (something I suggested in
> > > > > enhancements, unaware that Luis was already working on it) and the
> > > > > Hibernate interceptor (which I am working on) so much complex work is
> > > > > done for you, but you still get a grip on exactly what's going on
> > > > > underneath.
> > > > > Things like the Groovy loader, Transfer and Reactor integration,
> > > > > Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
> > > > > which will be standalone also), Security, Interceptors, CONVENTION
> > > > > (this is huge, the ability to have convention over configuration,
> > > > > while configuration is still an OPTION, not forced)
> > > > > There is a LOT of documentation (600+ pages, plus a full API guide
> > > > > online, trac, wiki, tutorials, forums, etc). The information is not
> > > > > sparse like with many frameworks.
> > > > > For a skin and bones application, ColdBox is very light and easy to
> > > > > launch. It allows you to add on easily without weighing you down from
> > > > > the beginning. With built-in dependency management, AOP via
> > > > > interceptors, etc it's really amazing how it runs so fast.
> > > > > Security is handled in a great way, and leaves open hooks for your own
> > > > > validators and logic.
> > > > > Debuggins is a breeze.
> > > > > The caching system alone is worth switch for, I haven't seen quite
> > > > > this much attention applied. It's very slick and thinks ahead.
> > > > > There is an Illudium PU-36 template set, as well as an Eclipse plugin
> > > > > for code generation and easy development.
> > > > > I'm running ColdBox on Railo and seeing (literally) 10 times the
> > > > > performance vs. CF8 in many cases.
> > > > > I have pages that are 284 milliseconds on CF8, while the exact same
> > > > > code runs in 29 milliseconds on Railo.
> > > > > The same handlers, all configured optimally using ModelGlue or FuseBox
> > > > > are not as fast as they are in ColdBox.
> > > > > The SES in ColdBox is AMAZING and SMART.
> > > > > ColdBox is very powerful and comes with a ton of example applications,
> > > > > including examples integrated with Transfer and alot more.
> > > > > Luis and the CB guys are always prompt in responding and try very hard
> > > > > to help.
> > > > > ColdBox + Railo = fast fast fast
> > > > > This was typed up in casually, my article will make the case more
> > > > > clearly and properly.
> > > > > Anyway, ColdBox is my framework of choice for the foreseeable future.
> > > > > I can write in all Groovy if I like and use ColdBox as a glue layer.
> > > > > I have other apps in MG, one in mach-ii, some tests in FB, but none
> > > > > have been as much fun, nor as easy and powerful to work with as
> > > > > ColdBox.
> We do have plan to implement like RSpec but at the moment other most
> important feature are under dev.
> Hopefully in coming versions we will baked this feature in core code
> base.
> > > > thank you. exciting stuff especially with 3.0 on the horizon.
> > > > - Gabriel
> > > > On Wed, Jul 8, 2009 at 7:49 PM, whostheJBoss <dotfus...@changethings.org>wrote:
> > > > > Oh, and the remote proxying is amazing as well. You can set up a proxy
> > > > > cfc (examples provided) that can tie in and execute any method within
> > > > > the system remotely. (So from Flex, AJAX, etc) ColdBox basically
> > > > > morphs into a remote facade for the ENTIRE application. This means
> > > > > your handlers can server views and layouts, but also have detection if
> > > > > the request is remote and provide a return as well. You don't have to
> > > > > duplicate. You can serve beans from your IoC (ColdSpring, etc), get
> > > > > model objects, do anything really, without changing your code at all.
> > > > > Just set up a ColdBoxProxy.cfc (you can have multiple, I have
> > > > > FlexProxy.cfc also) and your entire site is automatically ready for
> > > > > remote methods.
> > > > > On Jul 8, 4:44 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > > > > > Well, I'm writing an article about it right now. I plan to make a very
> > > > > > good case for CFML as a stable and rapid deployment platform,
> > > > > > particularly using the emerging open source tools and app engines. I
> > > > > > think we'll see a lot more of ColdBox in enterprise production
> > > > > > environments soon.
> > > > > > So, with that aside, I think ColdBox is the most flexible and most
> > > > > > powerful CF framework out right now, at least for my needs. Others may
> > > > > > be sufficient for specific needs, but for a flexible, scalable and
> > > > > > FAST solution, ColdBox works perfectly for me. I know a lot of people
> > > > > > consider their framework the "best", I think there is the best for
> > > > > > certain jobs. I can see uses for others, but none of them do anything
> > > > > > ColdBox does not. I cannot say the same applies in reverse...
> > > > > > Some points:
> > > > > > It's easy to get started with. You can pick it up and quickly begin
> > > > > > developing apps, but if you want complexity, it's also there from the
> > > > > > very beginning. If you don't fully understand MVC or some other
> > > > > > elements of OO web development, ColdBox is still very natural to use
> > > > > > and introduces you to many concepts in a new way, this has been
> > > > > > something many people that have worked with it have said.
> > > > > > It gives you SO much built-in functionality, but leaves the door wide
> > > > > > open for your own integrations. The layer separation is great, and
> > > > > > with the addition of standalone modules (something I suggested in
> > > > > > enhancements, unaware that Luis was already working on it) and the
> > > > > > Hibernate interceptor (which I am working on) so much complex work is
> > > > > > done for you, but you still get a grip on exactly what's going on
> > > > > > underneath.
> > > > > > Things like the Groovy loader, Transfer and Reactor integration,
> > > > > > Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
> > > > > > which will be standalone also), Security, Interceptors, CONVENTION
> > > > > > (this is huge, the ability to have convention over configuration,
> > > > > > while configuration is still an OPTION, not forced)
> > > > > > There is a LOT of documentation (600+ pages, plus a full API guide
> > > > > > online, trac, wiki, tutorials, forums, etc). The information is not
> > > > > > sparse like with many frameworks.
> > > > > > For a skin and bones application, ColdBox is very light and easy to
> > > > > > launch. It allows you to add on easily without weighing you down from
> > > > > > the beginning. With built-in dependency management, AOP via
> > > > > > interceptors, etc it's really amazing how it runs so fast.
> > > > > > Security is handled in a great way, and leaves open hooks for your own
> > > > > > validators and logic.
> > > > > > Debuggins is a breeze.
> > > > > > The caching system alone is worth switch for, I haven't seen quite
> > > > > > this much attention applied. It's very slick and thinks ahead.
> > > > > > There is an Illudium PU-36 template set, as well as an Eclipse plugin
> > > > > > for code generation and easy development.
> > > > > > I'm running ColdBox on Railo and seeing (literally) 10 times the
> > > > > > performance vs. CF8 in many cases.
> > > > > > I have pages that are 284 milliseconds on CF8, while the exact same
> > > > > > code runs in 29 milliseconds on Railo.
> > > > > > The same handlers, all configured optimally using ModelGlue or FuseBox
> > > > > > are not as fast as they are in ColdBox.
> > > > > > The SES in ColdBox is AMAZING and SMART.
> > > > > > ColdBox is very powerful and comes with a ton of example applications,
> > > > > > including examples integrated with Transfer and alot more.
> > > > > > Luis and the CB guys are always prompt in responding and try very hard
> > > > > > to help.
> > > > > > ColdBox + Railo = fast fast fast
> > > > > > This was typed up in casually, my article will make the case more
> > > > > > clearly and properly.
> > > > > > Anyway, ColdBox is my framework of choice for the foreseeable future.
> > > > > > I can write in all Groovy if I like and use ColdBox as a glue layer.
> > > > > > I have other apps in MG, one in mach-ii, some tests in FB, but none
> > > > > > have been as much fun, nor as easy and powerful to work with as
> > > > > > ColdBox.
> On Jul 9, 3:12 pm, Sana <sanaulla...@gmail.com> wrote:
> > Hi salomoko,
> > We do have plan to implement like RSpec but at the moment other most
> > important feature are under dev.
> > Hopefully in coming versions we will baked this feature in core code
> > base.
> > > > > thank you. exciting stuff especially with 3.0 on the horizon.
> > > > > - Gabriel
> > > > > On Wed, Jul 8, 2009 at 7:49 PM, whostheJBoss <dotfus...@changethings.org>wrote:
> > > > > > Oh, and the remote proxying is amazing as well. You can set up a proxy
> > > > > > cfc (examples provided) that can tie in and execute any method within
> > > > > > the system remotely. (So from Flex, AJAX, etc) ColdBox basically
> > > > > > morphs into a remote facade for the ENTIRE application. This means
> > > > > > your handlers can server views and layouts, but also have detection if
> > > > > > the request is remote and provide a return as well. You don't have to
> > > > > > duplicate. You can serve beans from your IoC (ColdSpring, etc), get
> > > > > > model objects, do anything really, without changing your code at all.
> > > > > > Just set up a ColdBoxProxy.cfc (you can have multiple, I have
> > > > > > FlexProxy.cfc also) and your entire site is automatically ready for
> > > > > > remote methods.
> > > > > > On Jul 8, 4:44 pm, whostheJBoss <dotfus...@changethings.org> wrote:
> > > > > > > Well, I'm writing an article about it right now. I plan to make a very
> > > > > > > good case for CFML as a stable and rapid deployment platform,
> > > > > > > particularly using the emerging open source tools and app engines. I
> > > > > > > think we'll see a lot more of ColdBox in enterprise production
> > > > > > > environments soon.
> > > > > > > So, with that aside, I think ColdBox is the most flexible and most
> > > > > > > powerful CF framework out right now, at least for my needs. Others may
> > > > > > > be sufficient for specific needs, but for a flexible, scalable and
> > > > > > > FAST solution, ColdBox works perfectly for me. I know a lot of people
> > > > > > > consider their framework the "best", I think there is the best for
> > > > > > > certain jobs. I can see uses for others, but none of them do anything
> > > > > > > ColdBox does not. I cannot say the same applies in reverse...
> > > > > > > Some points:
> > > > > > > It's easy to get started with. You can pick it up and quickly begin
> > > > > > > developing apps, but if you want complexity, it's also there from the
> > > > > > > very beginning. If you don't fully understand MVC or some other
> > > > > > > elements of OO web development, ColdBox is still very natural to use
> > > > > > > and introduces you to many concepts in a new way, this has been
> > > > > > > something many people that have worked with it have said.
> > > > > > > It gives you SO much built-in functionality, but leaves the door wide
> > > > > > > open for your own integrations. The layer separation is great, and
> > > > > > > with the addition of standalone modules (something I suggested in
> > > > > > > enhancements, unaware that Luis was already working on it) and the
> > > > > > > Hibernate interceptor (which I am working on) so much complex work is
> > > > > > > done for you, but you still get a grip on exactly what's going on
> > > > > > > underneath.
> > > > > > > Things like the Groovy loader, Transfer and Reactor integration,
> > > > > > > Lightwire and ColdSpring integration, ColdBox's own IoC (BlenderBox,
> > > > > > > which will be standalone also), Security, Interceptors, CONVENTION
> > > > > > > (this is huge, the ability to have convention over configuration,
> > > > > > > while configuration is still an OPTION, not forced)
> > > > > > > There is a LOT of documentation (600+ pages, plus a full API guide
> > > > > > > online, trac, wiki, tutorials, forums, etc). The information is not
> > > > > > > sparse like with many frameworks.
> > > > > > > For a skin and bones application, ColdBox is very light and easy to
> > > > > > > launch. It allows you to add on easily without weighing you down from
> > > > > > > the beginning. With built-in dependency management, AOP via
> > > > > > > interceptors, etc it's really amazing how it runs so fast.
> > > > > > > Security is handled in a great way, and leaves open hooks for your own
> > > > > > > validators and logic.
> > > > > > > Debuggins is a breeze.
> > > > > > > The caching system alone is worth switch for, I haven't seen quite
> > > > > > > this much attention applied. It's very slick and thinks ahead.
> > > > > > > There is an Illudium PU-36 template set, as well as an Eclipse plugin
> > > > > > > for code generation and easy development.
> > > > > > > I'm running ColdBox on Railo and seeing (literally) 10 times the
> > > > > > > performance vs. CF8 in many cases.
> > > > > > > I have pages that are 284 milliseconds on CF8, while the exact same
> > > > > > > code runs in 29 milliseconds on Railo.
> > > > > > > The same handlers, all configured optimally using ModelGlue or FuseBox
> > > > > > > are not as fast as they are in ColdBox.
> > > > > > > The SES in ColdBox is AMAZING and SMART.
> > > > > > > ColdBox is very powerful and comes with a ton of example applications,
> > > > > > > including examples integrated with Transfer and alot more.
> > > > > > > Luis and the CB guys are always prompt in responding and try very hard
> > > > > > > to help.
> > > > > > > ColdBox + Railo = fast fast fast
> > > > > > > This was typed up in casually, my article will make the case more
> > > > > > > clearly and properly.
> > > > > > > Anyway, ColdBox is my framework of choice for the foreseeable future.
> > > > > > > I can write in all Groovy if I like and use ColdBox as a glue layer.
> > > > > > > I have other apps in MG, one in mach-ii, some tests in FB, but none
> > > > > > > have been as much fun, nor as easy and powerful to work with as
> > > > > > > ColdBox.
|
