It’s been quite-a-10-days. In fact, a little hard to believe it’s been 10 days. Technically it’s only been 9 days. Last weekend I proposed to my girlfriend of four years and she said yes! Although I’ve been working 12 hours a day, 7 days a week, it seemed like the right thing to do to take the day off.
Since then, my progress has been slower than desired. I’ve been bogged down in decision making. What to name events? Which controller should handle a certain broadcast? How smart to make my beans? How do I refactor existing procedural code into the new framework? These are the kinds of decisions that are second nature with experience but as a newbie, it’s difficult to know how these near-term decisions are going to influence my project later.
Despite the slow going, there have been moments of genius working with Model-Glue. Being able to rename an event or insert an additional broadcast somewhere has felt like a little piece of magic at times. It’s clear that, in the long run, these frameworks are worth the flexibility they provide. I wonder if it wouldn’t have been wiser to start from scratch instead of trying to salvage a lot of my code?
Not much to share other than a couple of cool findings in the past week. With my head down I haven’t learned much beyond what I posted about the lifecycle and SSL certificates.
Findings Today
- My last question was “Will I finish by Feb 6th”? The answer is shaping up to be “No”. I admitted defeat this morning and hired some expert Model-Glue help that starts Thursday. I’m hoping the contribution of 20-30 hours per week multiplies my productivity. If so, I should not be too far behind.
- Transfer tip: if you’re just getting started with Transfer, it can be easy to miss that putting a onetomany, manytoone or manytomany relationship in one object automatically generates the reciprocal methods on the other object. The docs are accurate but, for me, difficult to read. Pay close attention!
- Requiring SSL in Model-Glue and passing event parameters: There are times when you must use SSL like when checking out of a store. For normal Model-Glue redirects you can use the result tag to pass event values across the redirect like so:
<result do="someEvent" redirect="true" append="someVar,anotherVar,thirdVar" />
The problem is, what if you want to switch the URL to be HTTPS? There is no way to do this intrinsic to the framework. I solved it with the following broadcast:
<message name="verifySSL">
<argument name="varsToForward" value="someVar,anotherVar,thirdVar" />
<argument name="xeToForward" value="someEvent" />
</message>
varsToForward is a list of values to get from the event object and append to the URL for passing. It only works with simple values. xeToForward is the event you want to jump to. If you leave it out, it will redirect back to the current event but using SSL. This executes the following code in a controller:<cffunction name="verifySSL" access="public" returntype="void" output="false"> <cfargument name="event" type="ModelGlue.Core.event" required="true" /> <cfset var qry = "" /> <cfset var xe = "" /> < !--- this request requires SSL, if not, redirect back to itself ---> <cfif NOT cgi.server_port_secure> <cfif arguments.event.argumentExists("varsToForward")> < !--- build a query string to pass along ---> <cfloop list="#arguments.event.getArgument("varsToForward")#" index="ii"> <cfset qry = qry & "/#ii#/#arguments.event.getValue(ii)#" /> </cfloop> </cfif> < !--- we might want to redirect to another event (in the case of a post/etc, back to the form) otherwise we just forward back to the same event ---> <cfif arguments.event.argumentExists("xeToForward")> <cfset xe = arguments.event.getArgument("xeToForward") /> <cfelse> <cfset xe = arguments.event.getValue("event") /> </cfif> < !--- force SSL ---> <cflocation url="https://#arguments.event.getValue("globalConfig").getConfigSetting("WEB_SECUREHOST")##arguments.event.getValue("myself")##xe##qry#" addtoken="no" /> </cfif> </cffunction>
Notice that I’m getting my SSL host out of a Coldspring config bean but you could either hardcode your hostname or use a CGI parameter. Now the page redirects to the target event using SSL and passes the named parameters. Perfect!
Resources Today
- Using viewState.getValue(“fieldNames”) to populate beans. This is a simple trick but very cool – the fieldNames parameter is still available when a form is submitted meaning you can loop over it to dynamically set values in a bean.
engtech said:
on January 22, 2008 at 8:32 am
congrats man
I proposed a month ago
welcome to brokesville