Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #26891

Re: Motivation behind the web application viewer (WAVI) project

Show all headers | View raw

bakunin95 wrote:

> thank you for your post, I appreciate you take the time to comment.

You are welcome.

> I intend to generate a diagram of a web application and all its
> components.

The least you should do then is to allow the user to limit the level of 
inspection.  A Web developer (like me) should know the libraries and 
frameworks they are using rather well, and there is API documentation for 
those to find out; in a class diagram or component diagram I suppose they, 
too, are more interested in the structure of *their own* code (that uses 
libraries and frameworks, if necessary).

> I want to support javascript/nodejs,css,html,java.

There is no “javascript”.  This is the first thing that you need to accept 
and understand if you want to be successful there.  You are dealing with 
implementations of ECMAScript: a *family* of programming languages, with a 
similar but different syntax and feature set each – at first because the 
standard attempted to reconcile differences between existing implementations 
(Netscape JavaScript and Microsoft JScript), now because the standard allows 
extensions for conforming implementations.

Node.js is not a programming language, it is an application framework that 
uses Google V8 JavaScript, a particular implementation of ECMAScript Edition 
5+.

CSS has classes, but only as formatting hooks: it is a stylesheet language, 
not a programming language.  I cannot imagine a class diagram of a 
stylesheet.

HTML has a “class” attribute but it is a markup language, not a programming 
language.  The only way in which I can see the inspection of HTML as useful 
there is to determine client-side scripts, whether inline or referenced (see 
below).

_Java_ *is* a programming language, and it uses class-based inheritance, so 
it is a suitable target.  However, there are UML tools for it already – so 
much so that you can take Java code, generate an UML class diagram from it, 
and edit the class diagram where those changes are reflected in the Java 
code.  So you should ask yourself whether you should invest the time to 
reinvent the wheel.

ISTM that Java as a programming language for client-side *Web* applications 
is on the way out as the Netscape Plugin API (NPAPI) require for applets is 
not (well-)supported by modern browsers anymore; but it is used for 
standalone client applications and server-side code of Web applications.

> The problem I have is that UML is not meant to show web application and 
> all these languages components except for java so i use «stereotypes» and 
> color to extend UML and to show what is the type of the file. In this 
> React framework example, you only see JavaScript file.

Rather, UML *class* diagrams are not meant to represent the structure of 
code written in a *prototype*-based programming language.  However, it is 
possible to model a prototype object as a class *for the purpose of showing 
inheritance*.  Consider, for example (based on ECMAScript, 5.1 Edition):

  ,-----------------------------------------------------------.
  |                      Object.prototype                     |
  |-----------------------------------------------------------|
  | +constructor : Function = Object                          |
  |-----------------------------------------------------------|
  | +hasOwnProperty(v: String¹) : boolean                     |
  | +isPrototypeOf(v: Object) : boolean                       |
  | +propertyIsEnumerable(v: String) : boolean                |
  | +toLocaleString() : string¹                               |
  | +toString() : string                                      |
  | +valueOf() : any²                                         |
  `-----------------------------------------------------------'
                                ^
                                :
                                :
  ,-----------------------------------------------------------.
  |                       Array.prototype                     |
  |-----------------------------------------------------------|
  | +constructor : Function = Array                           |
  |-----------------------------------------------------------|
  | +concat(…) : Array                                        |
  | +every(callbackfn: Function, thisArg: Object) : boolean   |
  | +filter(callbackfn: Function, thisArg: Object) : Array    |
  | +forEach(callbackfn: Function, thisArg: Object) : boolean |
  | +indexOf(searchElement, fromIndex: int³) : int            |
  | +join(separator) : string                                 |
  | +lastIndexOf(searchElement, fromIndex : int) : int        |
  | +map(callbackfn: Function, thisArg: Object) : Array       |
  | +pop() : any                                              |
  | +push(…) : int                                            |
  | +reduce(callbackfn: Function, initialValue) : any         |
  | +reduceRight(callbackfn: Function, initialValue) : any    |
  | +reverse() : Array                                        |
  | +shift() : any                                            |
  | +slice() : Array                                          |
  | +some(callbackfn: Function, thisArg: Object) : boolean    |
  | +sort(comparefn: Function) : Array                        |
  | +splice(start: int, deleteCount: int, item1, …) : Array   |
  | +toLocaleString() : string                                |
  | +toString() : string                                      |
  | +unshift(item1, …) : int                                  |
  `-----------------------------------------------------------'

