On 3/3/06, Adam Winer <[EMAIL PROTECTED]> wrote:
Creator does that too, and it definitely works well ... the only *required* additional code is a BeanInfo class (see the JavaBeans API) that lets the component developer describe the component to the tool (for example, declaring that for the "style" property, use the nice CSS Style editor instead of just a string editor on the property sheet).
Writing dynamic behavior is possible, but not required. It's up to the component developer to decide if you want to make your component behave in interesting ways at design time or not. Examples we have implemented in the Creator components include:
* When you drop a Drop Down List component onto the page,
also create a helper bean for the options and bind the component
to it.
* When you have a Label component bound to an input component
via the "for" property, and you change the "id" of the input component,
respond to a property change event and change the "for" attribute
on the Label component as well so that it stays in sync.
* Do not allow a parameter (<f:param>) to be dropped except
in a context where it is relevant (such as inside an output link).
All of this stuff is optional, but provides you a way to improve the life of the users of your compoinents at design time, without messing up how they operate at run time.
By the way, the API we provide to component developers to make this possible has also been submitted to the JCP process (http://jcp.org/en/jsr/detail?id=273), so hopefully we can see a future world where a component developer can write design time behavior like this for more than one tool, instead of having to deal with each tool's individual APIs.
Craig
Why can't JSC just run the component and actually let it render
itself by default? I know that's what JDeveloper does, and
it works well.
Creator does that too, and it definitely works well ... the only *required* additional code is a BeanInfo class (see the JavaBeans API) that lets the component developer describe the component to the tool (for example, declaring that for the "style" property, use the nice CSS Style editor instead of just a string editor on the property sheet).
As a component developer (I've never worked on JDeveloper itself
at all, to be explicit), I really dislike the idea of writing a bunch of
extra Java code for all my components. Supporting optional Java
code when renderers can't render in design time (graphs, etc.) is
a great feature, but you shouldn't force component developers to
write anything for the common case.
Writing dynamic behavior is possible, but not required. It's up to the component developer to decide if you want to make your component behave in interesting ways at design time or not. Examples we have implemented in the Creator components include:
* When you drop a Drop Down List component onto the page,
also create a helper bean for the options and bind the component
to it.
* When you have a Label component bound to an input component
via the "for" property, and you change the "id" of the input component,
respond to a property change event and change the "for" attribute
on the Label component as well so that it stays in sync.
* Do not allow a parameter (<f:param>) to be dropped except
in a context where it is relevant (such as inside an output link).
All of this stuff is optional, but provides you a way to improve the life of the users of your compoinents at design time, without messing up how they operate at run time.
By the way, the API we provide to component developers to make this possible has also been submitted to the JCP process (http://jcp.org/en/jsr/detail?id=273), so hopefully we can see a future world where a component developer can write design time behavior like this for more than one tool, instead of having to deal with each tool's individual APIs.
-- Adam
Craig
