jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [JAVASERVERFACES_SPEC_PUBLIC-1193] Task

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Tue, 1 Sep 2015 17:01:23 +0200

Hi,

On Tue, Sep 1, 2015 at 4:47 PM, manfred riem <manfred.riem_at_oracle.com> wrote:
> Still stuck on the other stuff?

Indeed, latest status is a fix for 3 similar bugs in the implicit EL
resolver. Fix is trivial and has been committed and tested in
OmniFaces/mojarra master branch, but creating tests takes some more
time.

The following EL implicit objects are now done:

   "application", "applicationScope", "cc", "component", "cookie",
"facesContext",
   "flash",
   "flowScope", "session", "sessionScope",
   "view", "viewScope"


Still to do:

   "header", "headerValues", "initParam", "param", "paramValues",
   "request", "requestScope", "resource"

From the look of it they all seem fairly simple, but one never knows.

Kind regards,
Arjan Tijms







>
> 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
>>>>>
>>>
>