Re: [AOLSERVER] Dreamweaver ADP hooks Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
It definately looks promising.. :) it could be very nice to have, I will try and find the manual, but when I first looked into it (just after dreamweaver mx came out) they didn't have anything to support MX development, so now some time has passed I think they should be current on support - Original Message - From: Andrew Piskorski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 31, 2003 12:44 AM Subject: [AOLSERVER] Dreamweaver ADP hooks Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions On Thu, Jan 30, 2003 at 07:53:10PM -0700, Patrick Spence wrote: I think with only a little work, someone familiar with making extensions for Dreamweaver could easily code a module for TCL/ADP that works just as well as its PHP application tools.. which would give rapid prototyping and It was done for the ACS 4.x templating system, which of course uses ADP. I don't have the code, but I know for a fact that the Dreamweaver hooks were written, by Jonathan Sefton [EMAIL PROTECTED], who was CTO at one of the aD London office's clients. Here's what he had to say about that, back in October: - Forwarded message from Jonathan Sefton [EMAIL PROTECTED] - From: Jonathan Sefton [EMAIL PROTECTED] To: 'Andrew Piskorski' [EMAIL PROTECTED] Cc: David Fullagar [EMAIL PROTECTED], 'Jeff Davis' [EMAIL PROTECTED] Subject: RE: DreamWeaver ADP hooks? Date: Fri, 25 Oct 2002 20:00:34 +0100 Hi Andrew, Sorry for the slow reply; just moved house been waiting for NTL to hook up broadband, so haven't been checking email very often (forgotten how tedious dial-up is). I don't think I do have the Dreamweaver stuff - Infoshare were pretty strict about returning all s/w on exit. It's just possible I might have it on another machine which isn't unpacked yet. Bear with me and I'll check - might take a couple of days. If I can't find the original stuff, it should be pretty easy to reproduce. It wasn't such a big deal - Dreamweaver has its own XML-based extension mechanism which lets you describe tags behaviours. You just drop the XML files into the appropriate config folders it just works. Macromedia have (had?) a very detailed manual on how to do this; it is (was?) available on their website in PDF format. All the stuff I did was with DW-4. I notice they now have something called Dreamweaver 'MX' - don't know how different that is. We did have some good ideas for more advanced ways to connect Dreamweaver ADP, in particular by using some of the 'page contract' information to build 'palettes' of available fields for the graphic designers to drop onto the page. We also had some ideas for dynamically displaying a complete page within Dreamweaver, i.e. applying all the ADP master and include tags. Incidentally, I assume you're already aware of Nick Strugnell's 'themes' code, which we used pretty extensively on the Infoshare site? That was probably a bigger hit with the designers than the Dreamweaver extension. I'll drop you another email if/when I find the Dreamweaver stuff. Cheers, Jonathan - End forwarded message - - Forwarded message from Jonathan Sefton [EMAIL PROTECTED] - From: Jonathan Sefton [EMAIL PROTECTED] Subject: RE: DreamWeaver ADP hooks? Date: Fri, 25 Oct 2002 22:44:25 +0100 In-Reply-To: [EMAIL PROTECTED] Main Dreamweaver documentation... http://www.macromedia.com/support/dreamweaver/documentation.html For DW-4 you want to start with this doc: 'Using Dreamweaver 4' - zipped PDF: http://download.macromedia.com/pub/dreamweaver/documentation/using_dream weaver4.zip ***Page 537 onwards: 'Customizing the interpretation of third-party tags' This tells you how to define new tags (i.e. the ADP tags) 'Extending Dreamweaver 4' - zipped PDF: http://download.macromedia.com/pub/dreamweaver/extend/ext_dreamweaver4.z ip ***Chapter 8 - This tells you how to create custom 'property inspectors', which let you add support for the attributes of the ADP tags to the DW interface. For example, when you select an INCLUDE tag you get a dialog to modify its attribute(s). Disclaimer: I don't know anything about Dreamweaver MX! J. - End forwarded message - -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
I'd like to know how this turns out. Thanks! -- C. R. Oldham Director of Technology NCA CASI -Original Message- From: Scott Goodwin [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 1:44 PM To: [EMAIL PROTECTED] Subject: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions Hi all, can those of you with Cold Fusion experience please respond to me directly with your opinions on Cold Fusion vs Tcl in AOLserver? I need to make a case for moving a heavy Cold Fusion developer group to Tcl in AOLserver. Specifically I need to convince this group that the pain of the switch is worth it in the long run. I don't need philosophical advice (e.g. Use what you know). I need specific advice on why Tcl/AOLserver is a better solution than CF for web apps. Please reply to [EMAIL PROTECTED] Thanks! /s.
Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
Scott, I'll disclaim that I don't have direct ColdFusion experience, but assuming that your developers are using the current CF runtime, and knowing that the current CF Runtime is a J2EE container, I'm not sure how much good news there is for you. Both AOLserver and J2EE containers use a threading model, and have database connection pools available, so AOLserver's usual advantage is nullified here. Back in the 2.3.3 days, AOLserver would have commanded far less memory than other servers with embedded languages, but because of the way AOLserver has handled Tcl initialization since 3.0, AOLserver thread startup is actually quite heavyweight (either Jim W or Dan S had horror stories about threads requiring many seconds to startup because of the time required to initialize large amounts of Tcl code in the libraries and modules). ADPs would normally be a good rapid development tool with quick turnaround, but JSP offers very similar functionality. On top of that, nobody has any friendly AOLserver/Tcl/ADP front-end design tools, whereas CF was an environment built around the idea. Depending on the complexity of your application, it's entirely possible that the developers can get it going faster, and can deploy it on comparable resources, and with comparable performance if they use CF rather than AOLserver. It is very hard to compete against an app development environment like CF with it's front-end when we don't have even a Dreamweaver behavior that makes life easier, and if you don't do anything like I suggested recently regarding conditional and repeated content, it's really hard to do dynamic page development in anything other than a text editor. Again, from an ease-of-use standpoint, AOLserver has a hard time competing with CF. Now, if the app tests the boundaries of CF, you start to get a fighting chance with AOLserver, because AOLserver has finer-grained APIs, and you can adapt an AOLserver to fit your problem, where, with CF, you'll end up doing more fitting your problem to CF. The problem remains, though, that the CF environment is fairly rich, and unless you're going to OpenACS, AOLserver lacks a lot of the richness (and even with OpenACS, you still don't get friendly development tools -- I don't consider emacs a friendly development tool). If you're going to just try to have a shootout between AOLserver and CF, I think you're going to lose, unless you can mold it to the problem, and show how AOLserver can adapt better and quicker to your problem. Pete. On Thursday, January 30, 2003, at 03:44 PM, Scott Goodwin wrote: Hi all, can those of you with Cold Fusion experience please respond to me directly with your opinions on Cold Fusion vs Tcl in AOLserver? I need to make a case for moving a heavy Cold Fusion developer group to Tcl in AOLserver. Specifically I need to convince this group that the pain of the switch is worth it in the long run. I don't need philosophical advice (e.g. Use what you know). I need specific advice on why Tcl/AOLserver is a better solution than CF for web apps. Please reply to [EMAIL PROTECTED] Thanks! /s.
Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
On 2003.01.30, Peter M. Jansson [EMAIL PROTECTED] wrote: Again, from an ease-of-use standpoint, AOLserver has a hard time competing with CF. Being that I've been developing in CF for years now, including an e-commerce site built entirely in CF, I definitely agree with everything you said that I've snipped above. Now, if the app tests the boundaries of CF, you start to get a fighting chance with AOLserver, because AOLserver has finer-grained APIs, and you can adapt an AOLserver to fit your problem, where, with CF, you'll end up doing more fitting your problem to CF. Even here, CF trumps AOLserver for the most part. We needed a specialized handler for a custom inter-application communication protocol which was XML based. I simply spent a few hours writing a parser and generator that linked to Xerces-C++ and wrote a custom CFX tag in C++ for ColdFusion. IMHO, in 2003, since ColdFusion 5.x introduced UDFs (user-defined functions), CF5 is finally an attractive app. development platform. I am, however, seriously displeased that the next version after 5.x, CFMX, is based on some Java runtime inside a J2EE engine. Very disappointed -- I suspect the quality of the CF server to seriously go downhill after this maneuver. I once started writing a CFML parser and runtime in Perl so I could run CF apps under Apache on Linux (before Macromedia actually ported to Linux). I may do the same thing -- write a CFML parser and runtime in Tcl -- so I could run CF under AOLserver. As I said to Scott offlist, I did write a custom CFX tag, called CFX_TCL, that lets you evaluate Tcl code from your CF app. I'm going to hell for it, I know ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
On Thursday, January 30, 2003, at 09:37 PM, Dossy wrote: As I said to Scott offlist, I did write a custom CFX tag, called CFX_TCL, that lets you evaluate Tcl code from your CF app. I'm going to hell for it, I know ... Time to rewrite it for JACL. :-)
Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
- Original Message - From: Peter M. Jansson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 7:06 PM Subject: Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions rather than AOLserver. It is very hard to compete against an app development environment like CF with it's front-end when we don't have even a Dreamweaver behavior that makes life easier, and if you don't do I think with only a little work, someone familiar with making extensions for Dreamweaver could easily code a module for TCL/ADP that works just as well as its PHP application tools.. which would give rapid prototyping and development right to us. I am surely enjoying the power of the PHP application development under DW/MX and Aolserver, and would prefer to do things in Tcl to reduce memory (stack space especially) and other overheads.. but... I am not brave enough to attempt hacking into dreamweavers extension setup yet.. its just not my area of expertise yet.. -- Patrick Spence arivenATarivenDOTcom www.RandomRamblings.com www.Ariven.com
Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
On Thursday, January 30, 2003, at 09:53 PM, Patrick Spence wrote: but... I am not brave enough to attempt hacking into dreamweavers extension setup yet I'm a GoLive user, so I won't be much help here, either.
Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
On Thu, Jan 30, 2003 at 09:46:41PM -0500, Peter M. Jansson wrote: On Thursday, January 30, 2003, at 09:37 PM, Dossy wrote: As I said to Scott offlist, I did write a custom CFX tag, called CFX_TCL, that lets you evaluate Tcl code from your CF app. I'm going to hell for it, I know ... Time to rewrite it for JACL. :-) Apparently someone's already done something along that line, Gnutsp. At least it appears to be some Tcl parsed pages on top of the Tomcat servlet. http://www.rcreations.com/public/CoDisplayPage,0t,P=5.html http://sourceforge.net/projects/gnutsp/ I've not tried it myself, but might be worth a look. Last release was a year ago, but seems to have very recent CVS updates. -- Tom Poindexter [EMAIL PROTECTED] http://www.nyx.net/~tpoindex/
[AOLSERVER] Dreamweaver ADP hooks Re: [AOLSERVER] Cold Fusion vs Tcl in AOLserver: Opinions
On Thu, Jan 30, 2003 at 07:53:10PM -0700, Patrick Spence wrote: I think with only a little work, someone familiar with making extensions for Dreamweaver could easily code a module for TCL/ADP that works just as well as its PHP application tools.. which would give rapid prototyping and It was done for the ACS 4.x templating system, which of course uses ADP. I don't have the code, but I know for a fact that the Dreamweaver hooks were written, by Jonathan Sefton [EMAIL PROTECTED], who was CTO at one of the aD London office's clients. Here's what he had to say about that, back in October: - Forwarded message from Jonathan Sefton [EMAIL PROTECTED] - From: Jonathan Sefton [EMAIL PROTECTED] To: 'Andrew Piskorski' [EMAIL PROTECTED] Cc: David Fullagar [EMAIL PROTECTED], 'Jeff Davis' [EMAIL PROTECTED] Subject: RE: DreamWeaver ADP hooks? Date: Fri, 25 Oct 2002 20:00:34 +0100 Hi Andrew, Sorry for the slow reply; just moved house been waiting for NTL to hook up broadband, so haven't been checking email very often (forgotten how tedious dial-up is). I don't think I do have the Dreamweaver stuff - Infoshare were pretty strict about returning all s/w on exit. It's just possible I might have it on another machine which isn't unpacked yet. Bear with me and I'll check - might take a couple of days. If I can't find the original stuff, it should be pretty easy to reproduce. It wasn't such a big deal - Dreamweaver has its own XML-based extension mechanism which lets you describe tags behaviours. You just drop the XML files into the appropriate config folders it just works. Macromedia have (had?) a very detailed manual on how to do this; it is (was?) available on their website in PDF format. All the stuff I did was with DW-4. I notice they now have something called Dreamweaver 'MX' - don't know how different that is. We did have some good ideas for more advanced ways to connect Dreamweaver ADP, in particular by using some of the 'page contract' information to build 'palettes' of available fields for the graphic designers to drop onto the page. We also had some ideas for dynamically displaying a complete page within Dreamweaver, i.e. applying all the ADP master and include tags. Incidentally, I assume you're already aware of Nick Strugnell's 'themes' code, which we used pretty extensively on the Infoshare site? That was probably a bigger hit with the designers than the Dreamweaver extension. I'll drop you another email if/when I find the Dreamweaver stuff. Cheers, Jonathan - End forwarded message - - Forwarded message from Jonathan Sefton [EMAIL PROTECTED] - From: Jonathan Sefton [EMAIL PROTECTED] Subject: RE: DreamWeaver ADP hooks? Date: Fri, 25 Oct 2002 22:44:25 +0100 In-Reply-To: [EMAIL PROTECTED] Main Dreamweaver documentation... http://www.macromedia.com/support/dreamweaver/documentation.html For DW-4 you want to start with this doc: 'Using Dreamweaver 4' - zipped PDF: http://download.macromedia.com/pub/dreamweaver/documentation/using_dream weaver4.zip ***Page 537 onwards: 'Customizing the interpretation of third-party tags' This tells you how to define new tags (i.e. the ADP tags) 'Extending Dreamweaver 4' - zipped PDF: http://download.macromedia.com/pub/dreamweaver/extend/ext_dreamweaver4.z ip ***Chapter 8 - This tells you how to create custom 'property inspectors', which let you add support for the attributes of the ADP tags to the DW interface. For example, when you select an INCLUDE tag you get a dialog to modify its attribute(s). Disclaimer: I don't know anything about Dreamweaver MX! J. - End forwarded message - -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
