There are several basic categories of requirements for making
Creator-friendly components:
* Component architecture - Creator likes components to have concrete
properties,
not rely on the generic attributes capability of UIComponent. This
allows the tool
to do things like attach property editors and customizers to the
individual properties,
using standard JavaBean property management techniques.
* In particular for Creator, you'll want a "style" property like the
standard JSF components.
If you're using the default absolute positioning mode, this is where
the CSS position
information is persisted.
* Rendering architecture - Creator calls the renderng methods at design
time to generate
the visualization, so the renderers need to be able to execute
successfully in that case.
(You can create specialized design time appearance if you want, by
using Beans.isDesignTime()
to check whether you are at design time or run time). In addition,
the renderers should:
- Create well-formed markup (easily done if you use ResponseWriter)
- In renderers that deal with children and facets, such as Tree or
Table,
use the second argument on startElement() calls to indicate which
component caused this particular output. The tool uses this to
figure
out which component to select when you click on the design surface.
- Emitting a single outermost element helps the tool identify the
outer
boundaries of a component. That's also where the style attribute
content
(containing the positioning information) would be rendered.
* Tag architecture - the JSP tags associated with your components are
not executed
at design time, so they should not have any logic other than copying
in the relevant
attributes with type conversions. (Of course, you'll want this to be
true for components
to work with non-JSP view handlers anyway).
* Design time behavior - This is provided in two different ways:
- Static information about component classes are provided by
JavaBeans "BeanInfo" classes associated with each component.
In turn, these BeanInfo classes can be hand coded, or derived
from extended faces-config.xml content that conforms to a
Creator specific DTD. (NOTE - as JSR-276 comes to fruition,
MyFaces will also want to support the standard metadata formats).
- Dynamic behavior (such as "when you drop a table component
on the design surface, create a bunch of dummy rows and columns")
is created by providing "DesignInfo" classes for each component,
that conform to a Creator-specific design time API (which has also
been submitted as a starting point for JSR-273, which MyFaces will
also want to support when it's done).
There will shortly be some components on
java.net
that come complete with design time behavior, which we'll be able to
use as examples for what is required. In the mean time, one of my
colleagues (Edwin Goei) has posted some more detailed documentation
about how this stuff works. See the "Writing Custom Components" links
on his Wiki page:
http://wiki.java.net/bin/view/Javatools/SunJavaStudioCreator