Abstract:
One embodiment of the present invention provides a system that facilitates creating a hierarchical model from a programming language file that includes components. The system operates by obtaining a component from the programming language file. Upon obtaining the component, the system passes an encoder to the component and requests that the component encode itself using the encoder, thereby causing the encoder to generate elements in the hierarchical model. Each element includes an attribute that identifies the component, thereby allowing the component to be subsequently identified by referencing the attribute in the corresponding element in the hierarchical model.

Description:
BACKGROUND 
   1. Field of the Invention 
   The present invention relates to tools for developing applications for an application server. More specifically, the present invention relates to a method and an apparatus that facilitates creating a hierarchical model from a programming language file that contains components, in a manner that allows the components to be subsequently identified by referencing the hierarchical model. 
   2. Related Art 
   The rapid proliferation of computer technology in recent years has been facilitated by significant advances in the design of user interfaces, which have made computer programs significantly easier to use. As these user interfaces become increasingly more sophisticated, a significantly larger percentage of an application developer&#39;s time is dedicated to developing user interfaces. This development process typically involves tedious and time-consuming manipulations of the various graphical components that comprise a user interface. 
   A number of tools have been developed to simplify the process of developing user interfaces. Some of these tools provide a WYSIWYG (What You See Is What You Get) editor, which allows an application developer to manipulate the graphical components that comprise a user interface. 
   It is difficult to build a WYSIWYG design tool that allows a user to manipulate a component in the WYSIWYG view and to make corresponding changes to the associated component in the source file. This is especially true for JavaServer Faces (JSF) components in situations where a component is embedded within another component. In this situation, a component is free to replicate a subcomponent&#39;s rendered HyperText Markup Language (HTML) or ignore it altogether. For example, a “tabbed window” JSF component will render exactly one of its children—the one corresponding to the selected tab. In general, given a JSF component hierarchy, it is difficult to determine which portions of the HTML correspond to which individual components in the hierarchy. 
   The following example illustrates this problem. Consider the block of code in JSF source file  100 , illustrated in  FIG. 1A . When this block of code is rendered using JSF&#39;s render kit, corresponding JSF-rendered HyperText Markup Language (HTML)  110  is produced as is illustrated in  FIG. 1B . In  FIG. 1B , the bold line &lt;input type=“submit” value=“Submit”/&gt; corresponds to the bold line &lt;h:commandButton value=“Submit”/&gt; from JSF source file  100 . Everything else in JSF-rendered HTML  110  comes from the &lt;h:panelGrid&gt; component from JSF source file  100 . 
   While the system can compute the HTML stream to render at design time, the challenge is being able to identify which portions of the HTML correspond to specific individual components in the source file, without having any special knowledge of the individual components and what HTML they generate. It is important to be able to do this in a development tool. For example, if a user clicks on the button (rendered from the &lt;input type=“submit” value=“Submit”/&gt; tag above), the corresponding &lt;h:commandButton value=“Submit”/&gt; component is selected and its properties are displayed in a property sheet in the development tool. In order to accomplish this, the system needs to determine which HTML elements from JSF rendered HTML  110  correspond to which components in JSF source file  100  as illustrated in  FIG. 1C . 
   Hence, what is needed is a method and an apparatus for identifying components in a source file that generated a markup stream in a markup file. 
   SUMMARY 
   One embodiment of the present invention provides a system that facilitates creating a hierarchical model from a programming language file that includes components. The system operates by obtaining a component from the programming language file. Upon obtaining the component, the system passes an encoder to the component and requests that the component encode itself using the encoder, thereby causing the encoder to generate elements in the hierarchical model. Each element includes an attribute that identifies the component, thereby allowing the component to be subsequently identified by referencing the attribute in the corresponding element in the hierarchical model. 
   In a variation on this embodiment, the programming language file is a JavaServer Pages file. 
   In a variation on this embodiment, the component is a JavaServer Faces Component. 
   In a further variation, the encoder is the JavaServer Faces ResponseWriter. 
   In a variation on this embodiment, the system renders a markup language file from the programming language file, wherein markup language components in the markup language file correspond to elements in the hierarchical model. The system then uses the hierarchical model to associate markup language components with components from the programming language file. 
   In a further variation, the system uses the hierarchical model in an integrated development environment. 
   In a variation on this embodiment, the markup language is a form of HTML. 
   In a further variation, the markup language is XHTML. 
   In a variation on this embodiment, the hierarchical model is a Document Object Model. 

   
     BRIEF DESCRIPTION OF THE FIGURES 
       FIG. 1A  illustrates a code block from a JavaServer Faces Source File. 
       FIG. 1B  illustrates an HTML block from a JavaServer Faces rendered HTML file. 
       FIG. 1C  illustrates associations between a JavaServer Faces Source File and a JavaServer Faces rendered HTML file in accordance with an embodiment of the present invention. 
       FIG. 2  illustrates Document Object Model writer  206  in accordance with an embodiment of the present invention. 
       FIG. 3  presents a flowchart illustrating the process of creating a Document Object Model in accordance with an embodiment of the present invention. 
       FIG. 4  presents a flowchart illustrating the process of identifying a component that generated HTML using the Document Object Model in accordance with an embodiment of the present invention. 
   

   DETAILED DESCRIPTION 
   The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. 
   The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs), but does not include computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated). 
   DOM Writer 
     FIG. 2  illustrates Document Object Model (DOM) writer  206  in accordance with an embodiment of the present invention. (The current DOM specification can be found at http://www.w3.org/DOM) JavaServer Faces (JSF) provides a HyperText Markup Language (HTML) encoding scheme where each component, such as component  202  in JSF document  200 , has a corresponding HTML renderer, such as renderer  204 . Renderer  204  looks at component  202  and emits HTML according to the properties and children of component  202 . Component  202  is able to accomplish this by calling into a special component writer defined by JSF Oavaxfaces.context.ResponseWriter) to output the actual HTML content on its behalf. Note that this was done to ensure that the HTML is well formed (attribute values are properly escaped and so forth.) However, one embodiment of the present invention replaces an original JSF writer to solve the problem described above. 
   In this embodiment, the original JSF writer is replaced with a new ResponseWriter implementation, writer  206 . Component  202  is then asked to encode itself by calling back to writer  206 . Writer  206  builds up DOM  210  directly in memory to represent component  202 , instead of generating HTML text as was intended. For example, when component  202  calls startTag(“table”), writer  206  creates a new DOM Element in DOM  210  and assign it the tag “table”. When component  202  calls writeAttribute(“border”, “0”), writer  206  translates this into currentElement.setAttribute(“border”, “0”), and so forth. 
   However, DOM  210  also has some additional fields per element that are set in the current embodiment. In particular, in writer  206 &#39;s startElement( ) method, the system determines which UIComponent is currently being rendered, and stores that in DOM  210  right with the Element. This way, the end result is a DOM Document which not only has all the HTML elements and text nodes generated from the component, but it also has a reference for each element back to which JSF component the given tag corresponds to. With this information, a page designer, when rendering the HTML document, can also handle user interaction with the components. If a user clicks on a part of the display, the corresponding HTML for that mouse click is consulted, and the component reference is looked up in DOM  210 . The net result is that the system can select the right JSF component for the mouse click, and display its properties in the property descriptor, or apply a tool action like “copy” or “move” or “delete” to the right component. 
   Note that for purposes of illustration, JSF, HTML, and DOM are used. However, the invention is not meant to be limited to JSF, HTML, and DOM. In general, any types of programming languages, markup languages, and hierarchical models may be used. 
   Creating a Document Object Model 
     FIG. 3  presents a flowchart illustrating the process of creating Document Object Model  210  in accordance with an embodiment of the present invention. The system starts by replacing an original JSF writer associated with component  202  with writer  206 , wherein writer  206  renders elements in DOM  210  rather than HTML (step  302 ). 
   Next, the system requests component  202  to render itself (step  304 ). When component  202  invokes writer  206 , writer  206  generates elements in DOM format. These elements include additional attributes that indicate the component that generated them. For example, given a component named “button1”, each element generated in DOM  210  could include an attribute called “binding” with a property of “button1”. As each component invokes writer  206  to generate corresponding DOM elements, the system assembles these elements into DOM  210  (step  306 ). 
   Identifying Components with a Document Object Model 
     FIG. 4  presents a flowchart illustrating the process of identifying a component that generated HTML using Document Object Model  210  in accordance with an embodiment of the present invention. In the context of a developer tool, it is important when a user is manipulating graphical objects in a WYSIWYG (What You See Is What You Get) editor for the editor to make modifications to the appropriate component. DOM  210  can be used as a lookup map to determine which components generated which sections of the HTML code and corresponding graphical objects. 
   The system starts when it receives a mouse click from a user on a graphical object, such as a command button or a form field (step  402 ). Next, the system determines which part of the HTML file generated the graphical object that the user is interacting with (step  404 ). Finally, the system uses DOM  210  to determine the component that generated the HTML that created the graphical object (step  406 ). This is accomplished by locating the element in DOM  210  that corresponds to the graphical object, and reading the value of a special attribute attached to the element that indicates the ID of the corresponding generating component. 
   This embodiment represents a marked improvement over existing developer tools in that it provides a quick and accurate mapping from the generated HTML back to the generating components. DOM  210  is generated quickly and accurately from the components themselves, and facilitates this backward mapping. Existing tools cannot perform this mapping. Hence, if any existing tool tries to render a custom component which has been selected in a user interface, the existing tool will not be able to render the custom component, but instead will represent the custom component with some sort of reserved space to indicate that it could create a graphical object for the custom component in the area indicated by the reserved space. 
   The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.