Adobe Forums: Extendables: a framework for Adobe ExtendScript

Stijn DebrouwereCalculating status...

Currently Being Moderated

Extendables: a framework for Adobe ExtendScript

Nov 1, 2010 6:08 AM

Howdy folks,

New here, but I come bearing gifts. I've just open-sourced Extendables, a small framework that simplifies ExtendScript coding. Check it out at http://extendables.org and the documentation at http://extendables.org/docs/.

Extendables isn't a whiz-bang does-everything-for-you kind of framework, but if you're doing any serious scripting, it will definitely make your life easier. It includes some of the newer Javascript 1.6+ Array methods like forEach, useful shortcuts/monkeypatches and modules for logging, HTTP connections and creating user interfaces. Plus a bunch of other stuff.

With the rise of server-side Javascript (you might've heard of node.js, Narwhal or Rhino), there's a growing number of libraries and frameworks out there which don't depend on a browser to work, so the timing felt right to tap into that ecosystem as well for our own profit. For example unit testing is provided by a slightly tweaked Jasmine, which is a great DOM-less Javascript testing framework.

Do note that this release is halfway between a teaser and a working product. Some parts aren't feature-complete, like the HTTP library. Other parts are experimental. There's no common style yet. The UI helpers have a domain-specific language vibe and so does the unit testing library. The HTTP library and a couple of other parts work entirely getter/setter-based (think jQuery). But in other parts I've tried to stay close to how ExtendScript works out of the box, so that it'd feel intuitive for long-time scripters.

It's pretty stable, but I've only been able to test it out on my own system (InDesign CS4 — that's all I have a license for), so I've labeled it an alpha release regardless.

If you're up for that, do feel free to contribute via GitHub, either by helping to flesh out the core framework, by reviewing the documentation or by making your own module packages. There's already a lot of collective wisdom and code snippets out there, and it probably wouldn't hurt to bring some of that together and release it as proper packages.

I guess what I'm saying is: try it out, skim through the docs, let me know what you like, don't like or would like to see. I'd be happy to keep in touch with any tester over Google Talk, mail or IRC, to help sort out any inevitable kinks you might encounter.

(I've put up a similar message over at my blog, but feel free to continue the conversation over here.)

Currently Being Moderated

[Jongware]-GfBROo,

Community Member

Nov 1, 2010 6:14 AM

Report

Hi Stijn, and welcome to the party!

(Your extendables.org links return a 502 for now, but that may get fixed automagically.)

How does this work? I mean, not down to the nitty gritty internal details, but in practice -- is this a replacement for the system-wide Javascript parser? Can I write my scripts as usual, save them into ID's Scripts folder, and run them from within ID?

|
Mark as:
Currently Being Moderated

Stijn Debrouwere,

Community Member

Nov 1, 2010 6:26 AM

Report

Yes, a little DNS issue that should magically disappear soon :-)

Extendables is actually a framework or a library, depending on how you use it. If you just include the extendables.jsx file at the top of a script, you get a bunch of extra methods on top of existing object prototypes (like String, Array, ...) and a couple of libraries you can load in using var lib = require("thislibrary"); So you don't need to change existing scripts: you just get a bunch of extra stuff that's there if you want it, or that you can ignore if you don't.

But you can also create your own libraries/modules, and those do need a certain directory and code layout to get picked up by Extendables. Modules serve mainly to be able to separate helper libraries from your actual script, and to be able to load those libraries using require(). The advantage to modules is mainly that you don't have to pollute your global namespace, because require() puts whatever functions and variables you make available inside of your module into a variable, whereas with #include, you never really know what you're getting unless you check the included file.

Hope that helps.

Stijn

|
Mark as:
Currently Being Moderated

Harbs.,

Community Member

Nov 1, 2010 6:53 AM

Report

Hi Stijn and welcome!

Nice work!

I've actually been doing some work myself recently on converting my personal UI library into something which can be consumed by the general public. Mine is more geared towards increased functionality and ease of creating standard elements. It's not as fine-grained as what you've done.

Harbs

|
Mark as:
Currently Being Moderated

michielvoo,

Nov 1, 2010 7:24 AM

Report

JavaScript 1.6+, DOM shortcuts, CommonJS-type namespaces, unit testing, UI library... this framework seems to have all the right ideas!

Thanks!

|
Mark as:
Currently Being Moderated

Stijn Debrouwere,

Community Member

Nov 1, 2010 11:18 AM

Report

Thanks Michiel and Harbs!

@Harbs: that's right on the money, the Extendables UI library makes UI development a little easier and faster, but its main purpose is to get rid of messy code that intermingles structure and presentation. I'm curious to see what you come up with.

|
Mark as:
Currently Being Moderated

Peter Kahrel,

Community Member

Nov 1, 2010 1:10 PM

Report

Nice work, Stijn!

Peter

|
Mark as:
Currently Being Moderated

Marc Autret,

Community Member

Nov 6, 2010 6:28 AM

Report

This is an amazing and huge project!

Thanks for sharing :-)

@+
Marc

[ Question: how behave Extendables' conditional #include directives when compiling a project as .jsxbin? ]

|
Mark as:
Currently Being Moderated

Stijn Debrouwere,

Community Member

Nov 6, 2010 9:05 AM

Report

Hi Marc,

Thanks! I tried to mail you earlier in the hopes you'd have some time to put up a short message on Indiscripts, but my message got rejected as spam so I guess that never reached you.

As it happens, I've been thinking about how to do jsxbins for larger projects, and for Extendables-based projects especially. #include statements are not be the biggest problem — require() and extract() statements probably are. I guess that's the drawback of the module loader system.

I've been working on a Python script that inlines every last bit of code, producing a single (huge) file that would contain Extendables, any other packages plus your own script files. It works by replacing every include, require and extract with the files it actually loads, as well as by expanding certain variables like $.fileName. Once you have that file, you can easily run it through the Google Closure Compiler and/or make a jsxbin out of that. I'm thinking of open-sourcing that script, though I'm still in doubt — I do have to make some money, after all :-)

|
Mark as:
Currently Being Moderated

Marc Autret,

Community Member

Nov 6, 2010 9:25 AM

Report

Hi Stijn,

Sorry for the rejection of your comment: Indiscripts spam filter is probably too harsh -- although I still get a lot of unfiltered ads...

Let's continue the discussion by email...

@+
Marc

|
Mark as:
Currently Being Moderated

Loic_aigon,

Community Member

Nov 7, 2010 3:09 PM

Report

Hi Stijn,

I can't wait to give your framework a try. I was getting sick using ESTK

As others pointed out, thanks for sharing you very expected project !

Loic

|
Mark as:
Currently Being Moderated

Marc Autret,

Community Member

Nov 10, 2010 9:47 PM

Report

First try here:

http://www.indiscripts.com/post/2010/11/my-first-extendables-script-fo r-indesign

(Unicode Character infos box using the Extendables' http library.)

Cool!

Marc

|
Mark as:

Currently Being Moderated

Krishna V,

Dec 7, 2011 7:31 AM

Report

Hello,

I have been trying to use this framework with Indesign, but I am unable to get it working. I will appreciate your help on this. Below is the code that I am trying.

So far, what I have understood is that this framework does not work with any authentication parameters and I think I have seen some where that it's not yet implemented. Is that correct? If so, could some one help me on how would I be able to get this working?

Thank you so much for the help.

Indesign code:

	var auth=new Object();
	auth.username="admin";
	auth.password="admin";
	var auth = { username:'admin', password:'admin'};
	var response = http.get("http://localhost:4502/content/geometrixx/en/company/news/articles/jcr: content/par/text.html",auth,5);


	alert(response.body);
	if (response.status_code == 200) {
	alert(response.body);
	} else {
	alert("Connection failed");
	}

Result:

It fails at the runtime by pointing the ExtendScript debugger at the line number 137 in object.conversions.jsx. The line 137 is : throw RangeError("This method cannot convert from {} to {}".format(this.prototype.name, type));

Mark as:

Currently Being Moderated

Stijn Debrouwere,

Community Member

Dec 7, 2011 7:39 AM

Report

Hey Krishna! Thanks for giving Extendables a try. That code looks correct. Could you file a bug report at https://github.com/stdbrouw/Extendables/issues? It'd also be very helpful to know what version of InDesign you're using, because that can make a big difference.

|
Mark as:
Currently Being Moderated

Krishna V,

Community Member

Dec 7, 2011 7:54 AM

Report

Cool, thanks. I have just seen your post already there as a feature request. I did reply to your post and also added a new issue too. Also, I want to know when this will be implemented and do you know whom do I need to talk to on this?

Thanks so much for the help,
Murali

|
Mark as:
Currently Being Moderated

Stijn Debrouwere,

Community Member

Dec 7, 2011 7:59 AM

Report

Honestly, I don't know. It would probably be a quick fix and I intend to do a round of bugfixing at some point in the not-so-far feature, but I'm currently not doing any InDesign scripting professionally, so it's kind of at the back of my list of priorities. Sorry.

Stijn

|
Mark as:

InDesign Scripting

Extendables: a framework for Adobe ExtendScript

Nov 1, 2010 6:08 AM

More Like This

Bookmarked By (0)