W3C home > Mailing lists > Public > www-amaya@w3.org > July to September 2007

Re: JavaScript in Amaya

From: fwsmail35 <fwsmail35@aol.com>
Date: Mon, 27 Aug 2007 18:41:47 +0200
Message-ID: <46D2FECB.6040207@aol.com>
To: www-amaya@w3.org, juan.lanus@gmail.com


> 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
> <http://www.cs.kent.edu/%7Ejmaletic/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
> <mailto: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 <mailto: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
>
>
Hi Juan,

  I'm not sure to have understood all your project, or rather, I do not
see why you need Amaya to use your javascript CMS. Anyway, I can not
promise that my javascript/DOM implementation will be finished soon or
even it will be finished. The problem is that implementing DOM &
javascript events and finding how could work a javascript
editing/browsing interface need a lot of work whereas for the moment I
have been alone... so motivated programmers/testers are necessary to
make the project advance. Moreover, I do not personally need javascript
in Amaya and I'm more likely to concentrate my effort on MathML
implementation. But I started this implementation because I think it
corresponds to two main purposes of Amaya :

1) Creating a software that contains all W3C technologies

  Javascript (or Ecmascript) is not a W3C standard but is regarded by
several people as a basic feature of Web browsers. Hence it is a bit
paradoxical to have in the one hand state-of-art W3C technologies and on
the other hand no scripting capability. About DOM, it is part of the W3C
specification and so it is natural to implement it if we want to achieve
the goal of a W3C browser/editor. But I think we can moreover get
features that other browsers do not have :
    o Implementing DOM in XML languages other that XHTML. For instance
SVG and MathML have there own DOM implementation, described in their
specification, but as far I know, no browser implement them.
    o Using DOM inside an authoring tool (maybe it is related to your
project ?). For instance DOM can be used to let the user create its own
authoring functionalities with a script (for example that checks all the
"alt" attribute of the images and display a "prompt" window when they
are empty).

2) Being used by every level of users to produce documents conformed to
W3C specifications

  Javascript is both for a beginner (because the syntax is simple) and
an advanced user (because it allows sophisticated AJAX interface). So an
implementation in Amaya (with state-of-art XML languages) is required
for the latter and a help to easy write scripts conformed to W3C
specification is useful for the former (sadly enough, a lot of them use
a non-standard DOM, specific to Internet Explorer).

Fred

-- 
Frederic WANG
http://www.maths-informatique-jeux.com/international/
Received on Monday, 27 August 2007 16:42:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 December 2014 20:09:06 UTC