All,
how would I get the htmlBaseURL setting as a replacement setting? ie.
I want to be able to have this custom setting available...
<Setting name="application_url" value="${htmlBaseURL}"/>
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.
any thoughts?
Are you putting it in YourSettings?
<YourSettings>
<Setting name="application_url" value="$
{htmlBaseURL}"/>
</YourSettings>
?
yes.
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?
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.
I have tested and verified your findings. Here are your options:
#getSetting('htmlBaseURL')#
In your model object you can:
1.) Use cfproperty to inject the setting:
<cfproperty name="htmlBaseURL"
type="coldbox:setting:htmlBaseURL" scope="instance">
2.) Use constructor arguments:
<cffunction name="init" returntype="any" output="false">
<cfargument name="htmlBaseURL" type="any"
_wireme="coldbox:setting:htmlBaseURL" />
</cffunction>
3.) User setters:
<cffunction name="setHtmlBaseURL" type="any" output="true"
_wireme="coldbox:setting:htmlBaseURL">
</cffunction>
4.) If you are using IoC (such as ColdSpring):
<bean id="someModelObject" class="model.test.someModelObject">
<constructor-arg name="htmlBaseURL">
<value>${htmlBaseURL}</value>
</constructor-arg>
</bean>
Then add to your init() method:
<cffunction name="init" access="public" returntype="any"
hint="Constructor.">
<cfargument name="htmlBaseURL" type="string" />
<cfset variables.instance['htmlBaseURL'] = arguments.htmlBaseURL /
<cfreturn this />
</cffunction>
or
<bean id="someModelObject" class="model.test.someModelObject">
<property name="htmlBaseURL"><value>${htmlBaseURL}</value></property>
</bean>
You then put a setter on your model object:
<cffunction name="setHtmlBaseURL" type="any" output="true">
<cfargument name="htmlBaseURL" type="any" required="true" /
<cfset variables.instance['htmlBaseURL'] =
arguments.htmlBaseURL />
</cffunction>
YOU ARE DEFINITELY the JBoss!! 
thanks much, I surely do appreciate your efforts...
I'll be definitely using coldbox's native injector.
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.
“…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
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.
I can do:
http://www.foo.com/123
http://www.foo.com/user/25
http://www.foo.com/calendar
http://www.foo.com/calendar/6/25
etc...
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.
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.
thank you. exciting stuff especially with 3.0 on the horizon.
Yes, I am going to switch to bleeding edge from the SVN tomorrow to
start preparing for the 3.0 release.
yep! Coldbox rules I couldn't agree more...
I really wanna start using cfspec for my CB apps. anyone spec-ing
their cb apps?
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.
For the moment, check LogBox feature which offer more than even
log4j
http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbLogBox
Thanks
Sana
Good stuff Sana!
sweet! thanks Sana!