Class EventNode

  • All Implemented Interfaces:
    java.io.Serializable, java.lang.Comparable<Entity>

    public class EventNode
    extends TCE
    implements java.io.Serializable
    The class class comprises the intended public facing API for the JsonAST-Package. It is easy to load the Abstract Syntax Tree's from disk by invoking the deserializeFromJAR() method inside of class SERIALIZED_AST. Remember that the entire package Torello.Browser.JsonAST is used primarily by a proprietary, and yet unreleased code generator, and is only made public for informational & reference purposes.

    Loading the the serialized trees from the '.jar' file, perhaps, may elucidate some of Google's Browser CDP API. The nodes themselves have quite a bit of read only data available.
    An Java Object used within AST to symbolize or encapsulate the data present in any of the JsonObject's found within a Domain's "events" array.

    The following two tree diagrams, with explanation, are repeated verbatim across all eight AST Node Classes.

    Object Inheritance for AST Nodes, and RunTime Tree Organization

    The Objects which are generated by the JSON Parser are converted into AST Node Object-Instances, all of which are listed here, below. An in depth study of the CDP Specification, a programmer must realize that there are actually three (possibly four) different trees functioning simultaneously. The Classes themselves have their own "Inheritance Tree." Then, additionally, by its very nature, the original JSON Spec Files are organized in a Tree Structure (as is all JSON, you may view these trees here: Browser API JSON and JavaScript API JSON

    Finally, and most importantly, at RunTime as Objects Instances, themselves, are created by the Parser; they are saved into the "Abstract Syntax Tree" (AST for short). These instances are placed into this AST, by saving them into ReadOnlyList's from the ReadOnly Collections Framework.


    Class Inheritance Tree:
    The diagram below shows the static class hierarchy: how the core JsonAST classes inherit from one another at the type level.

    API
    Domain
    
    Entity
    ├─ TCE  (abstract)
    │  ├─ TypeNode
    │  ├─ CommandNode
    │  └─ EventNode
    └─ PPR
    



    Runtime Object Instance Tree:
    In contrast, this diagram shows the dynamic structure at runtime: how reified instances of those same classes are organized into an AST, with parent–child container relationships.

    API
    └─ Domain
       ├─ TypeNode
       │  └─ PPR       ➜ [P]roperties     ➜ Generate to Java Class Fields
       ├─ CommandNode
       │  ├─ PPR       ➜ [P]arameters     ➜ Generate to Java Method Parameters
       │  └─ PPR       ➜ [R]eturn-Values  ➜ Generate to Java Method Return Values
       └─ EventNode
          └─ PPR       ➜ [P]arameters     ➜ Generate to Java "Event Class" Fields
    



    The following six JsonObject properties are mapped to the following Entity subclasses:
    Json Object Type AST Node Java Conversion "Target"
    Type TypeNode Converted into Java Inner Classes / Nested Types of the Primary Domain Java-Classes
    Command CommandNode Converted into Java Methods within the Primary Domain Java-Classes
    Event EventNode Also Converted into Inner Classes / Nested Types of the Primary Domain Java-Classes
    Property PPR Converted into typical Java Fields within the Inner Types / Nested Classes.
    (See note †† below.)
    Parameter PPR For Commands, these are Converted by the Code Generator into Method Parameters. For Events, these are actually also just converted into Fields of the Nested Event Class too.
    (See note †† below.)
    Return Value PPR These are converted (for Commands), into Return-Values for the Methods. Using the "Multi-Return Tuples" RetN defined in the Java.Additional package, it is possible (and quite common, actually) to return multiple values from a single method invocation.
    (See note †† below.)

    †† Unlike TCE, Properties, Parameters, and Return-Values do not have their own dedicated AST nodes, because their content is always identical to that in base class PPR.
    See Also:
    Serialized Form


    • Method Summary

       
      Methods: interface java.lang.Iterable
      Modifier and Type Method Description
      Iterator<PPR> iterator()
      Returns an Iterator that iterates the contents of the parameters list.
       
      Methods: class java.lang.Object
      Modifier and Type Method Description
      String toString()
      Returns a String representation of 'this' instance.
      • Methods inherited from class java.lang.Object

        clone, finalize, getClass, notify, notifyAll, wait, wait, wait
    • Field Detail

      • serialVersionUID

        🡇     🗕  🗗  🗖
        protected static final long serialVersionUID
        This fulfils the SerialVersion UID requirement for all classes that implement Java's interface java.io.Serializable. Using the Serializable Implementation offered by java is very easy, and can make saving program state when debugging a lot easier. It can also be used in place of more complicated systems like "hibernate" to store data as well.
        See Also:
        Constant Field Values
        Code:
        Exact Field Declaration Expression:
         protected static final long serialVersionUID = 1;
        
      • EVENT_JSON_PROPERTIES_SET

        🡅  🡇     🗕  🗗  🗖
        protected static final ReadOnlySet<java.lang.String> EVENT_JSON_PROPERTIES_SET
        The list of additional JsonObject properties that the parser should expect when parsing EventNode objects from the JSON CDP specification files.
        Code:
        Exact Field Declaration Expression:
         protected static final ReadOnlySet<String> EVENT_JSON_PROPERTIES_SET =
                 new ReadOnlyTreeSet<>(String::compareTo, "name", "parameters");
        
      • parameters

        🡅  🡇     🗕  🗗  🗖
        public final ReadOnlyList<PPR> parameters
        Collection of PPR (Parameter) instances that will be materialized as Java Event-Class fields

        The CDP JSON Specification Files allocate a "parameters" array for most JsonObject "event" elements in the specs. Each of the objects in the "parameters" array are, themselves, constructed & instantiated into instances of class PPR.

        And each and every PPR will eventually be converted in a Java Field which is a member of the container "event" (a static nested class) in which they were specified.
        Code:
        Exact Field Declaration Expression:
         public final ReadOnlyList<PPR> parameters;
        
      • isReifiedInnerClass

        🡅  🡇     🗕  🗗  🗖
        public final boolean isReifiedInnerClass
        Flag indicating whether this EventNode represents a reified inner class in the CDP model.

        A "Reified Class" is an instance of a EventNode for which the Code Generator shall emit a static Java nested type as a static member of the ownerDomain class. In short, if an EventNode's 'isReifiedInnerClass' boolean has been assigned TRUE, then you should be able to count on finding a nested type in the Generated Java Class for the domain in which that EventNode resides.

        As an example, in the BrowserAPI, the first domain which is listed is the Accessibility domain. Inside that domain, the first nested type / inner class listed is one named Accessibility.loadComplete. The inner class loadComplete is, indeed, a static nested inner class; and if you were to traverse or "search" the AST tree for the following nodes:

        BrowserAPI (API Node)    ➜    Accessibility (Domain)    ➜    loadComplete (EventNode)

        and check the value of its isReifiedInnerClass flag, you would see instantly that it had been assigned TRUE, precisely because the Code Generator intentionally generated that nested class to represent this particular EventNode

        What is important to know is that within the CDP JSON Specifications, not all "events" have been declared or created equal. Any type which has at least one PPR property in its parameters array will be reified into its own, dedicated, Java Nested Class.

        Some events, simply called "Marker Events" by the docs in this library (although they are not likely known by that name elsewhere), are events which do not possess any state whatsoever. And when they are fired by the browser, since there is nothing to relay to the user, other than the fact that the event did fire, they are not "reified" into actual Java Classes. In english this means that the internal Java-HTML Code Generator will not produce an actual Java Class for that event.

        Instead, when they are fired a generic BrowserEvent is transmitted to the programmer's Event Listener, with the BrowserEvent's fields name and domain being sent to the domain and event name that have been fired.
        Code:
        Exact Field Declaration Expression:
         public final boolean isReifiedInnerClass;