> Hi Isaac--thanks for clarifying. I misunderstood what you > meant by "yields no noticeable advantage" so my apologies > if I was off-base on that point. We've discussed the "XML > for XML's sake" issue before and while I probably agree > that the Mach-II config doesn't necessarily HAVE to be XML, > I guess I don't see it as that big of an issue; it's a way > of organizing data that IMO makes it pretty easy to read > and deal with, and XML certainly can be dealt with > programmatically too, but there are many ways this > could be done.
Yea, it is or isn't an issue almost entirely based on how your mind works around problems, which is a really individualized thing. The blog entry does also mention the fact that xml can be edited both programatically and by hand, however, I think it's important to remember that xml is easier for a human to edit than it is for the software to update, since the software has to convert it into native variables, manipulate those and then convert it back to text, whereas a human just edits the text. And of course, an xml document also introduces new namespaces which is another area where namespace conflicts can occur. XML Namespaces could theoretically be used to limit this as a possibility, however, I'm not sure if a namespace could be applied to the list of listeners for instance to accmplish this. When you're editing the config file by hand, it's not such an issue, you can rename the listener however you like and then go rename all the references to that listener in your new event-handlers for an add-on component. But if you're wanting to write an installer that will handle adding components automatically without requiring someone to manually edit the config file, it's a whole other ball-game. The installer has to first determine if a listener with the desired name already exists in the config, then it has to determine if it's the same listener (so it doesn't duplicate itself), then if a conflict exists it has to figure out how to rename its own listener and update all its references to that listener. If you've got an event-handler name conflict, forget it, 'cause even after changing the name of the event the installer's got to be able to track down and update any CFC methods that announce that event. I suppose if push came to shove I could add a property to the framework and use that property as the event name in references to announceEvent() (which I probably would have named eventAnnounce() in keeping with structure and array functions heh :) but then I absolutely can't have any name conflicts in the properties section, and it still seems like a big challenge to me. This also becomes another advertisement for descriptive variable names. I guess I may be a bit unusual in wanting the user-experience for installing modular application components in a scripted application to be similar to the user-experience for installing browser plugins for instance. When you install Flash into IE you don't have to do any programming to make that happen, it's all done for you. I want my scripted applications to work the same way "out of the box". No more of this readme.txt step 1) edit the application.cfm blah blah... > Personally, I like having all that functionality in the > config file as opposed to a more automated way of doing > things. The advantage of course of having a lot of the > information in the config file is that I can leave the > CF code exactly as is (e.g. index.cfm?event=doSomething), > go into that XML file and change the implementation of > the "doSomething" event and the code will automatically > pick that up the next time someone calls that event. You're still writing code tho, and that's my real issue. ... I wish I had a really good comparison actually... speaking of which -- if you don't mind terribly, could you send me (in private email) a snippet of a mach-ii.xml file where you've been able to make a significant change easily? (With a description of the change of course.) I'd like to compare it against what I know of Fusebox and onTap -- but I don't really have a frame of reference right now for an "in the wild" situation that Mach-II is well suited for. If I can come up with some good comparison(s) I think I might even write a 4th artcle with "just the facts" about a given functional modification (or a few) and what is required to accomplish it in each framework. > I personally really like the fact that I can make a > very small change in the XML file and completely change > the behavior of the application, and I like > the flexibility the setup offers. > Sorry if my tone came off as heated--that wasn't my intent > but I realize in re-reading it that it may have been a bit > more abrasive than I intended. Ooops! Sorry... when I said "less heated" I meant less so than my blog and my article -- I realize that both of them are somewhat abrasive and not complimentary to the framework. I won't pretend to be a master of diplomacy. :) > As you mention, in the end this all of course boils down > to personal choice, and I still plan to check out onTap > when I have time (I promise!). At the moment having been > through 2 projects with Mach-II, which is an admittedly > small number, I've just had a big grin on my face every > time the client has what would have been a major change > and I can do it in a matter of minutes. I'm sure this > positive emotional reaction has probably swayed me but it's > also saved me so much time I can't help but love it. As I > work with it more I may discover things about it that annoy > me, but both the Mach-II projects I've done thus far have > been pretty darn smooth compared to some previous experiences. Well, you've had more experience with Mach-II than I have. I haven't gotten to the point yet where I've actually finished a complete application with Mach-II, and so my opinions are obviously "first impressions". I'm sure I will end up writing at least one retraction of something I said about Mach-II at some point. What I'll retract we'll just have to wait and see. :) > I just looked at your blog entry as well, and I think much > of what you say there also boils down to personal preference. > I see your point about automating some of this, but it's a > trade-off: with automation you give up a certain degree of > flexibility; with no automation you do more typing. I > prefer the latter myself, but I certainly see your point. I've always been a big fan of the idea of making a decision to do something in a "standard" way and then allowing that standard to automate the workload. File naming conventions is a good part of that. One of the things I dislike about Fusebox is that in spite of having file naming conventions, there's also no automation in that framework. So at this point I feel much the same way about the "busy work" of writing fbx_circuits and fbx_switch files (FB3) as I do about Mach-II's xml config file. > Another "bottom line" on all of this is the usual "use the > right tool for the job." I wouldn't use Mach-II (or probably > any other framework for that matter) for a horrendously > simple application that needed to be done extremely quickly. > Those are usually bad projects from the outset however; > they're never as simple as they seem, and you pay for > quick coding later when things need to be changed. But, if > such a project did exist, then Mach-II is probably a bit > heavy-handed. As those "simple, quick" projects grow into > larger, more complex projects, however, I've found that > Mach-II keeps things almost comically flexible, which in > my mind is a darn good thing. More work now, less work > later is the way I look at it. My dad used to have a t-shirt or somesuch that said "inside every small program is a big program trying to get out". :) Which I think is really appropriate. You're right, I think most of the small projects I start into end up being a lot larger than I expect them to be, and largely for that reason I think I'm more likely to use a framework even on a smaller project in antiscipation of growth. Imho it's better to have it and not need it than to wind up wit a mess of linguine (my code is wide and flat rather than round. :) and having to try and bring some sense to it or backward-engineer it into a framework or at least some semblance of structure. > Good discussion--thanks again for getting it rolling. I'm glad there seem to be some good things coming of it. :) I've been kind of "preparing myself for the worst" and it hasn't happened. At least not yet. :) s. isaac dealey 214-823-9345 team macromedia volunteer http://www.macromedia.com/go/team chief architect, tapestry cms http://products.turnkey.to onTap is open source http://www.turnkey.to/ontap ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
