GSF 12 Is Finally Here!

image

GSF-12 is finally here! Yay!!!

This new version comprehends brand new features, but also a major reorganization of the entire project's codebase and several features getting deprecated in benefit of some of WebCenter Sites 12c's native features.

This is the first GSF release which embraces WCS 12c's features and rendering practices.
 
The main goals of this new release were:
  • Providing the means for clients out there already using GSF to reuse as much of their existing code as possible when upgrading from WCS 11.x to WCS 12c,
  • Leveraging the use of WCS 12c's new features/API,
  • Simplifying GSF's installation/deployment to the utmost and making it as agile and CI-friendly as possible, and
  • Encouraging GSF users and potential adopters to benefit from GSF's optimized code whilst leveraging better encapsulation, cleaner design and more intuitive, simpler usage and deployment.

So... What's New?

Updated Java Stack

GSF-12 requires Java v1.8, Servlet 3.0 and JSP 2.2.

Brand New Namespace

All new classes will live under a brand new namespace: tools.gsf. These are packaged inside a separate JAR: "CORE".
 
The general policy towards logging becomes "one class, one logger" -- although very few exceptions still apply.
 
All pre-existing classes using the old namespace ("com.fatwire.gst.foundation") have been deprecated. These get packaged inside a separate JAR: "LEGACY".

(Considerably) Simpler Installation Procedure

For those of you starting a brand new project and those upgrading a project where there aren't any dependencies on deprecated (GSF-specific) features and classes, then installing GSF-12 can be as simple as deploying the "CORE" JAR inside the WCS 12c web app.
 
No more GSF-specific asset types, WEM App, CatalogMover files nor JVM property values... just an ordinary library with its own configuration files, for those who want to customize it or build upon it.
 
Music for the ears of those who are into agile and CI!

Cleaner, More Intuitive, and Simpler to Extend

The very foundations of the GSF have been revised and refactored.
 
As a result, conceptual consistency is better enforced across the board, design patterns are better leveraged and, ultimately, developers will find it considerably easier to extend GSF-12 - or even customize it - without requiring developer knowledge of some convoluted, internal logic.
 
Scoped factories make the GSF-12 learning process very intuitive and familiar, getBean vs getObject ambiguity is history, AppContext vs Factory duality has been resolved and annotations won't be triggering bean/service instantiation under the hood anymore.
 
In older version of the GSF, using your own custom factory required modifying the web.xml descriptor. In GSF-12, using custom factories no longer implies modifying the web.xml descriptor.
 
Those wanting to use their own Navigation Service can do so transparently by means of the brand new Nav Service API/contract (keep reading)

Integrating With WCS Is Easy As Ever

GSF-12 makes it easy for those wanting to use GSF features from within WCS 12c's new Controllers by providing an extension to WCS' base controller: InjectingController.
 

Obviously, you can still use the GSF from your Java code.

Very Cool Annotations

The brand new @CurrentAsset annotation (tools.gsf.facade.assetapi.asset.CurrentAsset) makes it trivial to carry out what's probably the most frequent operation on any WCS-based project: instantiating the current asset (as per c + cid) and loading some of its attribute values.
class SomeTypicalController extends InjectingController {
        
        (...)
 
        @CurrentAsset(attributes=["title", "subtitle", "body"]) TemplateAsset theAsset;
 
        protected void handleRequest() {
                String headline = theAsset.asString("headline");
                
                (...)
        }
        
        (...)
 
}
... and it supports TemplateAsset, ScatteredAsset and AssetData fields. When WCS 12's AssetReader is not powerful enough, or too slow, this option is ready with zero configuration.
 
Beautiful, right?
 
All other GSF-specific annotations are still around; their code is now cleaner and clearer:
 
  • The @ServiceProducer annotation (tools.gsf.config.ServiceProducer) allows your defining ServiceProducer methods inside your Factory classes.
(...)

@ServiceProducer(cache = true, name="someCustomBean")
public MyCustomBean newCustomBean() {
    return MyCustomBean.getInstance();
}

(...)
  • The @InjectForRequest annotation (tools.gsf.config.inject.InjectForRequest) allows your injecting a ServiceProducer-produced bean into your own Java class, Groovy controller or even JSP / Groovy Template.

(...)

@InjectForRequest(value="sitePlanNavService")
protected NavService myNavService;

