THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Overview
Search
Other MyFaces Extensions
Community
- [Mailing Lists]
Development
Sponsorship
Unknown macro: {iframe}
Page History
Navigation
| Page Tree Search |
|---|
- Index Page
Page Tree Column Section
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
| Wiki Markup | ||||
h1. Navigation {pagetreesearch} * [Index Page|EXTSCRIPT:Index] {pagetree} {column} {section} h1. 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. h2. 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. h3. Setup To use the components following namespace has to be included: {code:xml} xmlns:exs="http://myfaces.apache.org/ext-scripting" {code} |
Example:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <!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> {code} h3. The Compiler Output Component One of the cornerstones of |
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:
| Code Block |
|---|
} Java Compiler, Error on line: org/apache/myfaces/javaloader/blog/Blog.java:30:class, interface, or enum expected30 {code} |
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
| Wiki Markup |
|---|
action {iframe:src=http://www.youtube.com/embed/v56ru9ZJyhQ|width=640|height=480|frameborder=0|class=youtube-player|type=text/html} {iframe} |
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>
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <exs:compilerOutput errorsLabel="Errors:" warningsLabel="Warnings:" scriptingLanguage=""/> {code} h5. 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 | !compiler_output.png|border=1! Image: Compiler Output Component h3. 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: {code} |
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:
| Code Block |
|---|
INFO: [EXT-SCRIPTING] Tainting: org/apache/myfaces/javaloader/componentTest/MyComponentTag.java
{code}
|
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <exs:taintHistory noEntries="5" /> {code} h5. 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 | h2. 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) h2. Page and Resource Reloading h3. 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. h3. 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|http://weblets.dev.java.net]*. !source-resource.jpg|border=1! Image: Page and Resource Reloading The central point of setting up your resource reloading are two configuration parameters * |
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.MyFacesReroutingResourceResolve
...
r.
...
For
...
further
...
reference
...
please
...
also
...
visit
...
out
...
...
...
...
...
.
Overview
Content Tools
Apps