_________
I am using several conventions for argument and return types here that
I have found useful (and that are used in the ECMAScript Support Matrix
[“ES Matrix”; see sig], with a more detailed explanation to come about
the [rather complex] type system of ECMAScript implementations):

¹ “String” means that you can pass both a primitive string value and a
  reference to an object that inherits from String.prototype, or that the
  passed value is converted to that; “string” means that the value has to be 
  a primitive string value.  Likewise for other types that allow for
  primitive values.
² There is no “any” type; “any” indicates that a value of any type may
  be passed or returned.
³ “int” means that a value of type “int” is expected if such a type is
  supported, and a value of type Number with decimal fractional part 0
  otherwise.

> JavaScript is definitely the most difficult one to show in UML, […]. The 
> fact that there are no class yet and that there are so many people that 
> use this language differently pose problem.

The main problem is that so many people think it is only one language, the 
same everywhere.

There are classes already in implementations of the abandoned ECMAScript 
Edition 4 Working Draft, for example in Microsoft JScript .NET and 
Macromedia/Adobe ActionScript 2.0+.

There are going to be classes in a fashion different from that in 
implementations of the upcoming ECMAScript Edition 6.  Probably Mozilla 
JavaScript and Google V8 JavaScript will be the first to support that.

People use these language*s* so differently because they are so flexible; 
that is a, if not *the*, strength of them.

> For example, i cannot tell for sure that ReactInstanceHandles is meant to
> be a Class or if its simply a standalone script.

That depends on how people think of a “class” in a language that has no 
classes.  If they think about it in terms of something that can be 
instantiated using the “new” keyword, then you can look for that: an 
identifier or property accessor that is used with “new” is meant to refer to 
a constructor.  One can consider a constructor a required part for a user-
defined object type (that which most closely resembles what is a class with 
class-based inheritance).

> I cannot tell in what environment they will be run, is
> it a nodejs module for the server ?

ISTM that a telltale signs of a Node.js module is the occurrence of a 
standalone “module.exports” in a source file.

BTW, Node.js is not tied to server-side applications.  (Where I work we are 
using it exclusively "client-side", in build scripts.)

> or is it a javaScript file for the client.

A possibility is to look for “script” elements referring to the file as a 
resource in (X)HTML markup.  But scripts can be combined, there is content 
negotiation, and they can be loaded dynamically as well.

> What i found out with my project is that what would be a small
> class in Java end up being an Object inside a JavaScript file.

I do not understand this statement.  Object instances exist in memory, not 
in source files.

> This is why i extract that information. As for Array, im still unsure if
> they are interesting components to extract or not.

Native object types should only be inspected per user preference.
 
> The visibility is also quite tricky, they are not explicitly shown in
> Abstract Syntax Tree,

It is if you make function declarations and expressions, thereby execution 
contexts, nodes in the tree.

> […] if there is anything else i can do to make my project better, feel 
> free to share.

[x] done

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Motivation behind the web application viewer (WAVI) project bakunin95 <jocl06@hotmail.com> - 2015-02-21 16:56 -0800
  Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-22 12:40 +0100
    Re: Motivation behind the web application viewer (WAVI) project bakunin95 <jocl06@hotmail.com> - 2015-02-22 06:37 -0800
      Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-22 19:29 +0100
        Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-23 10:20 +0000
          Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-23 15:17 +0100
            Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-24 09:58 +0000
              Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-26 11:29 +0100
                Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-26 19:26 +0000
                Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-27 05:48 +0100
                Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-27 10:26 +0000

csiph-web