This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 109531 [details] only the new api changes Currecnt way how to register new JSF component libraries over current friend API is insufficient and quite powerless. It has several base issues like: - it permits to extend webmodule just about one library which has to be registered in IDE - no way for additional customizations of the JSF component library - there is no way how to do more things for additional webmodule updates (like changes of web.xml DD or faces-config.xml) The plan is to replace current friend API with something more powerful - more similar to universal PHP APIs or WEB API. The main goal is to offer users also JSF component libraries which are not bundled with the NetBeans IDE.
Created attachment 109532 [details] full patch - API and usage
PH1: Would be nice if you could annotate params and return values with @NonNull, @CheckForNull etc. PH2: There is Set<JsfComponentImplementation> getJsfDescriptors() in JsfComponentProvider. I would expect getJsfComponents() considering class name. PH3: Perhaps it would be better to return List or Collection from getJsfDescriptors() - I guess Set has no real benefit, but might confuse caller a bit. PH4: createJsfComponentCustomizer seems to be kind of strong contract (declaring the customizer is always created). If clients depend on such behavior then it is ok, otherwise I would change it to getJsfComponentCustomizer and removed the javadoc saying the new customizer is always created. PH5: SPI looks good, but it looks like it is used from client module (JSFFrameworkProvider). Perhaps there should be also API part to make future extensions easier.
Created attachment 109553 [details] full patch 2 - API and usage
Created attachment 109554 [details] new api changes 2 PH1-PH4 in the new patches
Looks good. Thanks Martin. DK1: double check but I think that JsfComponentImplementation.extend(WebModule) should actually be JsfComponentImplementation.extend(webModule, jsfComponentCustomizer) where jsfComponentCustomizer can be null. But in case a suite has some customizer and suite is being added to a project which is being created then extend() method needs to have an access to whatever data user entered in customizer instance.
Created attachment 109563 [details] full patch 3 (In reply to comment #5) > Looks good. Thanks Martin. > > DK1: double check but I think that JsfComponentImplementation.extend(WebModule) > should actually be JsfComponentImplementation.extend(webModule, > jsfComponentCustomizer) where jsfComponentCustomizer can be null. But in case a > suite has some customizer and suite is being added to a project which is being > created then extend() method needs to have an access to whatever data user > entered in customizer instance. That's a good point. But it seems that it is almost since PH4 comment fixed. There is no need for creating new customizer now, so the module can call getJsfComponentCustomizer itself in the extend method. Anyway for letting to customizer know that it should be initialized to defaults values (opening for first time cusomizer in new project or project properties) I extended getting of customizer to: public JsfComponentCustomizer getJsfComponentCustomizer(boolean initialize, @NullAllowed WebModule webModule); see the next patch
Created attachment 109564 [details] new api changes 3
Created attachment 109597 [details] full patch 4 PH5 - Finally I moved that into the client module since it's only place where it should be used. Thanks.
Created attachment 109598 [details] new api changes 4
No new comments so I'm going to integrate tomorrow.
web-main #8102e293bc4b Thanks for the review.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/8102e293bc4b User: Martin Fousek <marfous@netbeans.org> Log: #200258 - API Review: Friend API for JSF component libraries