Background

Being new to the SWT I wanted to learn a little about the API by making a simple change to the Commerce Manager UI. I put this post together with the hope that it might have some useful tidbits for other SWT newbies out there.

Goal

The CM client displays a product icon in the catalog's Product Listing view. The icon may vary depending on whether the product is a bundle or has multiple SKUs, but otherwise it is the same icon for every product. To make things more interesting I decided to customise the view to generate an icon specific to each individual product. In the real world, the image location would probably come from a product attribute. To keep things simple however we will simply generate a small square image with a random background colour.

Solution

To achieve our goal we will create a new class ProductIconImageRegistry. This class will be responsible for creating SWT product image icons that can be obtained via the following get(Product) method.

/**
* Returns an image for the given product.
*/
public Image get(final Product product) {
     final Long key = product.getUidPk();
     Image image = imageCache.get(key);
 
     if (image == null) {
          if (isCacheFull()) {
               freeCache();
          }
               
          image = getProductIcon(product);
          addToCache(key, image);
     }
          
     return image;
}

Because every new SWT image instance requires an allocation of OS resources, we will cache the icons in a hash map. To keep the cache from growing indefinitely we will define an upper limit and free up some cache when it reaches the maximum size.

Two important rules to bear in mind (see References) when working with SWT components are:

The rules apply to a number of SWT classes including Image, Color, Font, Widget, GC, and so forth. If you invoke a constructor to instantiate one of these classes, you must free them using the dispose() method.

Color color = new Color(...); // allocates platform resources
color.dispose();

However if you acquire an instance without calling the constructor there is no need to dispose().

Color color = display.getSystemColor(SWT.COLOR_BLUE);

In the case of the ProductIconImageRegistry class, we are creating a new icon image as follows:

/**
  * Returns an icon for the given product.
  */
private Image getProductIcon(final Product product) {
     final Display display = Display.getCurrent();
     final Color color = createRandomColor(display);
     final Image iconImage = createIconImage(display, color);
     return iconImage;
}
 
/**
  * Creates a random Color.
  */
private Color createRandomColor(final Display display) {
     final int red = random.nextInt(256);
     final int green = random.nextInt(256);
     final int blue = random.nextInt(256);
     return new Color(display, red, green, blue);
}
 
/**
  * Creates an Image with the specified background Color.
  */
private Image createIconImage(final Display display, final Color color) {
     final Image image = new Image(display, ICON_LENGTH, ICON_LENGTH);
     final GC gc = new GC(image);
     gc.setBackground(color);
     gc.fillRectangle(0, 0, ICON_LENGTH, ICON_LENGTH);
     
     drawIconBorder(gc, display.getSystemColor(SWT.COLOR_GRAY));
     gc.dispose();
     return image;
}
 
/**
  * Draws a border around the icon.
  */
private void drawIconBorder(final GC gc, final Color borderColor) {
     final int border = ICON_LENGTH - 1;
     gc.setForeground(borderColor);
     gc.drawLine(0, 0, 0, border);
     gc.drawLine(0, 0, border, 0);
     gc.drawLine(0, border, border, border);
     gc.drawLine(border, 0, border, border);
}

Our freeCache() method will simply purge a tenth of its contents and call dispose() on every removed image.

private void freeCache() {
     int removeQty = CACHE_SIZE / 10;
     for (int i = 0; i < removeQty; i++) {
          final Long removedKey = cacheKeys.removeFirst();
          final Image removedImage = imageCache.remove(removedKey);
          removedImage.dispose();
     }
}

We will also provide a disposeAllImages() method on the ProductIconImageRegistry class to allow the client code purge everything on shutdown.

public void disposeAllImages() {
     for (Long key : imageCache.keySet()) {
          final Image image = imageCache.get(key);
          image.dispose();
     }
     imageCache.clear();
     cacheKeys.clear();
}
 

Finally, we need to plug in our new class into the existing CatalogImageRegistry and CoreImageRegistry classes. This can be done by updating the getImageForProduct(Product) method:

