Inspiring

Answered

DW Extensions: What, Where, Why, How?

Forum|Forum|8 years ago
September 15, 2017
3 replies
2464 views

It seems there is more than one meaning for "extension". The one I want to discuss: files an individual DW user creates, fills with code, and places in a dedicated folder, in the case of Macs and the latest DW:

~/Library/Application Support/Adobe/Dreamweaver CC 2017/en_US/Configuration/Commands/

These are usually in HTML--JS pairs, e.g. Extension1.htm and Extension1.js, containing --respectively-- the initialization and the implementing JavaScript code for what the extension does. This results in the DW menu item

Tools-->Commands-->Extension1

which activates the extension. It has full access to the DOM of the current file, so all sorts of transformations are possible.

Q1: What's the definitive, unambiguous description for this kind of extension?

- - -

I write extensions for complex tasks that I do often in my workflow. For example, the built-in tool

Tools-->Clean Up Word HTML

only does part of the clean-up I want to do, so I wrote a variant that does what I need.

This capability is vital to my workflow!

- - -

When I debug extensions, I edit the extension files in the above-named directory, then I use a command hidden in the "insert" palette that reloads all the extensions in that directory. (In recent versions of DW CC, doing this causes my DW to crash. The only workaround I can think of is to quit and re-launch DW to trigger extension loading.) Then I activate the extension and see what happens. Sometimes I trigger Alerts in the code to tell me what's happening. Rinse, Lather, Repeat. Classic printf debugging.

Q2: Is there an alternative development flow?

Q3: The ExtendScript Toolkit (4.x) is an extended-JS debugging environment: Is it capable of debugging DW extensions as defined above? If so, how is this initialized?

Q4: Or, ...what?

- - -

Q5. Are there any web forums or similar resources specifically supporting this kind of DW extension development?

TIA

This topic has been closed for replies.

Correct answer lnayal

pziecina:

Thanks for your reply.

