Re: JavaScript in Amaya

Thanks Frederic, Irene, Chaals,

Thanks for the information.

Yes, I realize the issue of editing a document that is being simultaneously
modified by a script. And that Amaya is not a browser but a web editor, that
is exactly how I use if: to build a mesh of connected documents. In fact, a
single document with many "pages" as in a binder.

Thus, I don't pretend to run Gmail in Amaya.

Anyway, a compromise is possible. For example running scripts only "onload",
and/or tagging ad "modified" all DOM elements whose contens was changed by a
script and depict them same as always but read-only with an arrow cursor
pointer instead of the insert point.
This way the more it does scripting, the less it can do edition, under the
control of the document owner.

As of authoring scripts, IMO it is completely a different business than
writing documentation. If it were my project I'd tag it "out of scope" and
instead 'd try to integrate Amaya into Eclipse as a plugin in order to be
able to leverage the already available JS features.

My interest is because I see the need for a documentation system capable of
managing relationships (like synapses) to repace the current "document"
paradigm, qhere "document" is something disconnected, a remain of the
diskette era. Something that can be moved and in the move all links to
related documents break.

After an email by Chaals I did some reading, about Thot, JSR-170 and a paper
by Jonathan Maletic http://www.cs.kent.edu/~jmaletic/papers/tefse05.pdf.
Also looked carefully at Fred's pages.

Now I realize that scripting is for interacting, a different function as
compared to authoring/reading. The difference that exists between an
interactive application and a piece of documentation.
There are many approaches but none seems to get enough traction so I want to
build mine, yet another CMS.
There are hundreds, as one can see in http://cmsmatrix.org/

None complies with the needs I perceive, what would be the "requirementes"
of the software. For example most CMS's focus in high volume publishing
while providing miserable publishing capabilities, or specialised publishing
circuits like for news or the like. As if one were to author using Word and
then "publish" a completely edited document.

In the software design, build, document, revise, fix domain (where I strive)
documents have to be live all around the lifecycle of the system.
Documentation has to be shareable like Google docs but this application is
horrible to work with as it copies the Word paradigm, and does not have a
semantic linking feature. Which is a must. Linking in GDocs is horrible,
Amaya is muc hbetter for linkinf to an anchor in a paragraph inside another
document. As long as that document is opened ...

Maletic focuses in linking and in understanding the system programmatically
while I need that the people working on the system understands it, not a
computer program.

The key point is usability of the reading and authoring user interface. This
is not achieved by copying Word which is vastly known but not quite usable.

Well enough, this is running too long. Thanks to all. As of today Amaya is a
bettter solution for doing what I'm doing only I want to do much more.

Saludos!
--
Juan Lanus





On 8/27/07, Irene Vatton <Irene.Vatton@inrialpes.fr> wrote:
>
> On Saturday 25 August 2007 21:05, Juan Lanus wrote:
> > Hello,
> >
> > Every now and then somebody asks for the plans to support Javascript ....
> > sorry ...... ECMAScript in Amaya.
> >
> > With the generalization of the AJAX architecture model there is a need
> for
> > the scripting support, more than ever.
>
> This is true for a browser. For an authoring tool, in my opinion,  the
> need is
> to help people to create scripts.
> The main problem with a Javascript support is to mix changes done by the
> authoring tool and changes generated by a script.
>
> > So let's do this year's question: are there any plans at least to start
> > planning scripting support inside Amaya? Please?
>
> As I know Frederic Wang is working on that support. Will integrate his
> work as
> soon as it is usable.
>
> > --
> > Juan Lanus
>
> --
>      Irène.
> -----
> Irène Vatton                     INRIA Rhône-Alpes
> INRIA                               ZIRST
> e-mail: Irene.Vatton@inria.fr       655 avenue de l'Europe
> Tel.: +33 4 76 61 53 61             Montbonnot
> Fax:  +33 4 76 61 52 07             38334 Saint Ismier Cedex - France
>
>