Jared has posted a Model-Glue DTD...there are a few M-G DTD's floating around, but this is the first I've seen that declared portions of the XML as entities, which can make your life easier. More on using XML entities with Model-Glue can be found on Wayne Graham's blog - it's really quite sweet!
0 comments - Posted by Joe Rinehart at 6:46 PM - Categories: Model-Glue
Yep, I really am working on it! Things have been crazy busy at work - combining that with some renovations and home and my summer cycling habits, I'm a little swamped.
However, there are two new things in the bleeding-edge...one permanent, the other is in there for feedback:
1. Permanent: "append" attribute on the result tag
Ok, so the "redirect" attribute is nice. But imagine this: you commit a new record, then redirect to a read-only detail page for that record. That keeps it from being recommitted if the user hits F5, but the detail page may not know what record to show, because it probably uses a URL parameter named recordId!
Append is optional, and contains a list of viewState values to append to the url. In this case, you could do:
And your the URL redirected to would be "?event=recordDetail&recordId=12345&foobar=foobarsValue"
How's that?
2. Feedback requested: createSingleton()
There's been talk about how configBeans can do a lot more than instantiate configuration: they can be used to instantiate pieces of your model as singletons. However, it may not be convenient, or in your plan, etc. to have to create a .xml file just to a singleton instance of SomeWebServiceWrapper.cfc. Also, you may not want to have SomeWebServiceWrapper conform to the needs of the ChiliBeans workings (get/set, etc.).
To answer this need, I've added a method to the base controller called "createSingleton" (that actually wraps a ModelGlue method called getSingleton). Its signature is the same as createObject, however, it'll insure that you're only creating one instance of that object within a given Model-Glue application.
Some initial feedback has been that it'd be nice of createSingleton() used ChiliBeans to configure your singleton. However, I feel it'd be better to keep configuration out of it, and if you want to do that, you can configure your singleton with a ConfigBean, like so:
Thoughts, flames, objections, praise, anyone?
Minor last note: You'll note that I use createConfigBean() instead of getModelGlue().getConfigBean(). It does the same thing, and while it's currently available in the bleeding edge release, it may not stay.
6 comments - Posted by Joe Rinehart at 6:36 PM - Categories: Model-Glue
I'm sorry if I implied that CompSci courses should teach a "trade" - that's not my point. By all means, I agree with some other posts and comments that it's the concepts that are the most important - they're not going to change, and shouldn't need to.
Where I disagree with CompSci curriculum is that I think there are better ways to teach these concepts than taking an 18-year-old and throwing them into an environment where the technical implentations of these concepts are so full of low-level details that it's too easy to get so caught up in the details of the implementation that it becomes equally easy to miss the concept entirely in favor of memorizing its implementation details. (Yikes, sorry for the blatant run-on.) Sort of like the difference between doing Windows API programming in C or VB.
While I do value the "classic" Computer Science curriculum - the low level things are very, very important! - I also think that the "high level" skills like "design, architecture, and problem solving" could be better learned with higher-level, managed languages. Isn't learning the concepts, and then learning the implementation details a lesson we've learned through design patterns?
I'm not suggesting getting rid of *anything* in Computer Science curriculum - I'm suggesting that we add to it or fork it.
In the end, I see it as a simple math problem. If we keep trying to teach students everything in CompSci from 1970 forward, we're only going to have curriculums that get further and further behind. While there are 1970 concepts that are still very, very important, not everyone studying CS that need to know their details by heart.
3 comments - Posted by Joe Rinehart at 7:49 AM - Categories: Off Topic
So there's articles all over about the slump in computer science enrollment, why it's happening, what to do about it, and blaming it generally on the dot-com bust. This isn't going to be a long post, because I think the answer is easy: update the curriculum already!
I'm not so far out of college, and while I'm not CompSci (actually, I'm Business Management of all things), I took a fair number of CompSci courses. For some reason, I find writing my own linked lists more fun than Advanced Topics in Excel, although that's like comparing overcooked squash to overcooked zucchini.
Shockingly, at my school, Java was a frigging little elective course, treated almost like a toy language. If you weren't C++, you weren't studying Computer Science, and if you weren't taking up C for fun, you were getting a B- at best! It was easier to find a course in assembly that it was to find a course that showed anything about writing a web-base application.
So, let's split the curriculum. If you want to study memory allocation, write your own compilers (or string classes!) etc., by all means - study Computer Science.
However, if you want to write applications in higher-level languages, let's start some programs in Computer Application Development that focus on Java, .NET, ColdFusion, PHP, and all those other rascally languages really peeve those guys who make you feel stupid for not knowing how to use malloc() properly. Let's teach our up and coming students some development skills with which they can hit the ground running, adding business value from day one (or, just wrecking the hell out of everything, but at least in a managed way).
Sure, there's a lot of stuff that those higher level languages gloss over that some lower-level knowledge can help out with, but isn't that what Senior Developers are for? Or are those just the folks that showed up first? However, that's another rant.
6 comments - Posted by Joe Rinehart at 9:35 PM - Categories: Off Topic
4,000 points and a pint to the first person who can do this:
Compile this class:
And then instantiate and CFDump it from within a CF page (CFMX7.0 on J2EE). I get a 500 Null error every time.
Seriously, it'd be a big help. Thanks.
14 comments - Posted by Joe Rinehart at 5:57 PM - Categories: ColdFusion MX
It's looking like Lance Armstrong is going to win his seventh, and while all eyes are on him, I wanted to take a moment to recognize George Hincapie, his lieutenant on the Discovery Channel team, and the only teammate to ride with him in all six of his victories (and hopefully his seventh!).
George finally got what he deserved yesterday: his job was to cover breakaways, and he covered one that got away. Not a climber (cripes, he's bigger than me, and that's _big_ for a cyclist), he hung on to the best of them up a Category 1 and a Hors Categorie climb to the finish, and then won his *first* tour stage ever (out of the 160 or so he'll finish as Lance's teammate).
While he can own in the Spring Classics, every year he turns down large, lucrative offers out of sheer principle: he doesn't ride Le Tour for himself, but to help out his friend Lance.
5 comments - Posted by Joe Rinehart at 7:09 AM - Categories: Off Topic
Man, AJAX keeps popping up! While Google Maps rocks, I've also seen it used to simply submit a form, get submenu items in a DHTML menu, and perform other simple tasks. I've also had people ask me to add AJAX support to Model-Glue (which makes me think AJAX is very misunderstood, give that Model-Glue already supports it!). This all made me think of reasons not to use AJAX.
Now, before I get flamed for bashing the hot technology of the week, please be aware that I'm technology neutral. I think that AJAX is a tool, and you can either build stuff with it, or tear stuff apart. The purpose of this post was to think about a few scenarios in which AJAX may be harmful.
Case 1: It's cool, I gotta use it!
This post on TheDailyWTF.com is a perfect example of "I gotta use it!" All the developer needed to do was run a stored procedure and display a "Yes/No" validation result. Instead, an over-architected AJAX implementation was cooked up that spent so much time managing XML (remember, that's string parsing!) that the experience was much worse than doing a simple post!
Case 2: It's expensive
What? Whaddya mean it's expensive? It's all free!
No, it's not. The code may be free, but how much does the extra time adding this XML layer on cost in development? How about maintenance - debugging and maintaining service-oriented asynchronous system can begin to take up some serious time.
Case 3: I'm not Google
Google's huge. Google's got PhD's coming out of the walls. Google can _afford_ to deliver a high-quality AJAX application like Google maps. I don't have the time or personnel to deliver that application - and I doubt many of the people so hyped up about AJAX do.
Case 4: Have you tried Flex?
Flex rocks, and a lot of the plumbing you have to deal with in AJAX is taken care of. If you're at the level where you have the resources to devote to doing AJAX, and doing it right, Flex is well worth the licensing cost in operational dollars saved by not having to constantly monkey around with low-level transport code and the DOM.
Just a few reasons why I haven't really messed around with AJAX in the past few years.
11 comments - Posted by Joe Rinehart at 6:48 AM - Categories: ColdFusion MX