Hi Arjan,
Still stuck on the other stuff?
Thanks!
Kind regards,
Manfred Riem
On 8/24/15, 10:06 AM, arjan tijms wrote:
> 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
>>>>
>>