Sorry, but there are 2 places where typos can happen
the .xml file
the action method
in you case, you have moved the string from action to a property file.
Typos in your case can happen in 3 places
the .xml (typo in @key@)
the property file (bad key name)
the helper class that call an entry in properties file (bad key)
better suggestion:
'outcome.continue' on .xml file
'outcome.continue' as a public static final String OUTCOME_CONTINUE in
helper class
you only have 2 instances of the string outcome.continue all over your
code, typos in OUTCOME_CONTINUE variable will generates compilation
errors, it's easy to maintain, you don't have to go thru an over
engineered process, and you have one less place where a typo can arise.
example design
public class OutcomeConstants {
public static final String OUTCOME_CONTINUE="outcome.continue";
}
public String someAction(){
...
return OutcomeConstants.OUTCOME_CONTINUE;
}
navigation rule:
<from-outcome>outcome.continue</from-outcome>
En l'instant précis du 12/21/06 15:40, Anil Kommareddi s'exprimait dans
toute sa noblesse:
> Hi,
> I agree this is a bit of overengineering, but when working with developers
> whose first language is not english, typos or misspellings are a part of the
> cycle and this is one way to minimize them. We are working on a largish ERP
> project with over 200 navigation rules and can use whatever help we can get
> from tooling, automation and frameworks :).
>
> As I mentioned earlier, this is not an elegant solution and as you pointed,
> probably not desirable either as described. I am just soliciting ideas and
> providing my thoughts for a discussion.
>
> -----Original Message-----
> From: David Delbecq [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 21, 2006 9:18 AM
> To: MyFaces Discussion
> Subject: Re: from-outcome value
>
> Hi,
>
> This all looks to me a bit over-engineering and useless round cycling
> (defining constants string reference that resolve to constant string
> reference...)
>
> Why could this pack of things:
> <from-outcome>@OUTCOME.CONTINUE@</from-outcome>
> public String someAction(){
> ...
> return outcomeUtils.getOutcoume("OUTCOME.CONTINUE");
> }
> outcome.properties:
> OUTCOME.CONTINUE=continue
> finally proceed thru a ant script to convert your file
>
> in any way be better and more maintainable than this:
> <from-outcome>OUTCOME.CONTINUE</from-outcome>
> public String someAction(){
> return"OUTCOME.CONTINUE";
> }
>
> In both cases, you need OUTCOME.CONTINUE to be used inside your action and
> inside your navigation-case. Then use it as your action return!
>
> En l'instant précis du 12/21/06 14:52, Anil Kommareddi s'exprimait dans
> toute sa noblesse:
>
>> Thanks Marco, that is exactly what we have been doing.
>>
>> Here is one way that I thought of doing if anyone else is interested:
>>
>> Define the outcomes in a properties file and use an ANT filterset to
>> use this properties file to replace the outcomes in the
>> faces-config.xml during the build process. To take your example, the
>> Outcomes class would contain a method like this:
>>
>> *public* *static* String getOutcome(String id) {
>> *return* /getResourceString/(ResourceUtils./TYPE_OUTCOMES/, id); }
>>
>> The navigation rule would look like this:
>>
>> <navigation-case>
>> <from-outcome>@OUTCOME.CONTINUE@</from-outcome>
>> <to-view-id>/somepage.jsp</to-view-id>
>> </navigation-case>
>>
>> and the Outcomes properties file will contain:
>>
>> OUTCOME.CONTINUE=continue
>>
>> While this works, if anyone has a more elegant solution, I would love
>> to see it.
>>
>> Thanks for your response.
>> - Anil.
>>
>> ----------------------------------------------------------------------
>> --
>> *From:* Beelen, Marco [mailto:[EMAIL PROTECTED]
>> *Sent:* Thursday, December 21, 2006 4:01 AM
>> *To:* MyFaces Discussion
>> *Subject:* RE: from-outcome value
>>
>> Anil,
>>
>> There is no way you can specify the name of an outcome just once and
>> use a reference to it both in the java-code of your managed-bean and
>> the navigation-rules in your faces-config.xml. Since your
>> faces-config.xml doesn't get build or compile, there is no way to
>> garantee that the values used for outcomes are 'valid' and match the
>> String you use in the managed-bean.
>>
>> For me it works fine to create a Outcomes-class which contains a set
>> of static final String for all outcomes I use through out the entire
>> application. It allows to reference to those outcomes in your
>> managed-bean and set JavaDoc on the outcome-constants to spefify the
>> String to use in the faces-config.xml.
>>
>> public class Outcomes {
>> /**
>> * Outcome use to proceed to the next step in a wizard: "continue".
>> */
>> public static final String CONTINUE = "continue"; }
>>
>> managed-bean:
>>
>> public String someMethod() {
>> return Outcomes.CONTINUE;
>> }
>>
>> This doesn't prevent you from making mistakes and errors in typing the
>> value for from-outcome, but does offer you the possibility to re-use
>> your code better and made changes easier by allowing you to refactor
>> your code instead of performing 'global' search and replace-action on
>> your Strings used as outcomes.
>>
>> With kind regards,
>> Marco Beelen
>>
>>
>>
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> --
>> *From:* Anil Kommareddi [mailto:[EMAIL PROTECTED]
>> *Sent:* woensdag 20 december 2006 20:00
>> *To:* [email protected]
>> *Subject:* OT: from-outcome value
>>
>> Folks,
>> Has anyone devised or know of a pattern to be able to use a reference
>> to a constant string or property file in the from-outcome tag of a
>> navigation-case instead of 'hardcoding' the actual string there?
>>
>> My objective here is to maintain a common repository of outcomes
>> either in a class or property file and refer to them from both the
>> action method and the navigation case.
>>
>> Thanks - Anil.
>> ----------------------------------------------------------------------
>> --------
>> Notice: This e-mail message, together with any attachments, contains
>> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
>> New Jersey, USA 08889), and/or its affiliates (which may be known
>> outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
>> and in Japan, as Banyu - direct contact information for affiliates is
>> available at http://www.merck.com/contact/contacts.html) that may be
>> confidential, proprietary copyrighted and/or legally privileged. It is
>> intended solely for the use of the individual or entity named on this
>> message. If you are not the intended recipient, and have received this
>> message in error, please notify us immediately by reply e-mail and
>> then delete it from your system.
>>
>> ----------------------------------------------------------------------
>> --------
>>
>
>
>
