Hey all,
I'm not sure about the benefit of enums compared to simple string
constants. I could imaging something like this:
public class Views {
public static final String HOME = "/home.jsf";
}
public class SomeBean {
public Outcome actionMethod() {
return
Outcome.view(Views.HOME).redirect().includeViewParams().query("foo",
"bar");
}
}
This would result in:
/home.xhtml?faces-redirect=true&includeViewParams=true&foo=bar
All method calls would be optional of cause. Just to show all the possible
methods that could go into the Outcome class.
However, this could also work when using enums for the views as suggested
by Bauke.
Christian
2015-04-17 19:17 GMT+02:00 Josh Juneau <juneau001_at_gmail.com>:
> I like this idea. It would be beneficial to provide a type-safe
> alternative to string-based outcomes. If third party libraries support
> returning the Object from which toString() is used, then I think Bauke's
> suggestion would work well.
>
> Josh Juneau
> juneau001_at_gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Fri, Apr 17, 2015 at 11:22 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>
>> That would make it more verbose I think.
>>
>> We could also make use of the fact that Mojarra actually supports
>> returning an Object outcome from which its toString() would be used
>> (haven't checked MyFaces on this, but I think it does too). This works just
>> fine as in <h:link outcome="#{bean.someOutcome}"> and in <h:commandButton
>> action="#{bean.someAction}"> with below bean example:
>>
>> public enum Outcome {
>> FOO("foo.xhtml"), BAR("bar.xhtml);
>> private String value;
>> private Outcome(String value) { this.value = value; }
>> public toString() { return value; }
>> }
>>
>> public Outcome someAction() {
>> return Outcome.FOO;
>> }
>>
>> public Outcome getSomeOutcome() {
>> return Outcome.BAR;
>> }
>>
>>
>> Cheers, B
>>
>>
>>
>> On Fri, Apr 17, 2015 at 5:19 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
>>
>>> I think this is why frameworks like VRaptor return a Result object
>>> instead. I wish Enums supported inheritance... But perhaps we define an
>>> Outcome object that has properties like redirect, etc., and the value is
>>> either an enum or a String.
>>>
>>> ___
>>>
>>> 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://
>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>> <http://ww.enterprisejavanews.com>*
>>> * JSFCentral Interviews Podcast:
>>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>>> * Sign up for the JSFCentral Newsletter:
>>> http://oi.vresp.com/?fid=ac048d0e17
>>>
>>> On Fri, Apr 17, 2015 at 11:11 AM, Bauke Scholtz <balusc_at_gmail.com>
>>> wrote:
>>>
>>>> I like the general idea. But how would you toggle redirect=true|false
>>>> when returning an enum?
>>>>
>>>> Cheers, B
>>>>
>>>> On Fri, Apr 17, 2015 at 4:51 PM, Kito Mann <kito.mann_at_virtua.com>
>>>> wrote:
>>>>
>>>>> One of the things I've never really liked about JSF are the
>>>>> string-based outcomes. As a matter of fact, I often use enums instead. What
>>>>> do people thing about providing a type-safe alternative like the one
>>>>> brought up on the MVC EG below?
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Christian Kaltepoth <christian_at_kaltepoth.de>
>>>>> Date: Fri, Apr 17, 2015 at 10:38 AM
>>>>> Subject: [jsr371-experts] Re: [mvc-spec users] Re: Sample application
>>>>> To: "<jsr371-experts_at_mvc-spec.java.net>" <
>>>>> jsr371-experts_at_mvc-spec.java.net>
>>>>>
>>>>>
>>>>> I agree with Rodrigo that we could think about ways that are more
>>>>> typesafe.
>>>>>
>>>>> I'm very impressed by what is possible with VRaptor4:
>>>>>
>>>>>
>>>>> http://www.vraptor.org/en/docs/ten-minute-guide/#create-form-redirecting
>>>>> http://www.vraptor.org/en/docs/view-and-ajax/#redirect-and-forward
>>>>>
>>>>> Perhaps someone from the VRaptor could describe it in more detail?
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2015-04-17 16:05 GMT+02:00 Rodrigo Turini <
>>>>> rodrigo.turini_at_caelum.com.br>:
>>>>>
>>>>>> IMO it's not that nice depending on a String to do this job. A simple
>>>>>> typo will cause problems. Why not working in a type safe solution?
>>>>>>
>>>>>> just like result.redirectTo("/items") or even
>>>>>> result.forwardTo("/items").
>>>>>>
>>>>>> What do you think? And Christian, great work! Thanks for doing this.
>>>>>>
>>>>>> Rodrigo Turini
>>>>>> Caelum | Ensino e Inovação
>>>>>> www.caelum.com.br
>>>>>>
>>>>>> 2015-04-17 10:56 GMT-03:00 Kito Mann <kito.mann_at_virtua.com>:
>>>>>>
>>>>>> (2) Redirect:
>>>>>>>>
>>>>>>>> /*
>>>>>>>> * An Ozark specific way of doing redirects. Should this go
>>>>>>>> into the spec?
>>>>>>>> * Redirecting here is fine as the method doesn't need to
>>>>>>>> render any
>>>>>>>> * messages for the user which would get lost during the
>>>>>>>> redirect.
>>>>>>>> */
>>>>>>>> return "redirect:/items";
>>>>>>>>
>>>>>>>> Yes, the intent was to propose this for the MVC spec. Seems pretty
>>>>>>>> convenient. Comments?
>>>>>>>>
>>>>>>>
>>>>>>> We should consider doing this like JSF, since there is precedence.
>>>>>>> JSF does it like this:
>>>>>>>
>>>>>>> return "/items?faces-redirect=true";
>>>>>>>
>>>>>>> so we could do:
>>>>>>>
>>>>>>> return "/items?mvc-redirect=true";
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Christian Kaltepoth
>>>>> Blog: http://blog.kaltepoth.de/
>>>>> Twitter: http://twitter.com/chkal
>>>>> GitHub: https://github.com/chkal
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal