EaselInOtherProjects

Contents

Re-using Easel

This document looks at different scenarios in which Easel functionality may be required and evaluates what changes would be required to fully support such scenario.

Each scenario starts with a table with two columns:

  1. project source files - what user edits and works with
  2. browser URLs - what browser shows upon project execution

Each table is followed by notes on what IDE must do to successfully provide following Easel features in the scenario:

  • Refresh On Save
  • JS Debugging
  • CSS Styling
  • HTML Navigator

UI changes, if any are required, are discussed too.

Scenario 1 - simple case of plain static files

Project Browser
index.html
app.js
style.css
/index.html
/app.js
/style.css

This is a scenario fully support by NetBeans 7.3. In this scenario there is 1:1 mapping between project sources and how these sources appear in browser.

Scenario 2 - JS based templating on client

Project Browser
index.html
page_content_template.html
app.js
style.css
/index.html into which page_content_template.html was merged

/app.js
/style.css

In this scenario client side templating is applied using a JavaScript library - a content of page_content_template.html is taken and included somehow into the resulting index.html page. How the template is included into resulting page is specific for JavaScript templating library being used. Because each templating library is different it is impossible to provide a generic solution which would answer queries like "which template file(s) was used to produce this HTML document?" and "how exactly was template merged into this HTML document?".

A template library specific solution may or may not be possible. For example in AngularJS case it should be possible to answer both above queries. It should be possible to ask AngularJS framework in runtime which template file was used to build the current page. Such template file would be included as is in main page in div with ng-view attribute. With this knowledge the HTML Navigator could be enhanced to understand that some nodes came from a different HTML template document.

  • Refresh On Save - if templates are static files it is easy to discover them via observing what network resources a page required in order to be constructed (a generic solution for any templating library)
  • JS Debugging - should just work
  • CSS Styling - should just work
  • HTML Navigator - without tight integration of used templating library the HTML Navigator view may in most of the cases present nodes as "newly created" despite them coming from a different static project source file

No UI changes necessary.

Scenario 3 - JS based templating on client with usage of compiled languages

Project Browser
index.html
page_content_template.html
app.coffee
style.scss
/index.html into which page_content_template.html was merged

/app.js compiled from app.coffee
/style.css compiled from style.scss

This scenario enhances scenario 2 with CoffeeScript and SCSS (or LESS) files. Assumption is that coffee and scss files gets compiled automatically upon their change. The implications for Easel features are:

  • Refresh On Save - include coffee->js and scss->css relationship in DependentFileQuery implementation
  • JS Debugging - use Source Maps to map low level JS debugging in WebKit into original CoffeeScript sources and to map breakpoints in CoffeeScript sources into compiled JS file running in WebKit; "Variables" view should ideally show only CoffeeScript objects/variables but is it possible with just Source Maps?? this will require more detailed evaluation
  • CSS Styling - new styling property sheets would have to be written for SCSS (or LESS) to capture the language features; similarly like in JS debugging case Source Maps could be used to map SCSS elements to compiled CSS and vice versa; this will require more detailed analysis
  • HTML Navigator - should work as in scenario 2

UI changes:

  • customization of CoffeeScript, SCSS (or LESS) compilers

Scenario 4 - server side templating, eg. JSF, JSP, PHP, etc.

Project Browser
index.jsf
template.jsf
header.jsf
app.js
style.css


/index.html is result of merging index.jsf and template.jsf and header.jsf


/app.js
/style.css
/jsf-resources/jsf-internal.js
/jsf-resources/jsf-internal.css

This shares all the problems of Scenario 2:

  • Refresh On Save - very difficult to implement; for example saving a Java file may or may not impact JSF page shown in browser
  • JS Debugging - should just work
  • CSS Styling - should just work
  • HTML Navigator - as structure of JSF (or JSP, PHP) can be completely different from HTML page rendered in the browser it may make no sense to try to merge live DOM with the original page. Even if JSF page is XHTML it may contain only JSF components and therefore no "HTML".

UI changes:

  • global IDE browser selection is not sufficient as it does not distinguishes "with NB integration" browsers. Ideally each project type (that is Java Web project and PHP Application project) would provide a new settings in their Run properties named "Browser" where used could select a browser as in HTML5 project type. While in HTML5 project type browser selection is implemented via concept of Configurations it is not necessary for Java Web and PHP to do the same - project's browser option can be a regular setting accessible only via project properties panel. Disadvantage of this approach is that browser is not selectable in toolbar but that maybe be either acceptable or might be resolved differently, eg via a separate browser selection combo box in main toolbar.

Scenario 5 - server side generated page, eg. Java Servlet

Project Browser
MyServlet.java
app.js
style.css
/MyServletURL
/app.js
/style.css
  • Refresh On Save - very hard to implement it correctly
  • JS Debugging - should just work
  • CSS Styling - should just work
  • HTML Navigator - there is no HTML to start with so not applicable

Required UI changes are the same as in Scenario 4.

Scenario 6 - server side scenario with compiled languages

Project Browser
index.jsf
template.jsf
header.jsf
app.coffee
style.scss


/index.html is result of merging index.jsf and template.jsf and header.jsf


/app.js compiled from app.coffee
/style.css compiled from style.scss
/jsf-resources/jsf-internal.js
/jsf-resources/jsf-internal.css

This is a combination of scenario 3 and 4.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo