THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Overview
Search
Other MyFaces Extensions
Community
- [Mailing Lists]
Development
Sponsorship
Unknown macro: {iframe}
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: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 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} 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 {iframe:src=http://www.youtube.com/embed/v56ru9ZJyhQ|width=640|height=480|frameborder=0|class=youtube-player|type=text/html} Video: Compiler Component in Action h4. Usage of the Compiler Output Component The compiler output component currently is presented as Facelets only component as follows</p> {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} 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. !change_history.jpg|border=1! Image: Change History Component in Action The change history component can be currently used in Facelets only as follows {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 * 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 [Appendix: Configuration Entries Overview page|EXTSCRIPT:configentries]. |