The CSAW libraries (for InDesign Illustrator, Photoshop, and Bridge), are based on the scripting models of each product. I would imagine that it would be a rather difficult job to create ActionScript classes that would work in the differing scripting models.
If you need generic methods, calling ExtendScript functions might be an easier workaround.
As for other products, you can call scripting function for the ones which have scripting support.
In Computer Science we say all problems can be solved by one more level of indirection . While each product has
different scripting models, why can't a generic base class bridge them via a delegation pattern that invokes the product specific document method
for common properties like document path, document folder etc. Product specific methods can be implemented as they are now I am just
talking about common methods.
com.adobe.product.Document.getDocumentPath() ----> via derived clas soverride will call photoshop.Document.getDocumentPath()
If generic base class is hard to implement how about a common interface to shield us from product specific details when not needed ?
What we need is a generic interface or abstract class that provides gettters for common properties. This is OOPS 101, am I missing something
Again I am not saying this will work fo rall properties just for a few common properties would be a good start..
Oliver @ A
I don't think you are missing something, but I'm pretty sure it'll be a lot of work to implement. We do have a pretty easy workaround (i.e. using ExtendScript when the ActionScript classes don't offer the level of functionality you might want).
It all boils down to priorities. Personally, I would much prefer for the engineers to work on all the bugs as well as add the long list of additional functionality, rather than work on CSAW generality.
If you want this badly enough, you could probably create your own wrapper classes...
You can also call the ActionScript libraries untyped, which will let you use common functions in a way which will work across applications. Though you'd need to do a little application specific work to get the app object in the first place, from there you can type it as an Object and then call anything without compiler errors (though you'll need to be careful to avoid runtime errors for missing functions).
The reason why we haven't created common DOM classes is because, sadly, very little is genuinely identical. For example, while all of the products have a Document.open(...) API, the parameters passed in vary between all of them - and so the signature of this function is different in each. As in ActionScript (and ECMAScript generally) you can only have one function of a specific name, we cannot make Document.open(...) a generic API that would work in all products without effectively removing functionality.
We could add (for example) Document.genericOpen(...) but this feels like it would simply add confusion rather than help matters.
I do realize that parameters can be dfferent for setters or mutators so it doesn't make sense to
abstract them to a common interface.
That said, Adobe should consider a lot of us are writing workflow related tools for Adobe Suite and
just the basic getters on current open document -
document file path
Will go a long way in writing a generic plugin. So again by all means do not abstract out every method
just the basic core methods. Even an open() with a file name would suffice in the interface. More specific
open methods can stay with their product specific class.It would not add confusion as a factory method
could return the abstract class instance but underneath its really the derived class instance that can
be narrowed to if I want more specific function to invoke.
This will allow developers to use generic methods where they can. For the apps we are writing it would be
a life saver. Something to consider for future CS SDK...