There's a lot of talk today in various forums about the value and impact of Contributor for CF (and other web app developers). As I started to say in my previous entry, I think it will take time to sort out the impact not only for the clearly intended audience (folks needing simple content management systems, and developers who previously did updates for that audience), as well as the impact on the content management business (don't know that it will be a category killer, but it could in some segments).
But there's also the question of the impact for general CF (and other web app) developers.
While it may seem that the product is geared toward static sites, it does indeed support dynamic sites (it will automatically lock such server-side code to prevent the user editing it). And they suggested in the announcement conference call that it will change even more regarding that sort of development environment.
But I've been thinking about it in a way that perhaps may seem unorthodox to some. Many may even disagree. I'd also argue that it's possible that many sites that are currently dynamic could be switched to being more static. For instance, many use server-side coding simply to facilitate reusable/moderately changeable aspects of interface design (nav bars, page layout, reusable content segments). While Dreamweaver MX's template feature could be used for some of this, many web app developers prefer to do such things the old fashioned way (in CF, using CFINCLUDE and coordinating the upload of that code themselves). With DWMX, they would need to "republish"
the site whenever they'd change the template, rather than simply changing the included file. And while you could maybe put that power into the client's hands, they would have to have DWMX.
Contribute could change that sort of scenario, bringing the power of DWMX's templating feature to alleviate the page being dynamic just for these reusable components, without the user having to have DWMX.
This doesn't diminish CF's place (or whatever server-side coding one may use). Instead, it limits it to being used only for things that truly are dynamic (database, component, or web server-generated info, for instance). This could have a performance impact by allowing pages that are currently CF (or ASP/JSP/PHP) templates (just for the reusable interface aspects) to be reset to static pages.
But another reason server-side coding is often used is simply to facilitate creation/editing of content in a portion of a page. This, of course, is another thing that Contribute would alleviate entirely.
Still, the current lack of an approval/workflow system will keep some from jumping at the opportunity. It's seems the challenge is how to solve that adequately for all preferences. I can see how that would be a dilemma.
Again, time will tell both in how people find ways to best use it as well as how the product may evolve.
Monday, November 11, 2002
Look into Macromedia's new tool announced today, Contributor
Could I be the first to blog the link to Macromedia's new product announced today, Contributor. Check it out at http://www.macromedia.com/software/contribute/. I'm sure other bloggers will have much more to say. Of course, some will argue that it's not really something related to CF since it's really just a way to facilitate end-user updating of predominantly static sites.
But it could be used with CF sites, and more important there may be aspects of some sites you build in CF that could perhaps be set back to "static" by enabling update access in Contributor. Also, it has built-in ability to lock out dynamic code like CF (which can be disabled if you desire), so in time it will become more clear how indeed even CFers may find it quite appropriate to use.
One thing to note: the price listed on the FAQ page off that site shows it being $99, but it's not clarified that it's $99 for a client installation of Contribute (in other words, for a contributor), but according to a conference call announcing the product this morning, you can "contribute" to any number of sites from that one license. But this does mean that if you want dozens of people to be contributors, they'd each need a license. See the site for more details (which will hopefully answer any questions we'd all have over time)
But it could be used with CF sites, and more important there may be aspects of some sites you build in CF that could perhaps be set back to "static" by enabling update access in Contributor. Also, it has built-in ability to lock out dynamic code like CF (which can be disabled if you desire), so in time it will become more clear how indeed even CFers may find it quite appropriate to use.
One thing to note: the price listed on the FAQ page off that site shows it being $99, but it's not clarified that it's $99 for a client installation of Contribute (in other words, for a contributor), but according to a conference call announcing the product this morning, you can "contribute" to any number of sites from that one license. But this does mean that if you want dozens of people to be contributors, they'd each need a license. See the site for more details (which will hopefully answer any questions we'd all have over time)
Monday, November 04, 2002
Error in precompile.bat printed in my CFDJ article
Gads! Somehow the version of the precompile.bat file that was printed in my October CFDJ article (http://www.sys-con.com/coldfusion/article.cfm?id=519) is missing some important code! :-(
It should be:
As the article indicates, it's just 2 lines, the first being the SET and the second starting with %MX_INSTALL%.
But the printed version was somehow missing the beginning of the second line:
%MX_INSTALL%\runtime\jre\bin\java -classpath
So sorry for that printing mistake!
One other thing I've learned since writing the article is that it seems to fail to work if a directory name or file name being precompiled has spaces in the name.
Update: I've since found another issue with the version offered in the CFDJ. In certain instances it may fail to work, and it turns out that it was the setting the second line above to:
as was shown in the article. It should instead be what I've set it to above:
Turns out that the runtime\jre\bin calls a 1.3 version of the java interpreter, and as of the updater 1 of CFMX, parts of this compile process (when using the -f directive) need the 1.4 interpreter. The corrected line calls the correct one. See my entry of 12/6/02 for more info.
/charlie
It should be:
set MX_INSTALL=d:\cfusionMX
%MX_INSTALL%\runtime\jre\bin\java -classpath
%MX_INSTALL%\lib\cfusion.jar
coldfusion.tools.Compiler -webroot %1
-webinf %MX_INSTALL%\wwwroot\WEB-INF %1
As the article indicates, it's just 2 lines, the first being the SET and the second starting with %MX_INSTALL%.
But the printed version was somehow missing the beginning of the second line:
%MX_INSTALL%\runtime\jre\bin\java -classpath
So sorry for that printing mistake!
One other thing I've learned since writing the article is that it seems to fail to work if a directory name or file name being precompiled has spaces in the name.
Update: I've since found another issue with the version offered in the CFDJ. In certain instances it may fail to work, and it turns out that it was the setting the second line above to:
%MX_INSTALL%\runtime\jre\bin\java -classpath
as was shown in the article. It should instead be what I've set it to above:
%MX_INSTALL%\runtime\bin\java -classpath
Turns out that the runtime\jre\bin calls a 1.3 version of the java interpreter, and as of the updater 1 of CFMX, parts of this compile process (when using the -f directive) need the 1.4 interpreter. The corrected line calls the correct one. See my entry of 12/6/02 for more info.
/charlie
Wednesday, October 16, 2002
Speeding Up Dreamweaver MX: Disable Auto Refresh
Some have noticed that Dreamweaver can perform sluggishly.
One reason is that, by default, it's checking all files in a site (and all subdirectories) to determine if they have changed--and it does this every time you leave and return to DWMX, such as to go read email, edit a word processing document, etc. The thinking is that you may have created or edited a file while outside DWMX. Unfortunately, that "lookup" can cause a painful delay if you leave and return to DWMX often, especially if the site has many files (and subdirectories).
The option is controlled by the feature "refresh local files list automatically", a checkbox in Edit Site>Advanced>Local Info. Turn it off and see if that helps.
You can use the "refresh" button in the site tab to refresh the list. Also, if you expand a directory for he first time since opening the site, that will also obtain a refreshed list of what's in the directory. Once it's opened, though, the file list is cached and only using the "refresh" or restarting DWMX will obtain an updated list (with the "refresh automatically" option disabled).
It's worth clarifying that this is a site-specific feature. You can leave it enabled on one site and disable it on another.
One other comment about poor performance in DWMX in general: I mentioned in my entry of 9/27 ("Getting into Dreamweaver for Studio users") that your machine's performance may have an impact, and in an entry on 8/10 ("Time for developers to consider a hardware upgrade?") I suggested other benefits of considering a machine upgrade.
One reason is that, by default, it's checking all files in a site (and all subdirectories) to determine if they have changed--and it does this every time you leave and return to DWMX, such as to go read email, edit a word processing document, etc. The thinking is that you may have created or edited a file while outside DWMX. Unfortunately, that "lookup" can cause a painful delay if you leave and return to DWMX often, especially if the site has many files (and subdirectories).
The option is controlled by the feature "refresh local files list automatically", a checkbox in Edit Site>Advanced>Local Info. Turn it off and see if that helps.
You can use the "refresh" button in the site tab to refresh the list. Also, if you expand a directory for he first time since opening the site, that will also obtain a refreshed list of what's in the directory. Once it's opened, though, the file list is cached and only using the "refresh" or restarting DWMX will obtain an updated list (with the "refresh automatically" option disabled).
It's worth clarifying that this is a site-specific feature. You can leave it enabled on one site and disable it on another.
One other comment about poor performance in DWMX in general: I mentioned in my entry of 9/27 ("Getting into Dreamweaver for Studio users") that your machine's performance may have an impact, and in an entry on 8/10 ("Time for developers to consider a hardware upgrade?") I suggested other benefits of considering a machine upgrade.
Subscribe to:
Posts (Atom)
