New pattern to toggle features in JSP

From: Thompson, Sonya (HAL)
Sent: Thursday, May 24, 2012 9:19 AM
To: Ruckman, Maurice (HAL); Fillman, Eric (HAL); Phatak, Sheetal (HAL); Klein, Brian (HAL); Bojja, Sridhar (HAL Contractor)
Cc: Augustine, Anila (HAL)
Subject: RE: New feature to toggle features in JSP

I've also created a FeatureToggleHelper.java with getFeatureToggle() and getFeatureToggleAsString() methods.
This helper knows where the featureToggles.xml file is located & appends the "toggles.{environment}." To the front of whatever key is passed in.
However, this will not be avail until I merge it into 12.23

From: Ruckman, Maurice (HAL)
Sent: Thursday, May 24, 2012 7:31 AM
To: Fillman, Eric (HAL); Thompson, Sonya (HAL); Phatak, Sheetal (HAL); Klein, Brian (HAL); Bojja, Sridhar (HAL Contractor)
Cc: Augustine, Anila (HAL)
Subject: RE: New feature to toggle features in JSP

To supplement this effort, here is an example of how to access our XML in the back-end Java code to drive logic:
Refer: hal-ejb/src/main/java/com/hal/sf/olci/page/AcceptPrintTermsPage.java

if ( StaticXmlDataList.getInstance().getStaticXmlFileMap().get(
"web.copy.olci.acceptTerms_logic.xml" ).get(
"page.EUTerms." + guestCountry ) != null )
{
setEuropeanUnion( true );
}
else
{
setEuropeanUnion( false );
}
From: Fillman, Eric (HAL)
Sent: Friday, May 18, 2012 4:09 PM
To: Thompson, Sonya (HAL); Phatak, Sheetal (HAL); Ruckman, Maurice (HAL); Klein, Brian (HAL); Bojja, Sridhar (HAL Contractor)
Cc: Augustine, Anila (HAL)
Subject: New feature to toggle features in JSP

Hi.

Sonya and I put together a little process that will allow you to control when a new feature or new code will be used.
It starts with a file in Teamsite called featureToggles.xml, and it's in the web/copy/features directory.

Here's a very condensed sample of what the file looks like:

</toggles>

Essentially there are two sections - <nonProd> and <prod>. <prod> would be used for production, <nonProd> will be used for everything else. Within each you define an element and indicate whether that feature will be used/displayed/etc. within the JSP. In the example above, <displayGroupExcursions> can be used to control the group excursion functionality. It's currently set to true for nonProd so group excursion features will display there, but false for prod.

This way we can push code to dev, test, and prod, and have the features available in dev and test, but not prod. Once the OK is given for prod, we just need to change the XML and push that through Teamsite. If we need to shut a feature off for some reason in prod, we can do that too.

To use the featureToggles.xml, you just need to include a reference to it in the JSP like we do for all the static content XML files:

<s:set var="featureMap" value="#application.staticXmlDataList.staticXmlFileMap['web.copy.features.featureToggles.xml']"/>

Then in the JSP code, add an if statement to check the value of your feature name:

<s:if test="#featureMap['toggles.' + featureEnv + '.displayGroupExcursions'] == 'true'">

<s:if test="%{!getShxGroupTourBizList().isEmpty()}">

// Do something here

</s:if>
</s:if>

Notice the featureEnv variable in the highlighted line above. We added a method to the BaseAction class called getFeatureEnv() that will return a string value of either nonProd or prod depending on the environment variable set in the System Properties. If environment is prd, it returns prod, otherwise it returns nonProd. As long as your JSP is called from an Action that extends BaseAction (which I think everything is the new flows do), your JSP should have access to featureEnv.

You should also be capable of accessing the XML file directly from an action if you want to control which methods are being called from a service or something, but we didn't get that far with it.

The code is in 12.21-RC, so it should go to prod next week.

Let me or Sonya know if you have any questions.

Thanks.

Eric

Leave a Reply