---

Schliemann for all j2ee editors consideration

Goal of this document

The goal is to prove or disprove that the Schliemann editor engine is capable to cover all our existing a future features in HTML, JSP and XML editors or at least help to decide which direction we should go for 6.0 regarding the editing.

Motivation for the Schliemann consideration

• save resources
• decrease the amount of code making it easier to maintain
• get new features "for free" or with little effort

The Problem

Since there is a need to support many languages embeddings combinations in Netbeans 6.0 including our existing HTML, JSP and XML editors we need to somehow update the code to be able to work in the heterogenous environment.

How to solve

There are three ways of doing it:

1. migrate the editors to use Lexer
2. use just Schlieman engine
3. combination of the two above

Migrate the editors to use Lexer

The first case requires to reimplement a big amount of existing code which is now based on the old editor infrastrucure (Syntax). More detailed list of necessary steps is in J2EE Editors Features and Tasks for Netbeans 6.0 document. Moreover every new feature requires lot of handcoding and creates potentially lots of bugs.

Advantages:

• we know our code and know we won't regress in any of the features
• we know we can handcode most of the future features
• better for more complicated features

Disadvantages:

• it requires lot of work just to catch up with the previous (NB 5.5) features
• potentially we will create many new bugs in big codebase
• it is more demanding to create new features (e.g. navigator by Schlieman/vs. handcoded)

Use just Schlieman engine

This option means that we will replace our existing code by the Schliemann engine and achieve the same functionality. Some of the features cannot be fully-handled by Schliemann so there will still be some features hand-coded e.g. Java completion in JSP.

Advantages:

• we can save a VERY significant amount of work creating new features
• better bugs ratio - one Schlieman fix will fix all the editors
• improved maintanence - very short code
• probably easier unit testing

Disadvantages:

• there isn't any real Schliemann deployment - can we belive it will really work?
• harder to customize - we need to hand-code anyway - how to cooperate then
• we are not sure now whether Schlieman can cover even some important use cases (especially for JSP)
• less flexibility to "choose the way how we implement" some features.
• AFAIK no reasonable APIs so far
• potential performance problems

Use just Schlieman together with our hand-coded editors

It would be nice if Schliemann provided some reasonable APIs so we can build some of the future features like HTML/JSP navigator on top of Schliemann.

TBD

HTML/JSP/XML features

The following list contains our current editor features with a short description of how the feature works and how it could possibly be migrated to Schliemann. Motivation of this effort is to see if it is possible to cover our existing features by Schliemann, or whether they are so complicated so Schliemann can't handle them. In such case we must be assured that it is still possible to implement them using a hybrid approach.

How do we estimate the time needed to implement features using the Schileman engine? I can see 3 cases here:

• feature already supported (no effort required)
• feature can be supported, but requires some effort (how much?). Once implemented we will get this feature for new languages with no effort
• feature must be hand-coded, although it may reuse the Shlieman engine to some extent

HTML

Current features:

Feature	Description	Estimate to lexerize [engineer/day]	Schliemann'izable
coloring	regular code coloring	3	yes
regular CC	We can complete html tags and entity references according to various HTML specifications. We read the spec. from the HTML page prolog.	2ed	yes
CC follows quotation type	If user types <h1 align=' and invokes CC the items will the follow the quotation type ' or "	0.1	?
CC follows case	The completion checks if the user types uppercase of lowercase and completes accordingly	0.2	?
quotes autocompletion	<h1 aling + = => <h1 aling=""	0.1	?
completion documentation	We offer an HTML documentation of each CC item	1	probably
endtag autocompletion	we automatically offer closing tag by CC if user types an open tag	0.5	?
code formatting / indentation		3	yes?
html folding	just reqular folds for open - close tags and comments	3	yes
tag matching	open/close tag mathing (highlighting)	0.2	?
palette	we provide common HTML tags in the paletter in two categories	?	N/A
view/run actions	we can view a local file in the HTML browser or deply the webmodule and show the deployed page	N/A	? will we need our own DataObject?

Future features:

Feature	Description	Estimate handcoding [engineer/day]	Estimate Schliemann
HTML navigator	Show the file structure and allow to navigate to the code	10ed (Using SyntaxElement)	2
Error checking	Show errors/warnings for errorneous or deprecated code (unmatched closing tag, ...)	10ed (Need to get a parser)	2
Hints	Provide quick-fix actions for some of the errors	?	?
Hyperlinking	Be able to jump to referred files	2	?
Navigation to CSS file for HTML elements		3	?
Semantic coloring based on CSS style	mark elements whose rendering is defined by CSS	3	?

JSP

Current features:

Feature	Description	Estimate to lexerize [engineer/day]	Schliemann'izable
coloring	code coloring for JSP and HTMl tags, java code in scriptlets and expression language. The jsp tags coloring is connected to semantic analysis of the page - provided by Jasper parser.	5ed	yes (problematic beause of the lexer-semantic analysis dependency)
code completion	We can complete JSP tag names, directives, their attributes and values. The values completion can be for java classes, files, true/false values, bean names etc. We also support code completion in java scriptlets/expressions/declarations and code completion for expression language. In EL completion we offer default objects and beans.	4	partially
CC follows quotation type	If user types <h1 align=' and invokes CC the items will the follow the quotation type ' or "	0.1	?
CC follows case	The completion checks if the user types uppercase of lowercase and completes accordingly	0.2	?
quotes autocompletion	<h1 aling + = => <h1 aling=""	0.1	?
completion documentation	We offer HTML/JSP/java documentation of each CC item	2	yes
endtag autocompletion	we automatically offer closing tag by CC if user types an open tag	0.5	?
code formatting / indentation		3	yes?
jsp tags folding	reqular folds for JSP/HTML open - close tags and comments. We also creates a fold for groups of JSP directives.	3	yes
tag matching	open/close tag mathing (highlighting)	0.2	?
palette	we provide common JSP/HTML and custom tags in the paletter in several categories	?	N/A
hyperlinking	allows to jump to external files, java classes and beans; works in JSP/EL and java code	1	?
error highlighting	we shows JSP page errors gotten from the JSP page static analysis done by jasper parser	0.5	no

Future features: (just those not inherited from HTML editor)

Feature	Description	Estimate handcoding [engineer/day]	Estimate Schliemann
JSP navigator	Show the file structure and allow to navigate to the code. The navigation tree will include also HTML and javascript structure.	10 (Using SyntaxElement)	2ed
Live templates	Provide LT for example for JSTL or JSF tags	?	N/A
Hints for parser errors	For example taglib import hint for unknows JSP custom tag	?	N/A
Drag & Drop from explorer to editor	pictures, css, other files underneeth docroot	?	N/A
cc for attribute values	like color chooser, file chooser etc.	?	N/A

XML

Just a brief list of thoughts on XML support:

• Very rich code completion - a need to parse DTD/Schema
• We have a Grammar provider API used by CC infrastructure
• We have navigator now
• We can get errors easily by XML parser

Open questions

• Does Schliemann requires to have just one its DataObject? (This would probably complicate many things)