Hi,
On Mon, Aug 24, 2015 at 4:45 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
> +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.
Cool, so after I'm done with the current story I'll at least put some
time in investigating this and providing a more coherent proposal.
Thanks!
Kind regards,
Arjan Tijms
> ___
>
> 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://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
>> >
>
>