Patent Application
20130227396
Web-based content can be provided in HyperText Markup Language (HTML) pages, style sheets, images, scripts, etc. Some Web page development environments offer the possibility to provide different views for the HTML document edited and displayed simultaneously. This capability is commonly referred to as “Split View”. Such environments offer a code (or text) view and a design (or graphical) view. For example, an editor can present HTML code in a code view and the output of executing the HTML code in a corresponding what-you-see-is-what-you-get (WYSIWIG) design view (e.g., representing what will be presented to an end-user who accesses the Web page). Accordingly, a developer can make changes in either the code view or the design view to alter Web page functionality.
HTML documents, especially those that define applications, are typically composed of many external files. Instead of having one large monolithic document that incorporates the full functionality of an application, the functionality is typically broken up and divided across various other HTML, Cascading Style Sheets (CSS), and JavaScript files.
While this decentralization has the benefit of breaking up the applications into re-usable modules, it has the disadvantage of making it difficult to actually build applications. It definitely makes it difficult for a person wishing to style or modify an existing application because the person does not know which files contribute to the overall document. In addition, having to constantly switch files reduces the productivity of the application developer.
One embodiment provides a “Related Files” feature that provides direct access to all of the files that make up a particular document or application. One embodiment provides not only the ability to modify the source of the primary document (i.e., the document that references the related files), but also the ability to provide categorized access to the related HTML, CSS, and JavaScript files that the primary document depends on. One embodiment of this feature allows a user to edit both the primary document as well as the secondary/related document at the same time, and provides good synchronization between the related files view and the visual design tools.
One embodiment is directed to a method that includes providing a Web development tool for developing an application that includes a primary document and a plurality of related files. A user interface for controlling the Web development tool is generated. The method includes generating as part of the user interface a code editor panel, wherein the code editor panel includes a primary editor sub-panel for editing content of the primary document and a secondary editor sub-panel for editing content of the related files.
The accompanying drawings are included to provide a further understanding of embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and together with the description serve to explain principles of embodiments. Other embodiments and many of the intended advantages of embodiments will be readily appreciated, as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.
In the following Detailed Description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.
It is to be understood that features of the various exemplary embodiments described herein may be combined with each other, unless specifically noted otherwise.
One embodiment provides a “Related Files” feature that provides direct access to all of the files that make up a particular document or application. One embodiment provides not only the ability to modify the source of the primary document (i.e., the document that references the related files), but also the ability to provide categorized access to the related HTML, CSS, and JavaScript files that the primary document depends on. One embodiment of this feature allows a user to edit both the primary document as well as the secondary/related document at the same time, and provides good synchronization between the related files view and the visual design tools. In one embodiment, modifications made in the visual tools will highlight the appropriate markup in the related files view. Overall, embodiments of this solution are easier to use than other existing solutions, and make designers/developers more productive when building complex documents, such as those that can be found in Windows 8 applications.
Embodiments provided herein make working with documents composed of many other documents easier, while retaining the ability to simultaneously edit the primary document as well as use the visual tools. One embodiment provides a user with the ability to edit both the primary document as well as a document related to the primary document, and the ability to visualize the markup that is being modified in the primary document or related document as a result of changes to the visual tools. These features will be described in further detail below, following the description of a web development tool suitable for implementing these and other features.
A modification to the web page source code is applied to the running page instance of the web page as represented by running representation 104 to dynamically update the running page instance to include the modification to the web page source code. Likewise, a modification to a Document Object Model (DOM) element in the running page instance of the web page is applied to the web page source code to dynamically update the web page source code to include the modification to the DOM element. In this way, a web page developer may modify DOM elements in a running instance of the web page in a browser and/or modify the web page source code and the modifications are dynamically applied to the web page source code and/or the running instance of the web page, respectively.
Web page source code of text source document 102 is linked, via link 112, to associated DOM 110 elements in a running page instance of the web page as represented by running representation 104. Therefore, by selecting or highlighting a DOM element within running representation 104, the web page text associated with the selected or highlighted DOM element is selected or highlighted within text source document 102. Likewise, by selecting or highlighting a portion of the web page text within text source document 102, the DOM element or elements associated with the selected or highlighted portion of the web page text is selected or highlighted within running representation 104. In this way, a web page developer can instantly match DOM elements as they are represented in a running instance of the web page with the web page text source code that defines the DOM elements.
In one embodiment, text source document 102 is opened in a source code editor, which includes any suitable text editor suitable for opening, creating, editing, and saving web page text source documents. In one embodiment, the web page text source documents that can be edited by the source code editor include markup text, such as HyperText Markup Language (HTML), Cascading Style Sheets (CSS), Extensible Markup Language (XML), and/or Extensible HyperText Markup Language (XHTML). The web page text source documents may also include JavaScript or JScript. As used herein, “JS” is used to refer to both JavaScript and JScript. In other embodiments, the source code editor is suitable for opening, creating, editing, and saving web page text source documents including other suitable web page markup text and scripting languages. In one embodiment, the source code editor supports multiple instances of web page text source documents such that related or linked web page text source documents may be simultaneously opened within the source code editor.
In one embodiment, running representation 104 is a web browser suitable for representing a DOM 110. In one embodiment, the browser is a World Wide Web Consortium (W3C) compliant web browser. In one embodiment, the browser provides a browser agnostic representation of a DOM 110 such that the representation of the DOM 110 does not depend on any particular browser, such as Internet Explorer, FireFox, Chrome, Safari, or Opera. In another embodiment, the browser is selected such that the representation of the DOM 110 is based on the selected browser. The browser may include an option for the user to select a particular browser, such as Internet Explorer, FireFox, Chrome, Safari, or Opera, on which to base the representation of the DOM 110. In one embodiment, the browser supports multiple instances of DOMs such that related or linked web pages may be simultaneously running within the browser. Running representation 104 may also include running script 108 and an Application Programming Interface (API) 106. Script 108 and API 106 may modify, delete, and/or insert DOM elements in DOM 110 within running representation 104.
Computing device/environment 200 may also have additional or different features/functionality and additional or different hardware and software. For example, computing device/environment 200 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
The various elements of computing device/environment 200 are communicatively coupled together via one or more communication links 215. Computing device/environment 200 also includes one or more communication connections 224, such as network connections, that allow computing device/environment 200 to communicate with other computers/applications 226. Computing device/environment 200 may also include input device(s) 222, such as a keyboard, a pointing device (e.g., mouse), a pen, a voice input device, a touch input device, etc. Computing device/environment 200 may also include output device(s) 220, such as a display, speakers, a printer, etc.
Markup text 302 includes HTML, CSS, XML, XHTML, and/or other suitable markup text. In one embodiment, the source document including markup text 302 is opened in a source code editor. In other embodiments, web development tool 300 accesses the source document including markup text 302 without opening the source document in a source code editor. Markup text 302 defines any suitable number of objects for providing a web page. In the example illustrated in
Due to the textual nature of markup text 302, each character of markup text 302 has a corresponding line number as indicated at 332 and a corresponding relative character number for the line as indicated at 334. For example, the character “H” in markup text 302 is at line 2, character 8. Each character of markup text 302 also has a character number that indicates the position of the character relative to the beginning of markup text 302. For example, the character “H” in markup text 302 has the character number of 26 since it is the 26th character in markup text 302. Thus, each character within markup text 302 can be located based on either a line number and position within the line or based on the character number that indicates the position of the character relative to the beginning of markup text 302. Likewise, a series of characters within markup text 302 can be located based on a range of line numbers and positions within the lines or based on a range of character numbers. As used herein, these ranges of line numbers and positions within the lines or ranges of character numbers are referred to as “text offsets.”
Markup text 302 is parsed by markup parser 306 to construct document node tree 310. In one embodiment, markup parser 306 is located on the same computing device/environment as the source code editor. In another embodiment, markup parser 306 is located on a different computing device/environment from the source code editor. Markup parser 306 includes an HTML parser, a CSS parser, an XML parser, an XHTML parser, and/or other suitable markup text parsers. In one embodiment, markup parser 306 is W3C compliant. In another embodiment, markup parser 306 is based on the parser associated with a particular browser, such as Internet Explorer, FireFox, Chrome, Safari, or Opera. In other embodiments, markup parser 306 is a hybrid parser that includes the basic implementation of the parser associated with a particular browser with alterations in the parsing implementation based on knowledge of the particular browser runtime execution and/or parse behavior.
Markup parser 306 includes the source document details from markup text 302, which are relevant to web pages, in document node tree 310. In addition to HTML objects and CSS objects, markup parser 306 includes other details from markup text 302, such as doctype and in-source comments that might be interpreted by browsers. Markup parser 306 also includes text offsets in document node tree 310 indicating the location of the source document details in markup text 302. The text offsets map each node of document node tree 310 to the markup text associated with the node. In this way, a link between document node tree 310 and markup text 302 is maintained during the parsing process. This differentiates markup parser 306 from conventional parsers integrated within browsers, which often discard or transform source document details during rendering for performance reasons and do not maintain any link between the source document and the rendered document.
In the example illustrated in
DOM builder 314 constructs a DOM and a view node tree that represents the DOM from document node tree 310. DOM builder 314 maps each node of the view node tree to a corresponding node of the document node tree such that each element of the DOM is linked to the associated object in document node tree 310 and thereby to the source document markup text that is associated with the object. In one embodiment, DOM builder 314 injects event listeners into the DOM for tracking modifications to the DOM.
In one embodiment, DOM builder 314 constructs JS elements. Once executing, the JS elements may construct and/or modify DOM elements and corresponding nodes within the view node tree, which may not have corresponding nodes within document node tree 310.
In one embodiment, DOM builder 314 constructs a browser agnostic DOM that does not depend on any particular browser, such as Internet Explorer, FireFox, Chrome, Safari, or Opera. In another embodiment, DOM builder 314 is selected such that the DOM is constructed based on a selected browser. DOM builder 314 may include an option for the user to select a particular browser, such as Internet Explorer, FireFox, Chrome, Safari, or Opera, on which to base the construction of the DOM. The constructed DOM is represented by browser 318. In one embodiment, browser 318 is a W3C compliant browser. In the example illustrated in
The view node tree and document node tree 310 link the DOM elements within browser 318 to markup text 302. For example, by selecting or highlighting “Hello” within browser 318, the associated markup text within markup text 302 is selected or highlighted. Conversely, by selecting or highlighting “<p>Hello</p>” within markup text 302, the associated DOM element “Hello” in browser 318 is selected or highlighted.
DOM modification listener 322 tracks changes to DOM elements, such as DOM mutations, within browser 318. In one embodiment, DOM modification listener 322 tracks changes to DOM elements due to API 106 and/or script 108 (
In one embodiment, changes can be made to DOM elements via document node tree 310 by a user modifying element attributes and/or style properties via a properties panel or other suitable mechanism. In this embodiment, the properties panel generates a change record for each change to an element. Each change record identifies the element to modify by node of the document node tree and the change to apply to the node. The change record updates the node in document node tree 310 based on the change record. DOM builder 314 then updates the DOM and the view node tree that represents the DOM based on the updated document node tree 310 such that the representation of the DOM in browser 318 includes the modification.
Markup serializer 328 serializes change information in document node tree 310 for updating markup text 302. Markup serializer 328 formats the changes to document node tree 310 (e.g., due to change records from DOM modification listener 322 or from the properties panel) to include the information needed to modify markup text 302 to match the updated document node tree 310. In one embodiment, the information provided by markup serializer 328 includes the text offsets indicating the location where the change is to be made in markup text 302 and the new value to place at the indicated location. In one embodiment, markup serializer 328 combines change information for a plurality of changes to document node tree 310 into a single serialized data file to update markup text 302 in a batch process in response to a user action. In another embodiment, markup serializer 328 may update markup text 302 in a batch process including multiple data files.
Changes can also be made to markup text 302 within a source code editor. In one embodiment, after a change to markup text 302, markup parser 306 performs a partial parsing of markup text 302 to update document node tree 310. In another embodiment, after a change to markup text 302, markup parser 306 performs a complete parsing of markup text 302 to update document node tree 310. DOM builder 314 then updates the DOM and the view node tree that represents the DOM such that the change to markup text 302 is reflected in browser 318.
When it comes to HTML applications, similar to web pages today, the end result is often a composite involving many other files. Some of the files will be assets like images that a user can simply view. Some of the files will be editable HTML, CSS, and JavaScript files. In one embodiment, Web development tool 300 provides users with the ability to easily create, modify, and style their applications even if the markup they are touching is defined in a different document. One of the features in Web development tool 300 that helps users navigate this fragmented world is referred to herein as a related files feature.
From a user interface (UI) point of view, the related files feature enhances the split view feature provided by Web development tool 300. In the split view, both a code view and a design view are open at the same time. The split view allows a user to see the markup highlighted for an element that the user has selected in the artboard or in the object tree, or if the user explicitly chooses a “View Code” command via a context menu. The related files feature enhances the split view feature by allowing a user to view the markup for all related documents—not just the markup for the main document that the user currently has open.
The related files feature is beneficial for a number of reasons. First, HTML designers feel more comfortable when they can see the markup that is being generated or modified as a result of visual changes. Second, because Web development tool 300 seamlessly allows one to edit inside and outside fragments in one embodiment, not having the appropriate markup from the external document highlighted may make the split view feel incomplete or unfinished. Third, some users feel more productive writing markup manually rather than using visual/design tools. By providing these users with the ability to easily jump between the visual tools and the markup, the system gives them the ability to use whichever view they are comfortable with without abandoning the design surface in favor of only the markup.
Code editor panel 400 includes a primary editor sub-panel 402 and a secondary editor sub-panel 404. The primary editor sub-panel 402 displays the markup for the primary document. The secondary editor sub-panel displays the related markup and code files that the primary document uses. From the related files view, a user can select other related files that the user would like to see, including related HTML files, related CSS files, and related JavaScript (JS) files. Sub-panels 402 and 404 according to one embodiment are positioned immediately adjacent to each other, and have the same height (in a vertical direction), but different widths (in a horizontal direction). In one embodiment, sub-panels 402 and 404 have a default size in which sub-panel 402 is larger than sub-panel 404 and occupies about 60% of the total area of the panel 400, while sub-panel 404 occupies about 40% of the total area of the panel 400. Sub-panels 402 and 404 are configured to be resized by a user. In one embodiment, the border 403 between the sub-panels 402 and 404 acts as a resize grip that allows a user to adjust the sizes of sub-panels 402 and 404.
In one embodiment, when a user opens a document with user interface 600 and has nothing selected in the artboard panel 604, live DOM panel 602, styles panel, etc., the panel 400 will show the markup for the currently active HTML document in the sub-panel 402 with the sub-panel 404 grayed out. Since nothing has been selected, the default behavior according to one embodiment is to show the very top of the markup with nothing selected. If the user selects an element via the live DOM panel 602 or the artboard panel 604 that is declared inside the currently active document (main.html) shown in sub-panel 402, the corresponding line of code is highlighted in sub-panel 402. Sub-panel 404 will not show anything, again, because nothing CSS-related (or HTML-related or JavaScript related) was selected.
Assume that a user selects a fragment element, called “B”, which is declared in an external document called fragment.html. This selection may be triggered via the live DOM panel 602 or the artboard panel 604. The end result of this selection will be that the markup in sub-panel 402 corresponding to this selection will be highlighted, and the HTML header at the top of the sub-panel 402 will be changed from “main.html” to the file name from where this markup is coming from (e.g., “fragment.html”).
If a user multi-selects HTML elements via the artboard panel 604 or live DOM panel 602, the markup of the last item selected is highlighted in sub-panel 402. If a user selects a CSS rule via a Styles pane, the selected line is displayed in the sub-panel 404. Assume that a user selected a CSS rule with the selector “#contentHost” from the Styles pane.
From a CSS Attributes panel in user interface 600, a user can select a winning entry. In one embodiment, when a user selects a winning entry, sub-panel 404 is empty and grayed out. If the user is in “winning mode” and gives focus to a value editor from the CSS properties panel, the appropriate CSS rule is highlighted in sub-panel 404.
In one embodiment, if a user selects Inline rule from the CSS attributes panel, sub-panel 404 will be grayed out. A user can easily switch over into the HTML view and see the inline rules instead.
In one embodiment, the content for sub-panels 402 and 404 are synchronized based on selections on the live DOM, artboard, CSS Properties panel, and Styles Panel, of the user interface 600. In one embodiment, synchronization between the sub-panel 402 and the artboard and live DOM is two-way. A selection in the sub-panel 402 will result in the appropriate content getting selected in the object tree and artboard. In one embodiment, for sub-panel 404, the synchronization is one-way. A selection inside the sub-panel 404 will not result in a different rule getting selected.
In one embodiment of method 1200, the generating a user interface and the generating as part of the user interface a code editor panel are performed by at least one processor. In one embodiment, the content of the primary document and the content of at least one of the related files in method 1200 are displayed at the same time by the code editor panel. The code editor panel according to one embodiment is configured to be used to edit the content of the primary document and the content of at least one of the related files at the same time. In one embodiment, the providing categorized access at 1208 includes displaying on the secondary editor sub-panel: (1) a first list of all Cascading Style Sheet (CSS) files related to the primary document; (2) a second list of all JavaScript files related to the primary document; and (3) a third list of all HTML files related to the primary document. In one form of this embodiment, selection of one of the files in the first list, second list, or third list causes content of the selected file to be displayed in the secondary editor sub-panel.
The techniques described herein are not limited to HTML and Web development. These techniques can be used when authoring applications for any platform that has a notion of related support files used by a main document. For example, in the xaml platform, the system could show resource dictionaries related to a main xaml file.
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.
