To create a Java CFX tag, create a class that implements the CustomTag
interface. This interface contains one method, processRequest
, which is passed Request
and Response
objects that are then used to do the work of the tag.
The example in the following procedure creates a very simple Java CFX tag named cfx_MyHelloColdFusion
that writes a text string back to the calling page.
import com.allaire.cfx.* ; public class MyHelloColdFusion implements CustomTag { public void processRequest( Request request, Response response ) throws Exception { String strName = request.getAttribute( "NAME" ) ; response.write( "Hello, " + strName ) ; } }
javac -classpath cf_root\lib\cfx.jar MyHelloColdFusion.java
Note: The previous command works only if the Java compiler (javac.exe
) is in your path. If it is not in your path, specify the fully qualified path; for example, c:\jdk1.3.1_01\bin\javac on Windows or /usr/java/bin/javac on UNIX.
If you receive errors during compilation, check the source code to make sure you entered it correctly. If no errors occur, you successfully wrote your first Java CFX tag. For information on using your new tag in a ColdFusion page, see "Calling the CFX tag from a ColdFusion page".
You call Java CFX tags from within ColdFusion pages by using the name of the CFX tag that is registered on the ColdFusion Administrator CFX tags page. This name should be the prefix cfx_
followed by the class name (without the .class extension).
You can now call the tag from a ColdFusion page.
<html> <body> <cfx_MyHelloColdFusion NAME="Les"> </body> </html>
http://localhost/cfdocs/testjavacfx.cfm
ColdFusion processes the page and returns a page that displays the text "Hello, Les." If an error is returned instead, check the source code to make sure you have entered it correctly.
Implementing a Java CFX tag requires interaction with the Request
and Response
objects passed to the processRequest
method. In addition, CFX tags that need to work with ColdFusion queries also interface with the Query
object. The com.allaire.cfx package, located in the lib/cfx.jar archive, contains the Request
, Response
, and Query
objects.
This section provides an overview of these object types. For a complete description of these object types, see CFML Reference.
For a complete example Java CFX tag that uses Request
, Response
, and Query
objects, see "ZipBrowser example".
The Request
object is passed to the processRequest
method of the CustomTag
interface. The following table lists the methods of the Request
object for retrieving attributes, including queries, passed to the tag and for reading global tag settings:
For detailed reference information on each of these interfaces, see CFML Reference.
The Response
object is passed to the processRequest
method of the CustomTag
interface. The following table lists the methods of the Response
object for writing output, generating queries, and setting variables within the calling page:
Method |
Description |
---|---|
write |
Outputs text to the calling page. |
setVariable |
Sets a variable in the calling page. |
addQuery |
Adds a query to the calling page. |
writeDebug |
Outputs text to the debug stream. |
For detailed reference information on each of these interfaces, see CFML Reference.
The Query
object provides an interface for working with ColdFusion queries. The following table lists the methods of the Query
object for retrieving name, row count, and column names and methods for getting and setting data elements:
For detailed reference information on each of these interfaces, see CFML Reference.
Each Java CFX class has its own associated ClassLoader that loads it and any dependent classes also located in the web_root/WEB-INF/classes directory. When Java CFX classes are reloaded after a change, a new ClassLoader is associated with the freshly loaded class. This special behavior is similar to the way Java servlets are handled by the web server and other servlet engines, and is required in order to implement automatic class reloading.
However, this behavior can cause subtle problems when you are attempting to perform casts on instances of classes loaded from a different ClassLoader. The cast fails even though the objects are apparently of the same type. This is because the object was created from a different ClassLoader and therefore is not technically the same type.
To solve this problem, only perform casts to class or interface types that are loaded using the standard Java classpath, that is, classes not located in the classes directory. This works because classes loaded from outside the classes directory are always loaded using the system ClassLoader, and therefore, have a consistent runtime type.
You can determine how the server treats changed Java CFX class files by specifying the reload attribute when you use a CFX tag in your ColdFusion page. The following table describes the allowable values for the reload attribute:
The default value is reload="Auto"
. This is appropriate for most applications. Use reload="Always"
during the development process, when you must ensure that you always have the latest class files, even when only a dependent class changed. Use reload="Never"
to increase performance, by omitting the check for changed classes.
Note: The reload attribute applies only to class files located in the classes directory. The ColdFusion server loads classes located on the Java classpath once per server lifetime. You must stop and restart ColdFusion Server to reload these classes.
A new instance of the Java CFX object is created for each invocation of the Java CFX tag. This means that it is safe to store per-request instance data within the members of your CustomTag
object. To store data and/or objects that are accessible to all instances of your CustomTag
, use static data members. If you do so, you must ensure that all accesses to the data are thread-safe.