public static Image getImageForProduct(final Product product) {
     if (product instanceof ProductBundle) {
          return getImage(PRODUCT_BUNDLE);
     }
          
     if (product.hasMultipleSkus()) {
          return getImage(PRODUCT_MULTI_SKU);
     }
          
     return getImage(PRODUCT);
}

and replacing the last line with

return productIconImageRegistry.get(product);

We also need to hook in the disposeAllImages() method:

static void disposeAllImages() {
     for (final ImageDescriptor desc : IMAGES_MAP.keySet()) {
          final Image image = IMAGES_MAP.get(desc);
          if (!image.isDisposed()) {
               image.dispose();
          }
     }
 
     productIconImageRegistry.disposeAllImages();
}

With the all pieces together, the final result looks as shown in the screen shot. The icons in the Product Listing view are provided by the CatalogImageRegistry class.

The CoreImageRegistry class provides icons for the Select a Product dialog, which looks as follows with the changes in place:

References

http://www.eclipse.org/articles/Article-SWT-images/graphics-resources.html

http://www.eclipse.org/articles/swt-design-2/swt-design-2.html

http://eclipse.org/articles/Article-SWT-graphics/SWT_graphics.html

One of the quirks that I used to have while developing using binary based development is the fact that we have multiple maven projects, and changes to one of the projects (ie. core) will need to be rebuilt in other projects that depend on it (ie. storefront).

This was typical what I had to do:

cd project-root
cd core-project
mvn clean install

<take a nap for a few minutes>

<check to make sure the project built successfully>

cd ../storefront-project
mvn clean install

The other option is to build all the projects in the workspace.

cd project-root
mvn clean install

<take a longer nap for 10 minutes>

That is actually ineffective and a waste of time. One could argue you can write a script that will invoke those commands for you. However, you'd have to check for cases whent the build fails. Luckily, I found that there is a maven plugin that helps with automating that for us.

This is where the Maven Reactor plugin comes to the rescue.

The solve the previous problem where you changed your core project and only want to build the storefront, all you have to do is type this in the project-root directory:

mvn reactor:make -Dmake.folders=storefront-project

The Maven Reactor plugin will build core-project and then the storefront-project for you. If there is a problem with the core project (ie. compilation failures), it will stop the build and tell you.

Hello all,

In a recent project we began using the @Autowired spring annotation in our objects and services to help simplify and minimize the amount of configuration we were writing in our various xml files.

Introduced in Spring 2.5 annotation-based configurations are now a viable alternative to pure XML configuration.  While it is debatable if one approach is “better” than the other, in practice it seems that mixing both methods allows you to spend less time wiring everything up and just getting on with it.

There are a number of annotations available including support for JSR-250 and JSR-330 but for this article I will be focusing purely on the @Autowired annotation.  For more information please refer to the Spring documentation or any number of articles on the web.

What’s the point?

How many times have you had to explicitly wire your spring beans and services hunting for the proper bean names?  What about creating setter methods for your private objects?  What if there were an easier way to do it?

Spring 2.5 (and beyond) has introduced a new xml context schema that deals with ApplicationContext configuration related to plumbing – that is, not usually beans that are important to an end-user but rather beans that do a lot of the grunt work in Spring, such as BeanFactoryPostProcessors.  To enable the tags in the context namespace, simply add the context namespace to your schema definition:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:context="http://www.springframework.org/schema/context"
           xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">

<!-- <bean/> definitions here -->

</beans>

Now let’s look at a class as an example to see how @Autowired can help you in your daily development.

package emptest;
public interface EmployeeService {
         String hire(String name);
         String fire(String name);
}
 
 
package emptest.impl;
@Service
public class EmployeeServiceImpl implements EmployeeService {
 
         private EmployeeDao employeeDao;
 
         public String hire(String name) {
                 String message = employeeDao.getMessage("Hire");
                 return name + ", " + message;
         }
 
