+1 for investigation.
After working with a team with many composite components, it's clear that
writing components is still more complex than it needs to be, so if we made
it as easy as your sketch shows, I think that's a big win.
___
Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, Inc. |
http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com | @jsfcentral
+1 203-998-0403
* Listen to the Enterprise Java Newscast: *http://
<
http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<
http://ww.enterprisejavanews.com>*
* JSFCentral Interviews Podcast:
http://www.jsfcentral.com/resources/jsfcentralpodcasts/
* Sign up for the JSFCentral Newsletter:
http://oi.vresp.com/?fid=ac048d0e17
On Mon, Aug 17, 2015 at 1:28 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> I will. Now busy with the "CDI alignment" story, but as soon as that's
> "done" (at least having implemented all producers for implicit EL
> variables), I'll take a deeper look at this.
>
> Though there are many strategies, one that I like to mention upfront
> is the strategy of having a "component-lite" model, that is more
> naturally suited for injection.
>
> As we know the existing component model has been around for a long
> time and there are quite a few of nuances and complications with them.
> The idea here is to have a simpler component model that doesn't
> replace the existing components, but is "simply" called from a
> traditional component.
>
> This simpler component is then as much as possible a POJO, *maybe*
> with an interface, but certainly not extending a framework class.
>
> Just as a sketch, but to give an idea:
>
>
> @Named
> @EasyFacesComponent
> public class MyComponent {
>
> @Inject @Attribute
> private int max;
>
> @Inject
> private ResponseWriter writer;
>
> @Render
> public void render() {
> writer.write("Max = " + max);
> }
>
> }
>
> Please don't look too much at the specifics and names used here, it's
> just an example.
>
> This would be paired with a traditional component that the VDL would
> insert, e.g. say
>
> public class UIEasyComponent extends UIComponentBase {
>
> private String easyComponentName;
>
> public void encodeBegin(FacesContext context) throws IOException {
>
> // Setup easy component scope
>
> invokeRenderMethod(
> bm.select(EasyFacesComponent.class, easyComponentName)
> );
>
> // tear down easy component scope
>
> }
> }
>
> Note that this is pseudo code, just to give a broad example of the idea.
>
> As noted in the beginning, this is *one* possible way of going forward
> with JAVASERVERFACES_SPEC_PUBLIC-1193.
>
> The advantage is that you don't have to deal with the complexities and
> compatibility issues of the different kinds of ways components now
> handle attributes (including state helper, attributes collections,
> getters/setters, etc).
>
> Disadvantage is that the approach goes more than a little beyond what
> JAVASERVERFACES_SPEC_PUBLIC-1193 asks and may need some additional
> thinking (handling children, value holders, etc).
>
> But before I even attempt to investigate this approach further I'd
> like to hear from the EG if this is in general a direction worth
> *investigating* (not even saying to actually do it, just
> investigating), or whether this is too far removed from the problem
> domain to even consider investigating.
>
> Thanks!
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Aug 17, 2015 at 7:00 PM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
> > Hi Arjan,
> >
> > As you filed JAVASERVERFACES_SPEC_PUBLIC-1193 can you please look for an
> > implementation and specification strategy and report back to the EG?
> >
> > Thanks!
> >
> > Kind regards,
> > Manfred Riem
> >
>