(...)
  • The @Bind annotation (tools.gsf.config.inject.Bind) will look for a given variable in the specified scope ("ics", "request" or "session") and, if found, it will inject the value into the annotated field (plus, it handles automatic type conversion for you too)!

(...)

@Bind(value="rendermode")
protected String currentRenderMode;

(...)
  • The @Mapping annotation (tools.gsf.mapping.Mapping) will look up a MAP entry (AssetType:AssetName, AssetType:AssetId, etc...) matching the specified key in the Template / CSElement being executed (for the current site) and, if found, it will inject the mapped value into the annotated field. Yes, it supports AssetId and left/right selection!

@Mapping(value="myMappedAssetIdKey")
protected AssetId mappedAssetId;

The GST Properties Mechanism Is Not Tied To Any Asset Type Anymore

Gone are those times where you were forced to install the GSF's own GSTProperty asset type (or any GSF asset types for that matter)!
 
For those upgrading from an older version of the GSF, you can reuse your existing GSTProperty assets as-is.
 
For those starting fresh on GSF-12, you can use any asset type/subtype you want as long as it's got 2 fields which can provide the "name" (as in key) and the "value" of a property (technically, you need a third field providing the "description" of the property, but those who don't care about it should be able to reuse the field providing the "name" value for this purpose). Simply specify the configuration in your factory and voilà.
 
GSF-12 doesn't impose any asset type/subtype around any feature anymore. Bravo.

A Brand New Navigation Service API

People had been asking for something like this for a long time now...
 
You can now implement your own Nav Service implementation, including your own interpretation of what a "node" is. And you can make it available through your scoped Factories just like any other service/bean (e.g. @ServiceProducer). This implies, of course, being able to easily inject it into your Java classes and Groovy controllers.
 
Obviously, you can create as many navigation services as you want for the very same site. Since you decide how they get exposed by your factories, you have full control over the instantiation process -- and you can inject them into your Controller, just like any other service/bean.
 
In this new "contract" there are only three "clauses":
  • All navigation structures must be modeled as a hierarchy (N-tree) of Node objects.
  • Each navigation structure you build must have a unique handle.
  • Each and all nodes belonging to a nav structure have a (preferred) breadcrumb.
This translates into a new tools.gsf.navigation.NavService interface with 2 methods:
  • One for loading your entire nav structure (i.e. all 1st level nodes): List<N> getNav(S navStructureId);
  • Another one for calculating the breadcrumb of any of its nodes: List<N> getBreadcrumb(P navParticipant);
The concept of a Node is open by means of Java Generics, which allows your extending the base Node interface (tools.gsf.navigation.Node) as it better suits your requirements.
 
An AssetNode specialization is provided out of the box for your convenience, and typically you'd have N and P both bound to AssetId, but if you've got a better idea, then the contract is happy - and open enough - to accommodate that.

The base interfaces - NavService and Node or even AssetNode - "invite" you to (build and) return the entire Nodes N-tree structure when invoking NavService.getNav(), but it is not strictly enforced, leaving the door open to your implementing your own NavService using a lazy-loading approach, if needed.

... and What's Gone?

These are some of the major features which got deprecated in GSF-12:

  • The "gsf-mobile" module.
  • All GSF-specific taglibs.
  • The existing Navigation Service, including all related classes, taglibs and asset types / subtypes.
  • GSF Tagging, including supporting tables, asset event listeners et al.
  • GSF's own Groovy support.
  • GSF Actions / Controllers / Request Dispatching framework.
  • GSF's vanity URLs framework.
  • The entire "include" subpackage, including IncludeService and GsfCallTemplate.
  • All AppContext implementations and all related factories, servlet context listeners and injection-related classes, which have been replaced and enhanced by the new scoped factories-driven infrastructure.
  • All samples driven and/or related to the above features.

Refer to the GSF-12's Release Notes for a comprehensive list of deprecated features and the suggested approach for replacing each of them in your own project's codebase.

So... What's Next?

Function1 has been deeply involved in this new release of the GSF and will continue to support it and enhance it in the foreseeable future.

In upcoming articles, we will dive into the GSF 12's cool new features/components. For now, have a look at the GSF website.

Should you have any inquiries regarding GSF (any version) and/or WebCenter Sites, do not hesitate to contact us!

Subscribe to Our Newsletter

Stay In Touch