Great post man, and it really touches on something that I don't think enough people really concentrate on.
Application VS. Web Site. I haven't ever worked on a web site other than some little dinky side stuff. I write mission critical applications, often classified, that are used by government, law enforcement and the military. I also don't think some people realize the size and scope of these applications, and just how much complexity can be required in a single page request. For me using a framework isn't something I do to be cool, it's the only way I have of providing sanity for myself while debugging, fixing errors, conduction maintenance or adding new functionality to an already existing application. It saves, not costs, time and money in the long run. Something that seems to also be a problem for a lot of junior developers or graphics people, is the simple fact that to stay cutting adage as a programmer, you must be constantly doing professional development, constantly learning the new platform, application server, design pattern, or technology. For the designer guy: You want to continue getting raises and promotions? Learn about "web based applications". Learn about frameworks. Learn whatever you can. -- Timothy Heald Analyst, Architect, Developer [EMAIL PROTECTED] W: 202-228-8372 C: 703-300-3911 -----Original Message----- From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] Sent: Saturday, April 08, 2006 1:17 PM To: CF-Talk Subject: RE: Newbie Model Glue Questions > It still all boils down to one simple thing for me. > Tame something very simple, a web page And make it ridiculously > complicated by turning it into an object oriented application. I don't work on or with web pages. I haven't worked on or with web pages in many years. I work on and with applications. The fact that the medium is web is a matter of expedience. > You can't just open a page in dreamweaver anymore and edit it, you > have to go through the code and find the part that generate the > content and edit that. Which makes life very hard for the web > designers. I'm not a designer. If I were to provide a means for designers to contribute to my applications, it would be in a CMS, wherein a designer could certainly quite easily open a document in Dreamweaver, edit it and then paste the html into the application. Mostly I work on applications that don't have lots of "design" in the traditional graphic sense -- they have interaction design which is quite a bit different and deals with the manner in which users accomplish tasks, not the attractiveness of the page. > There is just no reason to do this as far as I can see. You probably work on a very different kind of web than I do. > A very simple framework does the same job as as complex one like > model-glue, except it's more accessible to more developers, easier to > understand, faster to use and a better ROI. That depends entirely on the project in question. > We recently tried out Model-glue and built a test site using it. It > now takes 10 times longer to maintain this site or make changes than > it would have done if it was using my framework. The original > developer liked it as he comes from an OO background. I then gave the > task of applying style and layout to another developer, and she had a > mess of a time trying to work it all out. That's not nearly enough information for anyone to make a viable judgement about the situation. It could be that the application didn't need OO because it was just a simple brochureware site. It also could be that it was a genuine extranet application which really needed some structure to make it maintainable in the long-term and that this is a scenario in which the designer needs to stretch herself (or be replaced) for "the greater good" of an ongoing project. Without knowing what the application is doing I can't make any viable judgements. > So great if u like these type sof frameworks, but really, don't expect > everyone else to. Then everyone else can have the scraps that are left over after developers who've taken the time to stretch themselves have taken all the best jobs. It's really that simple. > It's just using CFC's to create an OO type environment just for the > sake of it. That depends entirely on the project in question. A 5-10 page brochureware "web site" doesn't have any significant need for the encapsulation and extensibility of OO tools, because all it does is display some content on the web. I don't work on those sites. Most of the time when I answer questions for people on this list or in instant messengers, on the phone, in person, I'm not answering questions about those sites or the tasks associated with those sites. Why? Because the people I help are programmers, not graphic artists, and the mechanical programming aspects of those sites are easy, hence, there's no need for people to ask me questions about them. There are however a vast number of people in the ColdFusion community, as in any dynamic content server platform community, who work primarily on intranet and extranet applications. This is the larger programming world I'm involved in. In this world, nearly without fail, some OO encapsulation is a significant benefit to our applications. If all my intranet or extranet application did was mirror a public brochureware site, you'd be right, but then I wouldn't be making much money either, because my clients would just be hiring their neices and nephews who know how to use photoshop. They hire me because I know how to do things that other people don't, like modeling a database, creating complex SQL queries and generating RSS feeds that newsreaders won't reject. Part of that set of specialized skills includes the application of techniques like OO for improving the extensibility and maintainability of complex applications. Here is just one example of the kind of applications the vast majority of my jobs have involved: Site Manageware: an ASP extranet application for the residential real-estate market. The application manages a complex set of inventory including peripheral sales (parking spaces, boat slips), and upgrades (marble countertops, solid wood cabinets) and 3-dimensional maps of properties (placement of units on the property), mostly for high-rise condominiums. In addition to the inventory the application manages the sale process from start to finish including marketing campaigns (demographic tracking), price adjustments (oh my god do these get insane), downpayments, contracts/signings, closings and sales commissions (which also means the application required interfaces for managing sales staff). Beyond all of these functional capabilities, like most of the applications I work on it required a complex security layer to ensure that our clients could control which tasks any given employee would be allowed to perform within the application. The problem of residential real-estate was even worse than a lot of other domains because unlike accounting or law, there is absolutely no standardization of the business domain. When I say we managed sales commissions, we did it just barely. We were planning a new system for them when I left. The problem was that the payment of commissions was entirely different for each management company or sometimes for an individual property. One company would pay a single commission after the closing date. Another company would pay commissions in installments with the first commission being due 30 days after the complete payment of the first in a series of multiple downpayments on a property, with the number of downpayments being variable from one sale to the next. The existing system was not OO -- for that matter it wasn't even encapsulated. In order to accomodate such a wide variety of clients, they'd resorted to storing CFML code in a column in the database which would then be written to a file and executed at run-time. It worked, but as I said, just barely. It's unfortunately nearly traditional in the service-provider world for these applications to have been designed and implemented by a small team of less than ideally experienced people, whos background (degree or otherwise) is primarily in an unrelated field (I think in this case it was electrical engineering). The application of course becomes popular with the clients in spite of its flaws and the company grows, adding staff and expanding the application. The bigger problem is that a large and complex application such as this requires a good structure at its foundation to be extensible and maintainable. This application was pretty desperate for structure, but not the worst I'd worked on by any stretch of the imagination. Sadly probably the worst I've worked on was a content management application (not my own) for a fairly simple business domain. Without good structure and encapsulation in the beginning, the larger the application grows, the more apparent it is that its foundation is cracked. What appears to be an innoccuous change on one page will often have unexpected and undesirable results in other parts of the application. The lack of structure makes the application more difficult to test prior to the release of new features -- how do you know where to look for dependancies? (this is one of the biggest issues) Can these problems be solved without using OO or without using a framework? Yes. Site Manageware is proof that they can. But Site Manageware is also proof of something else; that solving them without a good underlying structure and encapsulation (things that frameworks and OO are designed to provide) is a _MASSIVE_ waste of resources. The weak or cracked foundation at the bottom is like trying to build a stack of bricks, 1000 tall and putting a rubber ball underneath the bottom brock. As you add bricks to the top, the only way to keep the whole thing from coming down is to add more support structure (more work) around the outside of the stack. It's far better, if you need the rubber ball at the bottom, to encase it in a brick and build the stack on top of that and eliminate the need for all the extra support work along the outside. Using that brick at the bottom may make it more difficult to get at the ball (holes in the side of the brick, special tools to get to the ball, etc - problems for your designers), but that's going to be less expensive than the alternative. Now lets compare this to the problem you described being caused by a framework; confusion on the part of designers and graphic artists. The work performed by a designer or graphic artist is at best 10% of the whole application. It's true that it will be seen everywhere -- it "dominates the landscape" of the application, however it is primarily cosmetic. I will admit the cosmetic is important however, graphic design is not essential to the function of the application -- the application will work or not (measured by users' ability to perform tasks) independant of how graphically appealing it is. If it's ugly (a failure of the graphic design team), the company endures some complaints about its being ugly. If it doesn't work (a failure of the programming team), the company loses money and potentially folds. This does not make a good argument for making the graphic designer's job easier at the expense of the jobs of the programmers. s. isaac dealey 434.293.6201 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:237248 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
