You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Current »

Navigation

Introduction

Congratulations by the time you have reached this section, you probably have mastered the basics of Ext-Scripting, you probably already can edit your local files and have them refreshed on the fly.

Under normal circumstances you, should be set up by now and you can start coding happily. However since this is a framework based reloading mechanism it is wise to dig a little bit deeper and to know what is happening under the hood and why things behave like they do. If you are interested then read on.

Helper Components

Additionally to the standard reloading feature, Ext-Scripting provides two components which hopefully will make the life of every programmer easier.

  • The Compiler Output Component
  • The Change History Component

Note currently and for the foreseeable future only Facelets as page description language will be supported by the components.

Setup

To use the components following namespace has to be included:

xmlns:exs="http://myfaces.apache.org/ext-scripting"

Example:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:exs="http://myfaces.apache.org/ext-scripting"
      xmlns:h="http://java.sun.com/jsf/html">
<h:head>

The Compiler Output Component

One of the cornerstones of Ext-Scripting is the dynamic recompilation. Every file changed, is reloaded, while you hit refresh on the browser. Now, under normal circumstances, the compiler errors and warnings are written to the console log
as following:

 Java Compiler, Error on line: org/apache/myfaces/javaloader/blog/Blog.java:30:class, interface, or enum expected30

Now, trying to catch those errors within the log is "mildly spoken" annoying and time consuming. Exactly for bypassing this problem a compiler output component can be used either in your page or preferably in a second page.

The following Video shows the compiler output component in action

Video: Compiler Component in Action

Usage of the Compiler Output Component

The compiler output component currently is presented as Facelets only component as follows</p>

<exs:compilerOutput errorsLabel="Errors:" warningsLabel="Warnings:" scriptingLanguage=""/>
Following attributes can be used

Attribute Name

Possible Values

Description

errorsLabel

All values are allowed

A Label which is displayed in above all errors to notify the user that the error section starts here

WarningsLabel

All values are allowed

A Label which is displayed in above all errors to notify the user that the warning section starts here

scriptingLanguage

Java, Groovy or an empty String

Scripting language filter, here you can set which scripting engines compile errors should be displayed, currently Java or Groovy are supported as values if you leave the attribute empty or set nothing then everything is displayed

Image: Compiler Output Component

The Change History Component

The second cornerstone of Ext-Scripting is change tracking and dependency detection. Now if you have changed a file, Ext-Scripting tracks the changes and also marks most classes which have a dependency to your class as changed.

Again usually the output is pushed into the log as following:

INFO: [EXT-SCRIPTING] Tainting: org/apache/myfaces/javaloader/componentTest/MyComponentTag.java

Again, to get a quick overview within your running page, or preferably an extra page, you can use a specialized component which gives you a quick overview over the change history of the system.

Here our change history component comes into play. With it you can track a certain number of changes done over time including their marked dependencies.


Image: Change History Component in Action

The change history component can be currently used in Facelets only as follows

<exs:taintHistory noEntries="5" />
Following attributes can be used:

Attribute Name

Possible Values

Description

noEntries

The <Integer Value> number of entries of the current history

A positive Integer value which shows the last N entries of your history beginning with the latest change marker on top

Debugging

Ext-Scripting automatically compiles with the debug flags on. Debugging against a running configuration should be no problem. If the debugger can be pointed towards the sources, debugging should work without any side effects.

Due to the fact that the debugger can pick up the debug info from the newly compiled class files. (Note - the class files are not altered in any way so in any case you just deal with normal Java classes)

Page and Resource Reloading

Introduction

One of the goals of Ext-Scripting is to prevent unnecessary restarts and redeploys during
development. To enable this, it provides custom functionality outside of the scope of providing scripting
capabilities.
One of those features is the page and resource reloading from your source directories.

Basic Functionality

Pages and web-resources like CSS files or images are loaded from your resource directory without having to redeploy the web
application, changes on them can be watched on the fly simple by a browser reload. There is no need to adjust
your web application server or your IDE for auto deployment mechanisms. Unnecessary web application restarts for changed resources can be avoided that way.

Note while page reloading works on the fly for both JSF 1.2 and JSF 2.x+, resource reloading
only works for JSF2.x+, if you need similar functionality for JSF 1.x you can use
a third party resource loading library like Weblets.
Image: Page and Resource Reloading

The central point of setting up your resource reloading are two configuration parameters

  • org.apache.myfaces.extensions.scripting.resource.LOADER_PATHS
  • facelets.RESOURCE_RESOLVER

The first parameter org.apache.myfaces.extensions.scripting.resource.LOADER_PATHS defines the root path for your resources (aka everything web related, like xhtml facelet templates css files etc..). Note, despite being called resource LOADER_PATH in most cases this path will just be pointed to the your source web application root directory.
(ie: src/main/webapp in a standard Maven2 structure or <project-root>/webapp for a standard Eclipse project structure. The name resource just refers to the fact that for Ext-Scripting every web related file is seen as resource
The second parameter facelets.RESOURCE_RESOLVER is responsible for enabling the resouce loading of Facelet templates and pages, since Facelets does not have an auto plugging mechanism this has to be set to a standard value which is org.apache.myfaces.extensions.scripting.jsf.facelet.MyFacesReroutingResourceResolver.
For further reference please also visit out Configuration Entries Overview Page.

  • No labels