         public String fire(String name) {
                 String message = employeeDao.getMessage("Fire");
                 return name + ", " + message;
         }
 
         public void setEmployeeDao(EmployeeDao employeeDao) {
                 this.employeeDao = employeeDao;
         }
}
 

In this simple example we have a service implementing an interface with a private DAO object.  In a typical spring configuration for this service typically you would define your bean as:

<bean id="employeeService" class="emptest.impl.EmployeeServiceImpl">
         <property name="employeeDao">
                 <ref bean=”employeeDao”/>
         </property>
</bean>

But Spring can automatically detect classes and register bean definitions with the ApplicationContext!  Let’s see how this works in practice.

Step 1.  Add <context:component-scan base-package=”emptest.impl”/> to your configuration file.  This tells spring to scan everything in the emptest.impl package for Spring stereotypes and annotations.

<beans xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:util="http://www.springframework.org/schema/util"
     xmlns:context="http://www.springframework.org/schema/context" xmlns:p="http://www.springframework.org/schema/p"
     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                 http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.0.xsd
            http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">

     <context:component-scan base-package="emptest.impl"/>


</beans>

Step 2.  Add @Autowired annotation to any private objects that you would like Spring to wire up for you.

package emptest.impl;
@Service
public class EmployeeServiceImpl implements EmployeeService {
         @Autowired
         private EmployeeDao employeeDao;
 
         public String hire(String name) {
                 String message = employeeDao.getMessage("Hire");
                 return name + ", " + message;
         }
 
         public String fire(String name) {
                 String message = employeeDao.getMessage("Fire");
                 return name + ", " + message;
         }        
}
 
 

That’s it!  Notice that there is no need to explicitly define a setter method, nor do you need to explicitly define your bean within the Spring configuration.

Of course this is a very basic scenario, but for the most part will get you started using annotation based configuration.  There are lots of tutorials, guides and documentation available online for more advanced usages.

Cheers!

Anyone who has had the pleasure of customizing the Commerce Manager knows that it is a complicated piece of software with a lot of moving parts. 

However, with the release of 6.2.1 combined with the new binary-based architecture and a number of clients going through an upgrade process, it has become even more complex with the introduction of patch fragments and a new approach to customizations.

For this blog post, I wanted to demonstrate a handy Eclipse plug-in that lets you visualize the dependencies between the various plug-ins within the Commerce Manager.  This is really useful for quickly discovering which plug-ins/bundles are dependent on each other.

The plug-in is called "Plug-In Dependency Graph Plugin". You can download it from http://testdrivenguy.blogspot.com/2009/05/eclipse-plug-in-dependency-graph.html. Then just unpack it into your Eclipse plugins folder and restart Eclipse.

Open the "Graph Plug-in Dependencies" view, click the search icon in the top right corner, and type in the name of the plugin you want to check out. In this example, I am interested in the our customized admin.configuration plugin.

You can see that there are a lot of dependencies between all the plugins, but by highlighting the admin.configuration plugin I can quickly see which plugins are directly referenced by it.

Alternatively, if you want to see who is directly referencing your plugin, you can show the callers:

In this case, not too interesting.  Let's take a look at com.elasticpath.cmclient.core:

A little more interesting. This plugin can help you quickly track down configuration issues in your plug-in manifest files when developing using the new patch fragment approach.

In future posts, I will provide more technical details as to our approach in implementing the patch fragment architecture including technical challenges encountered and our solutions to these issues.

Targeted Selling is Elastic Path's personalization engine. It collects data about the shopper from various sources and exposes it for rule-based conditional evaluation. In Elastic Path, this is done via Business User rule configurations. The underlying technology put in place to support Targeted Selling is called the Tagging Framework, enabling the system to perform tag-based customer segmentation.

The following diagram shows how the building blocks fit together and form the basis of the various areas of the Storefront that is exposed to a customer for interaction. As you can see, price lists and dynamic content are both driven by these two frameworks.

