+1 for f:importConstants as well, although f:loadConstants indeed would
make sense too. I'm not a big fan of f:viewConstants.
On Sun, Jun 26, 2016 at 4:59 PM, Josh Juneau <juneau001_at_gmail.com> wrote:
> While both f:loadConstants and f:importConstants seem to make sense, I
> think f:importConstants fits the feature a little better since it describes
> the functionality more closely. When I visit the Liferay f:loadConstants
> documentation, the general usage states that it allows constants to be
> "imported" from class, enum, and interface types. That makes me lean
> towards f:importConstants.
>
> Josh Juneau
> juneau001_at_gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Sun, Jun 26, 2016 at 1:34 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>
>> I can see that.
>>
>> EG, what's a better name, f:importConstants or f:loadConstants?
>>
>> I even momentarily tossed with f:viewConstants, to be consistent with
>> f:viewParam and f:viewAction, the other f:metadata specific tags. But after
>> all I think this is a confusing name. "See constants"?
>>
>> Cheers, B
>>
>>
>> On Sat, Jun 25, 2016 at 10:05 PM, Neil Griffin <
>> neil.griffin_at_portletfaces.org> wrote:
>>
>>> +1 and thanks for doing this!
>>>
>>> This feature reminded me of f:loadBundle as well, which is why we named
>>> the Liferay tag "loadConstants" instead of "importConstants"
>>>
>>> http://www.liferayfaces.org/web/guest/showcase/-/component/alloy/loadconstants/general
>>>
>>> We assumed "load..." was a prefix convention, just like "h:input...",
>>> "h:output...", "h:select..." etc.
>>>
>>> > On Jun 24, 2016, at 4:48 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>> >
>>> > Yes, it includes enums. I'm planning to rework the existing
>>> o:importConstants as an UICompoment for f:metadata. Its functionality
>>> already covers enums.
>>> >
>>> > Cheers, B
>>> >
>>> >
>>> > On Fri, Jun 24, 2016, 22:40 Michael Müller <
>>> michael.mueller_at_mueller-bruehl.de> wrote:
>>> > +1
>>> >
>>> > And it seems your constants include enums, right?
>>> >
>>> > Herzliche Grüße - Best Regards,
>>> >
>>> > Michael Müller
>>> > Brühl, Germany
>>> > blog.mueller-bruehl.de
>>> > it-rezension.de
>>> > @muellermi
>>> >
>>> >
>>> > Read my books
>>> > "Web Development with Java and JSF": https://leanpub.com/jsf
>>> > "Java Lambdas und (parallel) Streams" Deutsche Ausgabe:
>>> https://leanpub.com/lambdas-de
>>> > "Java Lambdas and (parallel) Streams" English edition:
>>> https://leanpub.com/lambdas
>>> >
>>> > On 23.06.2016 18:54, Josh Juneau wrote:
>>> >> +1
>>> >>
>>> >> Josh Juneau
>>> >> juneau001_at_gmail.com
>>> >> http://jj-blogger.blogspot.com
>>> >> https://www.apress.com/index.php/author/author/view/id/1866
>>> >>
>>> >>
>>> >> On Tue, Jun 21, 2016 at 8:00 AM, Bauke Scholtz <balusc_at_gmail.com>
>>> wrote:
>>> >> +1 for it being enforced into <f:metadata>
>>> >>
>>> >> Cheers, B
>>> >>
>>> >> On Tue, Jun 21, 2016 at 2:59 PM, Leonardo Uribe <
>>> leonardo.uribe_at_irian.at> wrote:
>>> >> Hi
>>> >>
>>> >> I see, so it is better if it is set as part of faces-config.
>>> >>
>>> >> Really there is a precedent of a similar tag. In tomahawk there are
>>> t:aliasBean and t:aliasBeansScope, which are tags designed to
>>> create temporal names for bean that are only valid for child
>>> components.
>>> >>
>>> >> This case is just similar, but for constants.
>>> >>
>>> >> Other option I can imagine is make it in the same way f:viewParam in
>>> f:metadata works.
>>> >>
>>> >> <f:metadata>
>>> >> <f:importConstants type="com.example.Gender" />
>>> >> </f:metadata>
>>> >>
>>> >> Then f:importConstants add the definition (which is in fact metadata)
>>> to UIViewRoot. Since everything inside f:metadata is read before the view
>>> is actually populated, things will work fine (but note f:importConstants is
>>> enforced to be added inside f:metadata, which has sense).
>>> >>
>>> >> regards,
>>> >>
>>> >> Leonardo Uribe
>>> >>
>>> >>
>>> >> 2016-06-20 20:33 GMT+02:00 Bauke Scholtz <balusc_at_gmail.com>:
>>> >> I don't think using an annotation is a good idea. Usually models
>>> reside in business/service (EJB) layer and you don't want to have JSF
>>> dependencies over there.
>>> >>
>>> >> Cheers, B
>>> >>
>>> >> On Mon, Jun 20, 2016 at 3:36 PM, arjan tijms <arjan.tijms_at_gmail.com>
>>> wrote:
>>> >> On Mon, Jun 20, 2016 at 3:24 PM, Bauke Scholtz <balusc_at_gmail.com>
>>> wrote:
>>> >> A faces-config.xml based configuration is a reasonable idea. Perhaps
>>> even better.
>>> >>
>>> >> And/or the upcoming @FacesConfig ;)
>>> >>
>>> >> Kind regards,
>>> >> Arjan Tijms
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Cheers, B
>>> >>
>>> >>
>>> >> On Mon, Jun 20, 2016 at 3:14 PM, Leonardo Uribe <
>>> leonardo.uribe_at_irian.at> wrote:
>>> >> Hi
>>> >>
>>> >> Just as a comment, f:importConstants reminds me f:loadBundle, which
>>> was deprecated and replaced by a solution that loads the bundle from the
>>> faces-config.xml files.
>>> >>
>>> >> The problem about f:importConstants is how to set up the context
>>> where these constants are available. For example
>>> >>
>>> >> <f:importConstants type="com.example.Gender"
>>> >> />
>>> >>
>>> >> <h:selectOneMenu value="#{person.gender}"
>>> >> >
>>> >> <f:selectItems value=
>>> >> "#{Gender}" />
>>> >> <f:ajax ...../>
>>> >> </h:selectOneMenu>
>>> >>
>>> >>
>>> >> if the ajax is only for the component, f:importConstants can be
>>> ignored and the code will break.
>>> >>
>>> >> so, the "challenge" is to find a way to define the EL context
>>> properly.
>>> >>
>>> >> In MyFaces there are some EL contexts:
>>> >>
>>> >> - page
>>> >> - template
>>> >> - view
>>> >> - global
>>> >>
>>> >> Sometimes you want a definition to pass through the template,
>>> sometimes through the view or sometimes just have a global definition for
>>> all your views.
>>> >>
>>> >> regards,
>>> >>
>>> >> Leonardo Uribe
>>> >>
>>> >>
>>> >> 2016-06-20 14:49 GMT+02:00 Bauke Scholtz <balusc_at_gmail.com>:
>>> >> Hi,
>>> >>
>>> >> See https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1424
>>> >>
>>> >> This is a commonly requested feature from the community. Several
>>> libraries have it implemented such as OmniFaces and PrimeFaces Extensions.
>>> It would be nice to offer a standard JSF solution such as
>>> <f:importConstants>. It's relatively trivial to implement.
>>> >>
>>> >> If there are no objections, I will take it on me.
>>> >>
>>> >> Cheers, B
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>