[CONF] Apache Labs > MagmaEclipseDevTools

[confluence]

MagmaEclipseDevTools Page edited by Simone Gianni What events are During the execution of a cycle, be it a page request or whatever else, a number of events take place. Some of these events may be : Output of a something to the web browser A database query Access to context informations (like reading or writing to the session, accessing i18n data, reading properties) A log statement Each event is composed of some fixed elements (common to all events): The subsystem executing it, which could be a tree (like Magma/Settings) An event proprity, like "Error", "Warning", "Info", "Debug". The requestor, that is the context where the operation is executed Timing informations It could also contain a bag of optional, multivalued attributes, like : Involved resources, for example the i18n file used, or the properties file used Parameter values, both entering and exiting the event, for example the string of a database query, value of parameters and value of return Events are inherently both a list and a tree. In fact, some events may have been generated by previous events, for example in Magma accessing a session attribute which is a database Entity may trigger a database read. So, each event is executed in the context of a number of events before it, like for example : Rendering page (URL="" Executing template (Template class = MyTemplate.java, Template file = mytemplate.html) Laying out (zone = zoneLeft) Executing method (method = MyBoxWebHandler.doSideBox(Person p)) Executing query (query = select p from Person where p.id=5 returning Personname=Simone But at the same time, it has meaning to ask for a tabular view of all "Executing query" events. Notable events Since events generated can be many (thousands), and they are a tree, we should partiton them selecting some "notable events" that the GUI should use as main anchor points of the tree. So, the tree of events has two access schemes, one is based on all events and their relation, the other one is based only on notable events that contain sub events. This simply means that each notable event will have decendant notable events displayed in a prominent position, even if those notable events are in reality children of non-notable events. In Magma, notable events may be : Entering a page request Entering a template Entering a layout method Entering a do method Entering a template (.vm, .jsp etc..) But the user should be able to customize its own "point of view" and add or remove which notable events are important for him. For example, if he is working on database performance, the datbase queries would be notable events. Located events Located events are events that have a specific location on the HTML page. Since we want to achieve "point and click" event browsing based on the target HTML, we need to give the tool some kind of location information about which events happened on a certain part of the page and vice-versa (which part of the page is responsible for a given event). Given that events are a tree, and entering a do method is an event, it would be quite obvious to have that (notable) event be also located. However, some other event are not necessarily notable but still located, like the translation of an i18n string. Events and output HTML HTML is relatively poor when it comes to structural data, and polluting HTML with elements used solely for the purpose of this "annotation" process can create more problems it solves. So, the HTML sould contain relatively small amount of event informations, while complete event trace should be retrieved using some other method, for example obtaining an XML representation of the event on request, or a complete dump of all events that the tool will then parse. So the solutions to achieve this synchronization are : A : Use absolute byte position of the event in the resulting HTML Pros : does not pollute HTML at all, given a click the byte position of the underlying element can be used to find where in the event stream we are Cons : there is no easy way to know the byte position of a mouse click on a browser (not in _javascript_, not in SWT browser widget) B : Use xpath expressions of the element the user clicked on Pros : again, no HTML pollution at all; _javascript_ is able to build an xpath string (or equivalent) for a click. Cons : much more parsing on the server side, to keep track of which is the xpath of the current element; browser DOM could be modified by the browser itself, making the two xpath not identical. C: Use custom attributes on HTML elements, containing one or more event ids Pros : easy to retrive those ids on click; always exact Cons : still need to parse outgoing stream data; custom attributes may trigger validation errors; since such attributes should be placed on the parent element, while events could happen after that element has benn flushed, we may need some kind of buffering. D : Use specially crafted HTML comments Pros : easy to retrieve the "nearest" (preceding sibling, or parent preceding sibling, recursively) comment in _javascript_ and SWT widget; easy to send them out on the stream; HTML is polluted but only by completely neutral elements. Cons : it may be not precise enough; we still need some buffering, but buffering of html comments waiting for ">" to apper on the stream The best compromise between simplicity and validity seems to be given by the option B. Obviously, only located events should be placed on the resulting HTML, no matter if they are notable or not. Display Conceptual layout Layout should be composed of the following elements : A site explorer view, containing instance wide informations, like : URI space Settings Environment data (classpath, env vars etc..) A page viewer, which is a browser with an address bar, reload button etc.. An event viewer It should display a table/tree, or ability to switch between the two Other optional event views, like for example Database events view I18n events view Caching events view etc.. they could be all the same view with different select parameters The various views should be interconnected. Selecting a page should, if necessary, update the site explorer to reflect the new server/instance. Clicking (or right clicking, or double clicking) on the page viewer, should contextualize the other views, like showing in the site explorer the corresponding uri space entry, displaying the tree of events in the event viewer, hilight the relevant parts of other satellite views. Also, cliking on satellite view or event tree should display the part of the page that generated them, in a facet view pattern. This design perfectly fits an Eclipse perspective, but the system should be deisgned so that different implementations are possible. Site explorer view The site explorer is has three main parts. Eventually these parts could be represented in an Accordion or Tab style interface. URI space The URI space is a tree rooted at the rootWebHandler class, and displays its handle and do methods. For each handle method, the returned type is considered and recursed to create child elements. It would be nice to make explicit wether the URI is generated by a project currently in the workspace, or by a Magma fragment, or by a third party classpath entry. If the method takes parameters, parameters should be displayed, either as special children or as another column of a tree table. The URI space gives access to two actions : load that page in the page viewer, or open the corresponding method in Eclipse. Settings The settings view display settings keys, values and source. It should be able to sort/group elements by each column. It should make explicit wether the setting is coming from a workspace file or not, and wether it is a default, environmental or user settings file that generates it. Some properties may not be explicit, but known to be needed. In that case these properties should be clearly marked. Some properties may be undeclared but fetched using a default value, in this case a special source element should be used. There should be two possible operations on a value : open the source file from where it comes from, and materialize it on an overriding file. Environment data This data includes the current user name as seen by Magma, the current environment setting (devel, production etc..), and eventually a bunch of informations about java version, OS version etc.. It will be a table of key-value, mainly obtained from the system properties of the JVM. Page viewer The page viewer is a browser where pages are displayed. It should support basic browser operations, like typing an URL, going back and forward, reloading. It would be nice to support different tabs, different pages openend at the same time. In eclipse this could mean that it is an editor, and more than one editor can be opened at the same time in the main workbench space. It would be ideal to have some kind of content assist while typing the URL, using previous used URLs or informations from the URI space if available. The browser should fetch the page from the given URL. While the page is loading, it should emit an event to other views regarding the new URL. The server should emit annotated HTML. One of the annotations will be a page ID, using which events can be retrieved from the server. The browser should instrument the HTML, either adding a _javascript_ to it or with other means, so that user interaction on the page triggers an identification of the part of the page the user is interested in. Once the user expressed interest on a part of the page, that part of the page should be highlighted, the nearest event annotation retrieved, and an event dispatched to other view so that they can highlight or scope their view. On the opposite, the page viewer should also act the opposite way, receiving from other views highlight request about a located event and displaying that part of the page. Despite this instrumentation, the page viewer should be a fully functional browser, allowing common page interactions, _javascript_ etc.. For this reason, a different gesture than the plain click should be considered fir highlighting parts. Future enhancements may include recording of small "macros" on the page and playback of those macros, which is something every web developers does in his day by day work. Event viewer This is probably the core of the system. It should display events happened during page generation. Events are, as we said, both tabular and tree data. The user should be able to switch between the two. Each event has a type, the type will most probably be the main discriminator, so each event type should have an icon or a name or both. Selecting only some events (aka configuring filters per type) is an extremely important feature. When events are displayed as a tree, the main tree structure is composed of notable events, filtered by type as indicated by the user. The user should also be able to decide if he wants to see different event types as notable events. Other events will be placed inside their notable events, in the same tree structure as the server parsed it. Each event will have some fixed parameters, like timing informations or source location. The user should be able to decide to show these parameters in the tree table view. Each event will have a number of variable parameters, these could be displayed in a small table aside the main tree/table. Events can be displayed also in a table, so that sorting on specific parameters is possible. For example, sorting events of type "Database query" based on their execution time. In a preliminar stage, only properties common to all events (like timing and proprity informations) may be used for sorting. Once the user has modified the view, filtering only some event types, sorting them etc.. These settings should be preserved. In a future version they could even be saved for the user to reuse them. This part heavily interacts with other parts of the system. When an event is selected, an event is broadcasted so that other views can react, for example : The page viewer can hilight the nearest located element As a conseguence, other parts could hilight some of their elements, like the URI in the uri space. Some parts could hilight specific elements pertaining to the event, like relevant settings for that event. The side list is popolated with the bag of variable elements. Some of these elements are important when they are doubleclicked, cause they could contain pointers to source files, for example the settings file it is originating from, and some others may register to launch some wizards, like for example adding a key on an i18n file. When an event is double clicked, the requestor source file is opened. Exporting events in some format, like CSV file or HTML report, is an interesting possible enhancement. Optional events view These views are different instances of the main event view, missing probably the side bag. These are configured to show specific events type, in specific order. When an event is selected in these views, it is selected on the main events view where full context is available. Also these views should support tree table and table only views. Implementation The system is composed of three main parts : Event gathering HTML annotation and event retrival Display part Here we will analyze these parts from an abstract POV. In fact, this developer tool is not directly connected to Magma itself, but applicable to any web framework using LTW and a servlet filter. The display part has boviously already been covered. Event gathering Events are gathered by AspectJ and saved on a threadlocal structure. This structure will accept "entering" in an event and "exiting" from an event, most probably these two function will be called by before/after advices. On entering, the event will be added as a child of the previous one, on exiting the event instance will be still available for last second modifications, like adding the return value or timing informations. The threadlocal will hold also a page id, that will be used later for its retrival. Events should be java objects in a self contained packages. This will enable access from clients without requiring those clients to share big chunks of classpath with the server. That also means that events should only contain basic types, like String, int etc.. So, parameters and return type, just to name two, will be converted to Strings. HTML annotation and event retrival A stream will be used to filter the outgoing webapplication data, and annotate it. Obviously, this will work only if the mime type is XML compatible. When the threadlocal receives a located object, it will produce an xml comment containing the id of the event. This comment will be stored in a FIFO, and the stream will wait for being in the proper situation to add that comment to the stream. Proper situation means that it has received a '>' and not yet received a '<', to avoid placing comments inside elements. One of the first comments it should add to the page is the fact that it is annotated. This special comment should also give the URL of the retrival service and the page id. The client receiving the annotated HTML, can call the retrival service to retrive events. Events will be sent out in XML using XStreams. It is still undecided whether there will be a single retrival (entire XML with all events for that page), or per-id retrival based on user interaction with the UI, or notable events retrival first and then subevents of given notable events by id. The decision on this will be taken based on UI responsiveness. Change Notification Preferences View Online | View Change | Add Comment --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@labs.apache.org For additional commands, e-mail: commits-h...@labs.apache.org