Be sure to check out the Tagging Framework and Targeted Selling documentation on the Elastic Path documentation site for details. For our purposes, today's blog entry will consist of an example of how we can customize and extend these frameworks to provide rule-driven personalization for a straightforward use case.

Aa a Sales Engineer, I frequently get asked to personalize our storefront presentation to demonstrate some scenarios that are specific to a prospective client. Here are two recent examples where I needed to set up the system to be configurable and present specific dynamic content for two different customer personas:

• Education Pricing: the system should be able to provide education-level pricing that differs according to which school a customer belongs to
• Membership Levels: the system should be able to provide personalized merchandising and pricing to customers at Bronze, Silver and Gold tiers, as well as Staff or Affiliate pricing
  

Now, I'm quite lazy and would be quite happy to spend my day browsing The Daily WTF. I definitely do not want to start writing new code every time the business/marketing admins want to start segmenting customers via new profile attributes. Therefore, I want this customization to the system to be easily configurable. In this post, we'll look at how I did it.

The steps we'll be running through include:

• Setting up the new customer profile and tagging data to support the customer segmentation
• Setting up segment specific pricing and dynamic content rules
• Extending the system to add a configurable Tagger in the storefront to perform the segmentation
• Testing the new configurable Tagger
• Tying everything together with Spring

Setting Up the Underlying Tag Data

Adding Customer Profile Attributes

I've elected to add two new String-based customer profile attributes via SQL rather than the Commerce Manager client. In this case, we're looking at two custom attributes that are automatically available for editing in the Commerce Manager's Customer editor, as seen below. Optionally, we could have made these attributes System attributes and added custom drop-down boxes with pre-defined values for valid membership levels and schools respectively for the Customer editor. I'll leave that as an optional exercise.

INSERT INTO TATTRIBUTE (UIDPK,ATTRIBUTE_KEY,LOCALE_DEPENDANT,ATTRIBUTE_TYPE,NAME,REQUIRED,VALUE_LOOKUP_ENABLED,ATTRIBUTE_USAGE,SYSTEM,ATTR_GLOBAL)
    VALUES (1000,'CP_MEMBERSHIP',0,1,'Membership Level',0,0,4,0,0);

INSERT INTO TATTRIBUTE (UIDPK,ATTRIBUTE_KEY,LOCALE_DEPENDANT,ATTRIBUTE_TYPE,NAME,REQUIRED,VALUE_LOOKUP_ENABLED,ATTRIBUTE_USAGE,SYSTEM,ATTR_GLOBAL)
    VALUES (1001,'CP_SCHOOL',0,1,'School',0,0,4,0,0);

Adding Custom Tag Definitions and Values

Next we're going to make the Tagging framework aware of new tags for Membership and Schools. We're also restricting the possible allowed values for each respective tag.

INSERT INTO TTAGVALUETYPE(uidpk, guid, java_type) values(20,'school','java.lang.String');

INSERT INTO TTAGVALUETYPE(uidpk, guid, java_type) values(21,'membership','java.lang.String');

INSERT INTO TTAGVALUETYPEOPERATOR(tagvaluetype_guid, tagoperator_guid)
    values('school', 'equalTo'), ('school', 'notEqualTo');

INSERT INTO TTAGVALUETYPEOPERATOR(tagvaluetype_guid, tagoperator_guid)
    values('membership', 'equalTo'), ('membership', 'notEqualTo');

INSERT INTO TTAGDEFINITION(uidpk, guid, name, description, tagvaluetype_guid, taggroup_uid)
    values(30, 'school', 'school', 'school', 'school', 3);

INSERT INTO TTAGDEFINITION(uidpk, guid, name, description, tagvaluetype_guid, taggroup_uid)
    values(31, 'membership', 'membership', 'membership', 'membership', 3);

