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
>