Wow...so I've probably spend the last month reading the documentation,
looking at sample code and following posts to this group in an effort
to learn ColdBox...or more importantly to figure out if I should start
using it. I have been a CF developer for a long time and I LOVE to
learn new ways of doing things...and ColdBox is truly the most unique,
albeit so far most complex, framework I have ever seen. I am amazed
by the support I see in the community, particularly Luis' ability to
respond to alot of forum posts on a very regular basis.
So, that being said, I think I have decided I really want to jump on
this band wagon and start programming in a way that seems more
consistent with the way I think, as CB does.
However, I am a firm believer in walking before I run, so here's my
question...based on the "advanced" application template as a starting
point and getting far enough so that I'm using a view for my request
event and a layout, I have two questions based on this code:
#rc.welcomeMessage#<br>
ApplicationPath: #getSetting("ApplicationPath", false)#<br>
FrameworkPath: #getSetting("FrameworkPath", true)#<br>
1). The above code is in a view and every time I make a change and
refresh the page, nothing happens...I always have to reinit the
framework. Is there a default cache I have not learned about. There
is no active cache settings I could find in the default coldbox.cfc
and I would have suspected this behavior perhaps if handler or
configuration code changes, not view or layout code.
2). If I display the settings payload structure (using rc.mycbs =
controller.getColdboxSettings() in the handler), I get a list of all
the settings so I plucked out two at random in the above code to
display. I get an error if the frameworkpath request is set to false
or omitted (the default value for that parameter) but don't for
applicationpath. Why would one work that way and not the other?
Part of why I typically struggle and eventually abandon most
frameworks is because of the learning curve involved. And that is not
the learning curve of how to code something using the framework, but
rather the how's and why's of what the code does or what scope it sits
in or where did it originate. This is particularly difficult with the
concept of IOC since, from what I can see, the injected functions
often become very global in nature so that the lines between scopes
and processes get blurred. That may be a very rudimentary way of
describing it but please, bear with me as I'm new to IOC in CF (and CB
for that matter).
Anyway...can someone point me in a direction on these two issues?
Please don't tell me I just skipped a couple of "chapters"
somewhere...I'm tired of reading and want to get more than just my
feet wet.
Thanks,
Mike
Please ask away any question you might have. The idea of having such an extensive library of documentation is that I strongly believe that the developers should have all the necessary information at their disposal. This is a double edged sword as it creates a sense of complexity and incredible size. When in reality, I am incredibly details and I decide that everything that is coded is documented for further retrieval.