insert into TTAGALLOWEDVALUE(uidpk, value, tagvaluetype_guid, description, ordering)
     values(42, 'gold', 'membership', 'Gold', 1),
     (43, 'staff', 'membership', 'Staff', 2),
     (44, 'affiliate', 'membership', 'Affiliates', 3);

insert into TTAGALLOWEDVALUE(uidpk, value, tagvaluetype_guid, description, ordering)
     values(45, 'sfu', 'school', 'Simon Fraser University', 1),
     (46, 'ubc', 'school', 'University of British Columbia', 2),
     (47, 'ua', 'school', 'University of Alberta', 3);

Adding Localized Content

For completeness, we're adding localized content so that our Pricelist Assignment and Dynamic Content Delivery rule editors will display our new tags appropriately for administrators.

INSERT INTO TLOCALIZEDPROPERTIES (UIDPK,LOCALIZED_PROPERTY_KEY,VALUE,TYPE,OBJECT_UID)
    values (200000,'tagDefinitionDisplayName_en','is from a school','TagDefinition',30);

INSERT INTO TLOCALIZEDPROPERTIES (UIDPK,LOCALIZED_PROPERTY_KEY,VALUE,TYPE,OBJECT_UID)
    values (200001,'tagDefinitionDisplayName_en','has a membership','TagDefinition',31);

INSERT INTO TLOCALIZEDPROPERTIES (UIDPK,LOCALIZED_PROPERTY_KEY,VALUE,TYPE,OBJECT_UID)
    values (200002,'tagDefinitionDisplayName_fr','is from a school','TagDefinition',30);

INSERT INTO TLOCALIZEDPROPERTIES (UIDPK,LOCALIZED_PROPERTY_KEY,VALUE,TYPE,OBJECT_UID)
    values (200003,'tagDefinitionDisplayName_fr','has a membership','TagDefinition',31);

Adding Tags to the Tag Dictionaries

The system groups tags into tag dictionaries, such as those for pricing and shopper segmentation. We're adding our new tags into these dictionaries so that they show up in the UI for configuration.

INSERT INTO TTAGDICTIONARYTAGDEFINITION(tagdictionary_guid, tagdefinition_guid)
    values('SHOPPER', 'school');

INSERT INTO TTAGDICTIONARYTAGDEFINITION(tagdictionary_guid, tagdefinition_guid)
    values('PLA_SHOPPER', 'school');

INSERT INTO TTAGDICTIONARYTAGDEFINITION(tagdictionary_guid, tagdefinition_guid)
    values('SHOPPER', 'membership');

INSERT INTO TTAGDICTIONARYTAGDEFINITION(tagdictionary_guid, tagdefinition_guid)
    values('PLA_SHOPPER', 'membership');

Configuring the School Pricing

Once this data is all loaded, we can now load up our Price List Assignment editor or Dynamic Content Delivery editor and be able to configure rules based on the new Membership or School tags, such as below.

As such, for a demo I've configured school level pricing for a specific camera to provide a price that is discounted to $150.00 from $199.00. However, this won't show up right away on the storefront because we need to have the School memberships added into a customer's tagset when they are interacting with the storefront.

Creating our own Tagger

To enable the storefront to be aware of the new tags, we're extending the existing CustomerProfileTagger. We're making the custom tagger extensible to automatically add in any configured customer profile attributes into the tagset. Note that the CustomerProfileTagger implements two different listeners for login and session creation events, and thus is executed when these events are fired on the storefront.

package com.elasticpath.sfweb.listeners;
 
import java.util.Iterator;
import java.util.Map;
 
import javax.servlet.http.HttpServletRequest;
 
import org.apache.log4j.Logger;
 
import com.elasticpath.domain.customer.Customer;
import com.elasticpath.domain.customer.CustomerSession;
import com.elasticpath.tags.Tag;
import com.elasticpath.tags.TagSet;
 
/**
 * Applies configured list of tag values into tagset.
 * 
 * @author drewz
 *
 */
public class ConfigurableCustomerProfilerTagger extends CustomerProfileTagger {
 