JS standards, right. In general, I'm strongly supportive of industry-wide standards, but we are talking about two entirely different environments -- I don't feel strongly that DWs internal engine must necessarily track those of browsers. (When I get time I'm going to try to find the specific incompatibility I believe I recall in the search and search-replace functions.)

Sign up for pre-release. OK, I did, downloaded CC2018, and launched it. The first item I checked was the "hidden" extension reload. Yes, it crashes. (Well, the first UI event following that, directed at DW or at the Finder, results in DW crashing.) So now I can submit a bug report that is somewhat more likely to get attention.

And, as you suggest, now I can ask the pro extension developers if they have encountered this hidden re-load issue; if not, why, if so, any workaround? So... how would I actually do that?

The vibrant days... OK, I get it. I arrived roughly at the time of the last Macromedia release. It is a shame all the history from those days was lost.

Validation. Thanks for the advice. I didn't want to hijack this thread to discuss validation. I'm doing some research about my issues and --if necessary-- I can start a new thread. There is a connection: to take care of some setup and after cleanup, I invoke the validator through a command extension. I need a working extension dev environment to track validation evolution. (Turns out I have DW CC 2015.2 still installed. It does not crash when I hit the hidden reload extension command so I have an interim working extension dev environment.)

Documentation updates: yes, I agree, there are all sorts of good reasons to keep the documentation current. One of them is sending a message to non-commercial extension user/developers that Adobe understands the importance of these. Another: the process of building/maintaining high-quality docs reflects back on the engineering and can result in higher quality work. Well, ideally.

Thanks,

Henry

Thank you Henry for reporting this issue. This issue is there with DW 17.5 also on Win and Mac both.

We have logged a bug in our system for this.

We will prioritize this for fixing.

Please let us know if you face any other issue with DW.

-Lalita

lnayal

Community Manager

Hello Hen3ry and others,

We have fixed crash with "Reload Extensions" with our upcoming build which is beta state.

Below is the link to access our pre-release portal and try fix at your end.

Adobe Prerelease

Thanks,

Lalita

pziecina

Legend

Just a few points before i forget.

If you use your method to 'install' extensions, any dot updates to Dw you install will overwrite your extension.

Any extensions you create without creating an extension package may conflict with newer versions of Dw, effectively rendering them useless, as there is no documentation or reference to them as an extension.

As an example, i created an extension for adding css flexbox/grids/multi-column layouts to Dw's css designer, but if Dw itself adds any of these items my extension will conflict with the Dw implimentation, so you have to check everything before installing any extension in a new version, (will never release the extension to anyone else).

hen3ryAuthor

Inspiring

Pziecina:

Thank you very much for your response!

Would it be OK to adopt the term "Command Extension" to describe the result and procedure I use?

- - -

I've been doing this a while -- I don't claim to have carefully kept track. Just did a quick look: My earliest work I found on a Command Extension is 2009. (What version of DW was current then?) I've never had any problem corrupting DW. If I recall correctly the worst problem: occasionally, I'd botch something in new work and produce an extension that failed at DW launch extension-load time, or at hidden-command-load time. DW would Alert about this, I'd remove the extension, reload extensions, and normal operation was restored.

In general, after every major version update of DW, I copy my extension work files from

~/Library/Application Support/Adobe/Dreamweaver OLDVERSION/en_US/Configuration/Commands/

~/Library/Application Support/Adobe/Dreamweaver NEWVERSION/en_US/Configuration/Commands/

That's definitely quick-and-easy. Almost always, as I recall, my Command Extensions functioned in the new version exactly as before.

Looking at the example you give of adding an additional function to DW's CSS Designer, I can see how an extension of such sophistication might conflict with new DW features. I think because I'm creating very simple extensions which only result in adding additional items to

Tools --> Commands

and do not modify any other function or dialog/palette --some are "headerless", change nothing visible at all-- I'm at much lower risk of conflicts, essential zero. What do you think?

How does making an extension package and installing it via an extension manager reduce the risk, especially as the extension manager itself is a 3rd party product? Can that a 3rd party vendor anticipate the kinds of conflicts that might occur?

- - -

You advise that I not use the ExtendScript Toolkit. I'm OK with printf-style debugging. I'd be OK with an actual breakpoint-and-examine debugger too, if one exists and reproduces the full Extension environment and the data state -- the DOM of the current file. Maybe I'm simply ignorant of how to make a typical (or a specific) DOM available in an external debugging environment like VS Pro. (Please provide a link so I can take a look at this product). Maybe I'm unreasonably fearful of potential differences in DW's JS implementation versus some other environment. Or does VS Pro use the same JS engine?

One key reason I considered using the ExtendScript Toolkit is the hope that it provides a work-around to the problem I noted my OP: for almost a year now, DW crashes whenever I use the "hidden reload". (By the way, this problem was confirmed 10 months ago by a user on a PC-based DW release.) I hoped that using ExtendScript Toolkit would be a work-around.

Anyway, I simply cannot figure out how to get the ExtendScript Toolkit to connect to the DW JS engine, so I cannot debug an activated Command Extension.

- - -

About submitting my extensions to the Adobe Exchange: it would be GREAT if my extension work would be helpful to someone else! I'd be glad to share, but I doubt this is practical. My extensions are all to support my workflow, which I think is very different from what most people use.

- - -

You advise avoiding the dedicated DW extension forum. OK. I gave up on that sub-forum many years ago. There hasn't been much traffic on that, and what little I found wasn't very relevant.

- - -

About documentation: In this particular case I'm not so concerned that the documentation doesn't show recent dates. This is a basic, original, and truly vital Dreamweaver function –supporting user customization– and I'm happy that this function is being maintained and will apparently continue on in the future. It's a brilliant design, and such things aren't easily improved.

I do wish there was some kind of active community, somewhere. I assume the 3rd party vendors have their own network, one that doesn't mix well with individuals writing non-commercial extensions.

Thanks,

Henry

pziecina

Legend

Hi Henry,

you can call the extensions you create, whatever you wish, and 'command extensions' sounds good to me.

Creating an extension package, (zxp) would ensure any load problems would just give you a warning at run time, and cause no problems otherwise. The main problem in doing so is that adobe no longer produces an extension manager for Dw, and this is required to create the extension package.

The 3rd party extension managers work just as the adobe one would, if it was available, and are produced by dedicated and very experianced extension providers, (dmxzone and project seven).

Given that you do not plan to distribute your extensions though, your method of installing is probably sufficient, and as you do know what you are doing i cannot see any real problems, but if you ever plan on doing anything more complexed it would be worth learning the correct method.

Now to the js, Dw used to have an 'hidden panel' js watcher for monitoring js during extension testing, but unfortunatly this vanished along with many other features after CS6. If you know how to use a browsers dev tools, (js debugger) then you can test your javascript using this. The only reason i mention VS is that the debugger it uses is the one i use, (i have the program, so i use it) but any good debugger will do. There is a debugger in Dw2015, (have not checked 2017), that can be enabled by starting Dw from the command line, (sorry dont know the mac equivalent).

The extendscript toolkit is for extending 'other' adobe programs, not Dw, (don't ask me to comment).

There is a long story about the decline of personal Dw extensions, and all the blame can all be placed on adobe and it's lack of understanding regarding Dw in the last 7 years. No matter what you do, do not submit an extension to adobe for inclussion in its exchange, as i can guarantee it will be more trouble than it is worth, and that is not just my opinion, but also that of extension developers who actually make their living from creating extensions.

Hopefully Preran will provide more information about updated documentation for the creation of Dw extensions, as without this we are all working 'blind' so to speak. A few people in the Dw pre-release have created extension and both dmxzone and project seven also ocassionaly take part in the program, though if they would give away 'trade secrets' is another question, but that may be another route you could try to find out more, as currently i am the only one in this forum, (as far as i know) that has created extensions.

Maybe a member of the dev team will join in with more info that will help you, but with the next release of Dw only weeks away, that is unlikely.

pziecina

Legend

Had you asked this question 5/6 years ago the answer would have been much simpler.

Answer then - An extension is any file with the mxp/zxp file extension installed using the extension manager.

Now it is not so simple, for one thing Dw does not have an extension manager unless one uses a 3rd party product. Users have to download extensions from Adobe -

https://helpx.adobe.com/dreamweaver/using/extensions.html

Many users will follow the procedure you are using for making extensions work in Dw, which personally i do not recommend as it is very easy to corrupt the Dw installation using that method. The other problem with it is that Dw in its 2017 implementation has not just a large amount of unused files/folders that are left over from old features that no longer work, it now includes files/folders from the Brackets code editor which do not conform to the Brackets method of installing or even writing extensions.

There was talk of updating the documentation for creating extensions for Dw, but I have not heard any information on the subject for months, more info may be available in the Dw pre-release program if you ask there, (Preran could you ask if any new info is available please? thank you in advance).

Now, having written all that, what was your question .

Do not use the extend script toolkit to debug your js. I know this sounds odd but it is not the best tool for extending Dw, (in fact it is not for extending Dw) i use VS Pro to debug the js and Dw for the html, but whatever you use it is important to remember that the final files you wish installed should be made into an extension package and installed via an extension manager to prevent corruption of the actual Dw installation.

It is also possible to submit your extensions to the Adobe exchange for instalation via the cloud, but this is not a method i personally would recommend, as not only does it take time for the extension to appear in the exchange, it is limited to a small number of free submissions, (5 or 10) and they are available to everyone as there is no personal folder.

There is a dedicated Dw extension forum as a sub-forum to this one, DO NOT USE. I and a few others used to answer question in that forum, but most if not all those who helped in that sub-forum have left, and i never look at posts in that forum anymore. The reasons for that turn of events are various, but the lack of updated documentation for creating extensions, (the newest is for CS 5.5, that was 7 years ago before CC and before the extension manager was dropped by Adobe).

The problem with trying to answer questions regarding how you should create extensions for Dw, are given above and until there is better documentation, and an easier method of installing them, (officially) I cannot provide a clear workflow or reference any up-to-date methods for creation, but if you do have further questions please remember to post in this forum, (not the extension sub-forum) and i will try to help if i can.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded