• Home
• com.jsftoolkit
• components-base
• 0.9
• source code
• CustomComponentCode.wiki.txt

×

Project download

Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance.
Project price only 1 $

You can buy this project and download/modify it how often you want.

com.jsftoolkit.doc.CustomComponentCode.wiki.txt Maven / Gradle / Ivy

== Adding Behavior ==

Sometimes your components need to do more than render HTML. Or you need to specify a complex default value for a property in a way that the generated code cannot accommodate. Rather than throw out the generated code, you can instead sub-class the generated code and have your sub-class registered instead.

This approach provides a clean separation between generated code and your component's unique behavior. Your sub-class is free to override any generated or super-class methods, as they are all non-^final^ and either ^protected^ or ^public^.

=== Making the Generated Class Abstract ===

If you specify that your component is ^abstract^ (see [[ComponentInfo]]), then the class that is actually generated will be named ^className + "Base"^.  The class registered in ^faces-config.xml^ will be the class name you specified, but it is expected that you will write that code yourself.  e.g. a spec of
{{{
	public static final String PACKAGE = "com.mycompany";

	public static final String CLASS_NAME = "MyComponent";
	
	public static final boolean ABSTRACT = true;
}}}
Will cause the generated code to be for "com.mycompany.MyComponentBase".  What will be registered in 
^faces-config.xml^ will be "com.mycompany.MyComponent".  See the javadoc for [javadoc/com/jsftoolkit/gen/info/ClassInfo.html ClassInfo].

Note that you can do the same for the renderer via ^RENDERER_ABSTRACT^.

=== Registering a Different Class ===

If you prefer to explicitly define what class is registered, having a different component class registered in faces-config.xml is straight forward:
{{{
	public static final String REGISTER_CLASS = "com.yourcompany.YourSubClass";
}}}
In the XML file, the attribute ^registerClass^ on the ^config^ element specifies the class to register.  Note that this property is just a string, and the class named does not need to be compiled at code generation time.

=== Generating Additional Properties ===

When you were just using the HTML template mechanism, all of your component's attributes were only needed at render time.  For this purpose, they were treated as strings and were allowed to be null.   When adding behavior, you will most likely need typed properties that may even be unrelated to rendering.

Constants of type ^PropertyInfo^ in your specification class let you define these properties. e.g.
{{{
	public static final PropertyInfo MAX_SIZE = new PropertyInfo(Integer.class,
			"maxSize", "0");
}}}

The first parameter is the class, the second is the name of the property, and the last string is the code corresponding to the default.  This code will be evaluated verbatim to provide the default value.  Since the example above is an integer, the code string is ^"0"^. If it were a string property, the string would be something like ^"\"default value\""^.

=== Caveats ===

Remember that any classes referenced by your component specification (whether or not it is an XML file or a Class) must be compiled before your component can be generated.  You must take care to avoid circular dependencies, e.g. if a class referenced by your specification depends on the generated component code, neither will compile.  This is why the name of the component class to register is a string constant, since it should always depend on the generated code.

== Extending Another Component Class ==

You components are free to extend any other component class. Components that extend ^UIData^ will most likely not make use of [[HtmlRenderer]] directly. The super class can be specified for the tag and component class (see [[ComponentInfo]]).

== Not Generating Anything ==

You can make full use of [[HtmlRenderer]] and the other base and utility classes without using code generation. However, what is being generated is code like getters and setters that, if written by hand, is tedious and error prone, so generating them is strongly recommended.  You may also use the [javadoc/com/jsftoolkit/gen/ConfigurationUpdater.html ConfigurationUpdater] independently of the [javadoc/com/jsftoolkit/gen/TemplateComponentGenerator.html TemplateComponentGenerator].