     private static final Logger LOG = Logger.getLogger(ConfigurableCustomerProfilerTagger.class);
     
     private Map<String, String> profileAttributeTags;
 
     /**
      * Apply configured string-based tags into session's tagset.
      * 
      * @param session instance of CustomerSession
      * @param request the originating HttpServletRequest
      */
     public void execute(final CustomerSession session, final HttpServletRequest request) {
          super.execute(session, request);
          
          if (profileAttributeTags == null || profileAttributeTags.isEmpty()) {
               return;
          }
          
          TagSet tagCloud = session.getCustomerTagSet();
          Customer customer = session.getCustomer();
          
          Iterator<String> iter = profileAttributeTags.keySet().iterator();
          while (iter.hasNext()) {
               String attributeKey = iter.next();
               String tagKey = profileAttributeTags.get(attributeKey);
               String attrValue = customer.getCustomerProfile().getStringProfileValue(attributeKey);
               
               if (attrValue == null) {
                    LOG.debug("Customer attribute " + attributeKey + " not available. Tag value not added to tag cloud.");
               } else {
                    LOG.debug("Adding customer tag " + tagKey + " to tag cloud: " + attrValue);
                    tagCloud.addTag(tagKey, new Tag(attrValue));
               }
          }
     }
     
     public void setProfileAttributeTags(Map<String, String> profileAttributeTags) {
          this.profileAttributeTags = profileAttributeTags;
     }
}

Testing the Tagger

No coding is complete without valid test scenarios! In this case, we're testing that any configured profile attributes are added to the tagset correctly, and any missing/empty profile attributes are not added.

/**
 * 
 */
package com.elasticpath.sfweb.listeners;
 
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
 
import java.util.Date;
import java.util.HashMap;
import java.util.Map;
 
import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.integration.junit4.JMock;
import org.jmock.integration.junit4.JUnit4Mockery;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.mock.web.MockHttpServletRequest;
 
import com.elasticpath.domain.customer.Customer;
import com.elasticpath.domain.customer.CustomerProfile;
import com.elasticpath.domain.customer.CustomerSession;
import com.elasticpath.tags.TagSet;
 
/**
 * Tests for CustomerProfileTagger.
 *
 */
@RunWith(JMock.class)
public class ConfigurableCustomerProfileTaggerTest {
 
     private static final String MEMBERSHIP_ATTR_KEY = "MEMBERSHIP";
     private static final String SCHOOL_ATTR_KEY = "SCHOOL";
     private static final String MEMBERSHIP_TAG_KEY = "membership";
     private static final String SCHOOL_TAG_KEY = "school";
 
     
     private final Mockery context = new JUnit4Mockery();
          
     private TagSet tagSet;
     private MockHttpServletRequest request;
     private CustomerSession session;
     private Customer customer;
     private CustomerProfile customerProfile;
     private ConfigurableCustomerProfilerTagger listener;
     
     /**
      * Setting up instances.
      */
     @Before
     public void setUp() {
          tagSet = new TagSet();
          request = new MockHttpServletRequest();
          session = context.mock(CustomerSession.class);
          customer = context.mock(Customer.class);
          customerProfile = context.mock(CustomerProfile.class);
          listener = new ConfigurableCustomerProfilerTagger();
     }
     
