On 3/3/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > On 3/3/06, Adam Winer <[EMAIL PROTECTED]> wrote: > > 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.
FYI, JSR 276 (http://jcp.org/en/jsr/detail?id=276) is a complimentary JSR that takes a metadata-driven, JSF-specific approach, instead of the Java code, generic JavaBean approach of 273. Both can work together. (I kinda like 276 more; I'm guessing Craig likes 273 more. Just a hunch. ;) ) -- Adam
