NetBeans: WebApps
Editor User View
Last changed: August 16, 2002
Changes: available in
CVS
Author: Petr Jiricka, Sun Microsystems/NetBeans
- Abstract:
- This document proposes new features and enhancements in the NetBeans JSP editor, and explains the benefits of each feature and enhancement. It should be considered as an input for task prioritization for the S1S Dublin release.
- Contents:
For the purpose of this document, it is assumed that the primary users of the JSP editor are the following types of users:
- Web programmers. These will typically program application logic (both business and presentation logic) in Java. They may also design the structure of the database, and integrate the application with additional capabilities, such as mailing, authentication, backend integration, integration with payment servers etc. Users of this type will typically design the aspects of JSP pages, which involve UI components populated with data from dynamic data sources, navigational elements, client-side validation, elements of input forms and other dynamic features.
They will also integrate the JSP page with the server-side logic.
These users may use the composite view pattern to break the page into easily manageable pieces.
It is expected that these users have some experience in JSP including tag libraries, some experience in Java, some knowledge of JavaScript, and basic knowledge of HTML. It is not expected that these users know the advanced features of HTML, such as style sheets or DHTML, or that they are proficient at advanced features of JavaScript such as dynamic menus etc.
- Page designers. These will typically design the visual aspect of the pages, including any graphics, layout, JavaScript-based menus, animations, fonts, color scheme, scrolling text and other visual elements which are not directly tied to the application's business logic.
Presumably, these users typically use additional tools for their work, such as image processing tools such as Adobe Photoshop and web design tools such as Macromedia DreamWeaver. They will use the IDE either if they are more comfortable hand-editing web pages, when the particular tasks they need to achieve are not supported by their web design tools, or when their web design tool does not integrate well with JSP. They are proficient in HTML and graphics design. They may not be knowledgeable and familiar with JavaScript, since today's web design tools generate JavaScript code to accomplish advanced tasks, and it is usually unnecessary to modify (or understand) the generated code.
The two types of users will cooperate in one of the following two primary ways: Either, the web programmer creates a skeleton of a JSP page, which is then passed to the page designer, who designs the page graphics and layout. Or, the page designer designer designs the page graphics and layout and passes the page to the web programmer (possibly as a HTML page, not a JSP page), who then adds the dynamic behavior, splits the page to several smaller ones using the composite view pattern etc. This whole process may be iterative, so the team members who fulfill the respective roles will pass the page to each other several times.
In some not very common cases the same person may have both the role of the web programmer and the page designer.
The second assumption we will make is that the coding in the JSP editor represents a significant portion of both the web programmer's and the page designer's time (50% or more). Other tasks that the two team members perform are less time-consuming.
This section describes the features currently supported by the JSP editor in the IDE, as well as by the Java editor, and the benefits for the users. The information about Java editor is included for easier comparison of the similarities, differencies and inconsistencies of the two editors.
The primary feature of the JSP editor is the syntax coloring of HTML-based JSP files written using the standard JSP syntax. The editor distinguishes the parts of JSP written in HTML, parts written using JSP directives and tags (including custom tags) and parts written in Java, using different background colors of the text. This makes the job of the Web Designer and the Web Programmer easier, as they can immediately distinguish the dynamic portions of the page (on which the Web Programmer focuses) from the static ones (on which the Web Designer focuses). The editor does not distinguish the text written in JavaScript, or in the JSP Expression Language (as defined by the JSTL and JSP 2.0).
The second major feature of the JSP editor is the code completion. The completion feature is quite sophisticated compared to our competitors, although it is still far from perfect. The completion gives the user a context-based choice of options, that are in any given moment allowed in the editor. This has several benefits:
- Serves as hint in cases that the user can not remember the syntax of a particular JSP tag, directive or attribute, HTML tag or attribute, or a Java variable, class, field or method.
- May speed up typing of long symbols.
- Serves as hint for application-specific information, such as the available tag libraries, or names of beans in the current page's scope.
While the first benefit is probably the biggest one, the other two are not as significant. The second because most tag or attribute names are short, the third because the IDE provides only minimal support in this area.
Also, the user does not get help in case of JavaScript syntax, or the syntax of the JSP Expression Language.
The third (and relatively minor) feature of the JSP editor is the matching of corresponding < or > sign. When the editor cursor is on one of these signs, this feature allows the user to easily see the corresponding one.
The Java editor provides corresponding features to the ones described above, plus several additional ones that don't have an equivalent in the JSP editor. In some cases, the difference between the Java editor and the JSP editor bahavior creates the feeling of inconsistency.
The major ones is the automatic indentation of Java files. This allows the user not to worry about manually indenting the files, as the tool will take care of this for the user. This feature would be useful and desirable in the HTML and JSP editors too.
Another significant feature is the fast Javadoc window. This window is an enhancement of the code completion feature. When the completion selection list is displayed, the window shows the Javadoc for the method, field or class currently selected in the list. This feature could easily translate to the JSP editor.
A minor, but very convenient feature is the fact that the Java editor provides context-sensitive help (Javadoc) for the symbol that the cursor is on, via a hotkey.
The last significant feature is the error underlining in the Java editor. The editor underlines (in a manner similar to spell-checking software) the syntax elements that are currently wrong in the text.
This section presents a wishlist of new features and enhancements that the users would benefit from. Clearly, the resource constrainst do not allow all the features to be implemented in the Sun ONE Studio 5 (Dublin) time frame, so further prioritization is desired. The proposed features appear in no particular order.
Having syntax coloring for Javascript code would allow easier navigating in code when modification to Javascript code are needed. In the case when Javascript code is not expected to be modified (i.e. code generated by DreamWeaver and other design tools), JavaScript coloring is not helpful.
For JavaScript completion, the situation is similar. For the completion to be truly useful, it would need to understand the structure of the HTML (JSP) document, and would need to be aware of the components in the document's syntax tree. This is a very non-trivial problem to solve.
It is assumed that Javascript support should be available in HTML files, not only in JSP files.
See also issue
8600.
Currently only some Java variables are offered in Java code completion in JSP. These are variables which appear in
jsp:useBean declarations and the implicit objects specified by the JSP spec. Variables declared in JSP scriptlets and declarations are not considered for JSP completion. Also, variables which are stored in one of the standard scopes (page, request, session, application) are not considered - but supporting those would be a very challenging task.
Supporting variables in scriptlets and declarations will help users who use Java code in their JSPs, which has been recognized as a bad design practice, nevertheless it is still quite common.
Currently the HTML completion is uses upper case. However, since HTML is a case-insensitive language, and HTML case is a matter of user preference more than anything else, the completion shouls support both lower and upper case. Ideally, the completion should find out from the existing portion of the page what case the user is using, and should use that.
When the user uses the completion to complete the opening HTML/JSP tag in the editor, it would be useful if the completion typed the closing tag at the same time, with correct indentation. So after choosing
<table>, the editor will automatically type
</table> on the next line, and put the cursor after the opening tag. There will be variations - if it is usual to enter attributes for the tag, the cursor will be placed before the closing
> of the opening tag, so that attributes can be typed easily. Or, if the tag is usually a non-pair tag, such as
<br>, the closing tag will not be auto-typed.
See also issue
12935. JSP and HTML text should be automatically indented.
The JSP Expression Language, introduced by the Java Standard Tag Library, and the JSP 2.0 specification, defines a new type of expressions, which can be used in pages. These expressions may appear in JSP attribute values or in free JSP text, and take the form
${ expression }. In tandem with JSP tag libraries, they are intended as an alternative to Java code embedded in JSP pages. It would be useful to provide syntax coloring for them - distinguish them using the backgroung color from other JSP syntax elements, and distinguish various subelements of the expression language from each other using foreground color.
Code completion could be based on similar principles as Java completion: navigating between objects which form an object graph, starting from a set of variables which are applicable in the current page scope. The code completion would greatly benefit from knowing the variables defined in individual JSP scopes (page, request, session, application), but even without this knowledge it would be extremely useful for the Web programmer, mainly in the area of tying the application-specific business logic to the presentation layer.
The main benefits of the JSP/HTML code completion for the user is that it can auto-complete tags, directives and attributes. The user would also benefit if completion of attribute values was supported. For example, in tag
<img align="left" src="graphics/bullet.gif">, it would be useful if the completion offered all applicable values for attribute
align, which are
left, right, middle, top, bottom etc. Or for attribute
src, it could offer names of files relative to the current file's location. This applies to both HTML and JSP tags, and for JSP directives.
Currently the editor can do this only to a very small extent. For example, it can offer the list of scopes in the
jsp:useBean tag, or the list of tag library URIs in the
taglib directive. For the vast majority of attributes, attribute value completion is not supported. A more complete support would be a great benefit to both web developers and page designers, since the applicable attribute values are usually much more difficult to remember than tag or attribute names, and users have to spend a lot of time looking up help to find out the exact option they need.
The main difficulty with the implementation of this feature is the fact that while the support for completion of tag and attribute names only requires the knowledge of HTML or JSP syntax, support for completing attribute values requires the IDE to have semantic and domain knowledge of the particular HTML and JSP tags, which is different for each attribute, and has to be implemented on a per-attribute basis. So implementing such a support for a reasonable set of attributes would be very labour-intensive.
Moreover, the set of JSP tags is not closed, as new tags may be introduced by tag libraries. So while supporting value completion for HTML is a "closed" task, in the case of JSP it is an "open" task. Completion must be implemented on a per-tag-library basis. The obvious candidate for a tag library for which this feature could be supported is the Java Standard Tag Library - JSTL.
The Java editor supports getting context help for the current symbol in the editor by pressing the context help hotkey. That way, the user will get JavaDoc for the particular class or method that the cursor is on.
A similar feature is conceivable for JSP and HTML. For HTML, the hotkey would show help for a particular HTML tag, containing information similar to some HTML references available on the internet, such as
http://vzone.virgin.net/sizzling.jalfrezi/.
For standard JSP tags and JSP directives, the information will be similar to that in the JSP Syntax Card:
http://java.sun.com/products/jsp/pdf/card12.pdf. For custom tag libraries, help will probably need to be constructed on a per-tag-library basis. The obvious thing to do would be implementing the help for the JSTL.
Additionally, context help could be also available for JSP Expression Language constructs.
A new feature in NetBeans 3.4 is to allow show Javadoc for the selected item in the code completion list. This is implemented as a small window which pops up and disappears automatically, so it provides useful help, but does not distract the user as much as a full-screen web browser window. Currently this works for any Java files whose source is mounted in the IDE.
A couple of improvements could be considered in the context of JSP: First, the help is currently not available for Servlet/JSP APIs. This is caused by the approach which requires source code in order to display the help - and we don't distribute (and are not legally allowed to distribute) the servlet API sources. In order to support the help for Servlet/JSP APIs, the information would have to be gathered from Javadoc, or some other way. This will require some support from the base editor module that is currently not in place.
Secondly, it could show help for HTML and JSP, including all HTML tags, standard JSP tags and directives, custom JSP tags and the Expression Language. The information displayed in the help would be the same as the information used in the Context help hotkey feature. This may require some support from the base editor module that is currently not in place.
Toolbar, which would enable fast insertion of code snippets into the JSP code. This would be both a productivity benefit (faster than manually typing the code) as well as a hint to users who are not intimately familiar with HTML and JSP, or who just don't remember the exact syntax. For a more detailed proposal see
http://web.netbeans.org/doc/tag_toolbar_proposal.html.
NetBeans 3.4 has a new feature which is a toolbar containing buttons and potentially other controls which provide access to editor-related functionality. This toolbar can be used to provide easier navigation from JSP to the generated servlet and back.
I propose we add a button and a list box to the toolbar of both the JSP editor and the generated servlet editor. The button will implement the
Show code in servlet and
Show code in JSP actions, e.g. place the cursor to the location in the servlet (or JSP, respectively) corresponding to the current location in the JSP (or servlet, respectively).
The list box (selection box) will implement the side-by-side debugging feature, as requested by the BugTraq/BugParade bug 4487112. There will be four choices, implemented by icons (so as to save space on the toolbar): tabbed window, horizontal split, vertical split and separate windows. The meaning of the four options will be the following. Tabbed window view displays the JSP and the servlet in two tabs of the same window. So it is not possible to see them at the same time. This corresponds to the current state, and will be the default option. Horizontal split view displays the JSP and the servlet side by side in the same window, one above the other. The vertical split is similar, except that the views are split vertically. The separate windows view places the servlet in a new window.
Currently when the JSP is opened in the editor, the default encoding is used as its character set. Correct would be to determine the encoding from the
page directive of the page. This should also be consistent with how encoding is determined for HTML files. See issues
18652,
18651 and
7427.
Currently when the cursor is placed on an opening or closing tag, and its < or > sign, the corresponding sign is highlighted. This is not always very useful, since the two signs are usually very close to each other, there is not a need for hints. It would be useful to instead (or additionally) match the closing tag when the cursor is on the opening tag, and vice versa.
Various small enhancements in the area of JSP code completion:
- Also offer the attribute that the cursor currently on, see issue 13523.
- Provide icons for the items in the completion item list, similarly to the Java indentation. This would help distinguish various types of items: HTML tags, JSP tags and JSP directives, to name a few.
- Provide a better caption of the completion window, rather than the non-informative JSP Completion.
- Also offer directives after a < sign, see issue 20918
Underline erroneous syntax in JSP editor as the user types, similarly to how the Java editor does it.
For JSP files in the XML format, open them in the XML editor, rather than in the JSP editor. Then these files would reuse all features provided by the XML editor, which is owned by the NetBeans XML team.
When selecting an item from the HTML completion list, there are two ways to select any given item: by pressing
Enter and by pressing
Shift+Enter. The two options differ by what text will be written into the editor. For example, when selecting an HTML attribute one option will type only the attribute name, whereas the other one will type the name, the equal sign and apostrophes, so that the value can be directly typed. It is believed that this feature is not used by a vast majority of the editor users, and that most users use only one way. I propose to only keep one way of selecting an item, and give the behavior that is most intuitive and useful.