     /**
      * Test that configured list of profile attributes are added to the tagset. 
      * Testing two tags/attributes for membership and school.
      */
     @Test
     public void testAddExistingProfileAttributeToTagSet() {
          final String membershipValue = "GOLD";
          final String schoolValue = "SFU";
          
          context.checking(new Expectations() { {
               allowing(session).getCustomerTagSet(); will(returnValue(tagSet));
               allowing(session).getCustomer(); will(returnValue(customer));
               allowing(customer).getCustomerProfile(); will(returnValue(customerProfile));
               allowing(customer).getDateOfBirth(); will(returnValue(new Date()));
               allowing(customer).getGender(); will(returnValue('M'));
               allowing(customerProfile).getStringProfileValue(MEMBERSHIP_ATTR_KEY); will(returnValue(membershipValue));
               allowing(customerProfile).getStringProfileValue(SCHOOL_ATTR_KEY); will(returnValue(schoolValue));
          } });
          
          
          Map<String, String> profileAttributeTags = new HashMap<String, String>(2);
          profileAttributeTags.put(MEMBERSHIP_ATTR_KEY, MEMBERSHIP_TAG_KEY);
          profileAttributeTags.put(SCHOOL_ATTR_KEY, SCHOOL_TAG_KEY);
          listener.setProfileAttributeTags(profileAttributeTags);
          listener.execute(session, request);
          
          assertNotNull("Membership tag was null", tagSet.getTagValue(MEMBERSHIP_TAG_KEY));
          assertEquals("Failed to get the correct membership value from the tagset", 
                    membershipValue, tagSet.getTagValue(MEMBERSHIP_TAG_KEY).getValue());
          assertNotNull("School tag was null", tagSet.getTagValue(SCHOOL_TAG_KEY));
          assertEquals("Failed to get the correct membership value from the tagset", 
                    schoolValue, tagSet.getTagValue(SCHOOL_TAG_KEY).getValue());
     }
     
     /**
      * Test that if a customer profile attribute is missing for a customer, no tag value is added to the tagset.
      */
     @Test
     public void testMissingProfileAttributeToTagSet() {
 
          context.checking(new Expectations() { {
               allowing(session).getCustomerTagSet(); will(returnValue(tagSet));
               allowing(session).getCustomer(); will(returnValue(customer));
               allowing(customer).getCustomerProfile(); will(returnValue(customerProfile));
               allowing(customer).getDateOfBirth(); will(returnValue(new Date()));
               allowing(customer).getGender(); will(returnValue('M'));
               allowing(customerProfile).getStringProfileValue(MEMBERSHIP_ATTR_KEY); will(returnValue(null));
               allowing(customerProfile).getStringProfileValue(SCHOOL_ATTR_KEY); will(returnValue(null));
          } });
          
          
          Map<String, String> profileAttributeTags = new HashMap<String, String>(2);
          profileAttributeTags.put(MEMBERSHIP_ATTR_KEY, MEMBERSHIP_TAG_KEY);
          profileAttributeTags.put(SCHOOL_ATTR_KEY, SCHOOL_TAG_KEY);
          listener.setProfileAttributeTags(profileAttributeTags);
          listener.execute(session, request);
          
          assertEquals("Membership tag was not null", null, tagSet.getTagValue(MEMBERSHIP_TAG_KEY));
          assertEquals("School tag was not null", null, tagSet.getTagValue(SCHOOL_TAG_KEY));
     }
     
     
}

Tying it all Together

With our new tagger tested and verified, we now configure it into the system via the Storefront's serviceSF.xml spring configuration by replacing the default customerProfileTagger with our new custom tagger. Note that we're injecting a map of profile attributes that will be added to the tagset.

     <bean id="customerProfileTagger" class="com.elasticpath.sfweb.listeners.ConfigurableCustomerProfilerTagger" >
          <property name="profileAttributeTags">
               <map>
                    <entry key="CP_MEMBERSHIP" value="membership"/>
                    <entry key="CP_SCHOOL" value="school"/>
               </map>
          </property>
     </bean>

     Similarly, in the Commerce Manager application we need the UI to be able to handle the new tags, thus in serviceCM.xml we add in our value providers for the Tag Values.

     <bean id="selectableTagValueServiceLocator" class="com.elasticpath.tags.service.impl.SelectableTagValueServiceLocatorImpl">
          <property name="valueProviders">
               <map>
                              <!-- SNIPPED ... -->          
                    <entry><key><value>school</value></key>
                            <bean class="com.elasticpath.tags.service.impl.InternalSelectableStringTagValueProviderImpl"></bean>
                    </entry>
                    <entry><key><value>membership</value></key>
                            <bean class="com.elasticpath.tags.service.impl.InternalSelectableStringTagValueProviderImpl"></bean>
                    </entry>          
               </map>
          </property>
     </bean>

Tie this together and run the storefront with a test customer with a school membership, and suddenly we have the school level pricing we configured earlier. Custom customer segmentation is easy-peasy! Next time that marketer asks for new segmentation rules, we just go back to our XML file and then take a nice a KitKat break.

Obviously, there's plenty of room for improvement here. Ideally, we make the tags and UI select membership and schools from pre-defined lists. Also, I'm not too fond of having to edit XML files and redeploying the application to handle changes, so we could move the profile attribute configuration into Elastic Path's Settings Framework so that they can be modified at runtime without having to restart. But this is a good starting point, and hopefully that gives you an idea of how easy it is to extend the Tagging Framework to meet some common pricing and personalization scenarios.

Segment away!

The contract negociation went through, the SLA is signed, and as a super-keen developer, you've already downloaded and built Elastic Path within minutes ()! Your heart is racing. The adrenaline is pumping. You just can't wait to start building your ecommerce storefront. With the source code in hand, it's so tempting to start hacking the Elastic Path source code right away.

But then you start thinking about the next EP release version, and bug fixes... and you're wondering what you're going to do when it's time to upgrade... How will you manage your customizations while keeping in sync with the most recent stable release of Elastic Path?

Maven to the rescue! You can use the power of Maven dependencies and, more importantly, the WAR overlay feature to do this. Overlays are used to share common resources across multiple web applications. Basically, it's a nice and clean way to apply the Decorator pattern to any EP based web applications.

How It Works

Step 1. If you don't already have one, install your own Maven repository (Sonatype Nexus, for instance). I won't go into details, but have a look at this old post on TheServerSide.com: Setting Up a Maven Repository.

Step 2. Deploy all required libraries shipped with the EP source code in your new Maven repository and build the codebase as per the Developer Guide. When it's done, you should have all applications packaged and ready to be deployed. Depending on your chosen Maven repository, you will need to deploy your different WAR packages (cmserver, searchserver and storefront) by uploading both the WAR binary and the POM file within the project.

Step 3. Create a WAR Maven project to hold all the customizations that you want to make on the standard storefront source code (controller, XML configuration, etc.) and specify that you are dependent on EP's Mavenized storefront WAR as follows:

<dependency>
     <groupId>com.elasticpath</groupId>
     <artifactId>com.elasticpath.sf</artifactId>
     <version>6.1.1</version>
     <type>war</type>
</dependency>

In your POM project file, add   the Maven Warpath plugin. The Warpath plugin extends the existing war overlay functionality included in the Maven War plugin to turn war artifacts into fully fledged build dependencies. We need it to expose the classes built and contained within the WAR dependency.

<plugin>
     <groupId>org.appfuse</groupId>
     <artifactId>maven-warpath-plugin</artifactId>

     <extensions>true</extensions>
     <executions>
          <execution>
            <goals>
                 <goal>add-classes</goal>
            </goals>
          </execution>
     </executions>
</plugin>

WAR overlay gives you full control and dependency management on all your EP customizations. In case of an upgrade or bug fix, all you need to do is rebuild the default EP package and update your project dependency. No more code merge nightmares! No more wondering if you missed any updated configuration files!

By combining the WAR overlay approach with Spring framework's plugin capability available within EP, you can override even bean implementation by simply creating your own core extension jar project, having a dependency on the standard EP core jar library, and defining a plugin.xml file within your own jar project. All this has already been proven in the field. You can implement your own storefront without modifying any EP core domain interfaces, services by injection you own implementation.

And voila! By leveraging Maven dependency and WAR overlay mechanisms, you have a clean, straightforward approach to implementing EP in the field that keeps the upgrade effort low.