Blog

You've heard about it... the GST Site Foundation.  Maybe you've heard of it as the "GSF".  But what is it?

The GSF is a set of core architectural patterns and tools that support building websites with WebCenter Sites.

Think WebCenter Sites on Rails.

So why does it exist?  Well, WebCenter Sites provides very flexible and powerful APIs.  They are so powerful that the entire editorial interface, asset infrastructure, and all of the tools that are part of the application itself are built on the same APIs that we can use on our own websites.  Don't get me wrong, that's a good thing.  But the flexibility means that day-to-day website programming tasks are subject to the same drawbacks of highly generalized code: verbosity, duplication, annoyingly explicit APIs.  The GSF, tackles this problem directly, providing very efficient, compact APIs that let you spend your time getting the job done, not looking up checked exceptions and parameter names.

Here are a few examples.

Search Engine Fun

Running a simple search engine query and looping over the results would take 50 lines of code, shrinks down to just the following using the SimpleSearchEngine class in the GSF:

SimpleSearchEngine lucene = SimpleSearchEngine.getInstance("lucene");
QueryExpression qry = lucene.newQuery("myDescription", Operation.WILDCARD, "*"+q+"*");
for (ResultRow row : lucene.search(qry, "Global"))
{
    for( String fldName : row.getFieldNames() )
    {
        IndexData idxdata = row.getIndexData( fldName );
        out.println( fldName + ":" + idxdata.getData());
    }
    out.println( "Relevance:" + row.getRelevance());
}

which is pretty good.

Reading Asset Data

How about reading flex asset attributes from the primary asset in a template?  Prior to the GSF, you're looking at creating an asset set, setting the asset into it, and running getattributevalues and getmultiplevalues for each attribute you want to retrieve, then converting it into the right data type.  Or, if you're using the Java Asset API, you're looking at getting a session, retrieving the asset data manager, reading the asset data, retrieving the attribute data, extracting the data from the attributedata (yes, you actually have to do this), and then finally casting it to your desired type.  In the GSF, we're looking at something more like this:

TemplateAsset asset = new TemplateAssetAccess(ics).readCurrent();
asset.asString("description");
asset.asDouble("price");

Works for me.  Notice all of the NoSuchFieldExceptions?  All of the <assetset> tags?  How about the field casting?  You get the idea.

One more.  Page Nav Bars

Occasionally, websites have nav bars (and of course, by occasionally I mean approximately 100.0%).  To generate a nav bar based on the Site Plan Tree in WebCenter Sites involves the following:

1. identify your first page asset
2. get its site node
3. load the site plan tree for that node
4. get the node's children
5. look up the assets associated with each child
6. load the asset data for that child to get the linktext (see Reading Asset Data above for how to do that)
7. compute the link using the verbose <render:gettemplateurl> tag
8. iterate through the results
9. display the link

In the GSF, we're talking the following:

<gsf:navigation name="nav" depth="1" pagename="MainNav"/>
<ul>
    <c:forEach var="kid" items="${nav.children}">
        <li><a href='${kid.url}'>${kid.linktext}</a></li>
    </c:forEach>
</ul>

Which, if you'll notice is HALF AS MANY LINES as it took me to describe the steps alone (excluding formatting).

And that describes just three classes from the GSF.  Wait 'till you hear about the other 353!

But that's just ONE problem the GSF addresses.

Controllers

WebCenter Sites provides no controller infrastructure for website developers (i.e. 98% of its users... hmm...).  Instead, developers create "Wrappers", which are JSP templates that are called before the actual HTML-rendering layout JSP is actually called.  The idea is that custom logic goes there, and then you can call your template.  Yes, I'm serious.  Your "controller" is a JSP file.

There are real architectural reasons for which Oracle has to impose this limitation, which I could go into at length, but at the end of the day it doesn't matter.

The GSF provides, instead, an elegant drop-in controller architecture, along with several controllers to choose from, that allow you to write your logic in ... are you ready for this?  Java... not JSP.  Oh, and Groovy too if you like.  We'll blog about this more in the future, but the GSF lets you choose between a simple "BaseController", and more sophisticated "ActionControllers" which dispatch actions to dedicated classes (or Groovy scripts) to perform your logic.  The efficiency helpers in these actions are amazing.  Wired up with annotation-based dependency injection and a set of pre-built factories, DAOs, and service objects, reading asset data is amazingly simple.  Have a look at this action, which reads all of the attributes in an asset and then reads the associated children, and passes the result into the view through a model map:

    @InjectForRequest public ICS ics;
    @InjectForRequest public Model model;
    @InjectForRequest protected TemplateAssetAccess assetDao;

    public void handleRequest(final ICS ics) {
        AssetId id = assetDao.currentId();
        TemplateAsset asset = assetDao.read(id);
        model.add("asset", new ScatteredAsset(asset.getDelegate()));
        for (AssetAssociationDef assoc : asset.getAssetTypeDef().getAssociations()) {
            String assocName = assoc.getName();
            if (assoc.isMultiple()) {
                model.add(assocName, asset.getAssociatedAssets(assocName));
            } else {
                model.add(assocName, asset.getAssociatedAsset(assocName));
            }
        }
    }

You spend your time and brain space DOING YOUR WORK, not fumbling around with boilerplate code and the unnecessary torture of logic in JSP templates.

Groovy

Yes,  you can write your actions in Groovy too if you like.  You can write your groovy files into the webapp file system, or, as of the GSF 11, even in elements in the ElementCatalog!  Yes, WebCenter Sites thinks they're plain text, but the GSF actually runs them.  Oh myyy!

Vanity URLs

The GSF provides comprehensive support for vanity URLs in its default, out-of-the-box configuration.  The idea is that  web pages have URLs, and in Sites, content is presented through web pages, so content should have URLs. Keep in mind that this does not apply to all websites, but most of them.  By assigning a URL to an asset, and providing a very slick host substitution system, and finally by integrating the URL generation mechanism directly into the <render:gettemplateurl> API, all web pages can have vanity URLs natively, without any special programming at all.  Sites, which has been around since the late 90s, has never had this feature, and even in 11g it's still not present, but it now ships with the GSF.

And more

These are just some of the more popular GSF features.  The GSF was built to address all of the annoying little features that slowed down website development with Sites.  As a result, there are a few more features in it that I don't have time to cover in this post:

• built-in JSTL expression language support
• template injection
• render mapping support
• html helpers
• annotation-based controllers
• handy maven samples for builds
• tons of asset api helper classes
• catalogmanager helpers
• installer helpers
• multilingual site helpers
• Java support for dozens of JSP/XML tags not available through the regular Sites Java APIs
• IList & Exception helpers,
• tagging support, with cache dependency enhancements
• over a dozen convenience JSP tags for loading assets, reading properties, and overall scripting
• http error code handling
• site configuration property support
• alias/link/bookmark support

and on, and on, and on.

Use Only What you Want

A number of customers have seen this list of features and have been scared off using the GSF because "there is too much good stuff in there, and I can't use it all".  Perhaps they have invested a small fortune in their custom controller, or their custom URL system, and they don't want to replace tens of thousands of dollars worth of work with a few lines of code and the GSF....

Whatever the reason, the GSF can be used very selectively.  Many of my own projects just use the facades and tag library.  Most new ones use most features, of course, but dropping the GSF into an old project to speed up some code enhancements is so helpful.

In fact, the GSF runtime is extremely lightweight, and does not conflict with existing systems.  The only think you have to keep in mind is that if you're have your own URL assembler already in place, you have to configure the GSF's with the appropriate priority levels or fallback priority.  But if you don't use a GSF feature, that feature won't get loaded into memory and won't impact performance of the site.

In other words, you have no reason to be afraid.

What it's not

The GSF is not a site design template.  In fact, it imposes NO restrictions on your website architecture.  There are certainly suggestions that we can make about how you might want to model web pages, but they can be ignored if they are not appropriate

The GSF is not the answer to everything.  The aim was to go after 80% of website projects, not 100%.  Some sites won't be able to use some of its features.  No problem.  Everything the GSF does can be done without the GSF (only in more time).

The GSF is not heavyweight.  As stated above, we only load what is needed into memory, and the GSF is designed to be light and fast, from the ground up.

The GSF is not expensive.  In fact, it's free.  Open Source - Apache 2 License to be precise.

Sites and Product Development

The GSF was designed to fill gaps with WebCenter Sites' APIs and development practices.  Correspondingly, if Oracle adds features to the WebCenter Sites, it makes sense that the feature will be removed or deprecated from the GSF in favour of the official feature.

In an ideal world, then, the GSF would have nothing in it, and Sites would do all that it needs to do.  But the reality is that product development has timelines and constraints that make it virtually impossible to react in a timely manner to pressing needs in the development community, and the GSF stands in to fill that gap.

We work with Oracle product development to explain why the GSF contains certain features, and so far several GSF features have been incorporated into Sites, and more are on the way.

This will continue into the foreseeable future.

Authors and Support

So where did this thing come from? The GSF was founded by FatWire Software's Global Solutions Team (GST) in 2010 - Suzanne Bourdeaux, Dolf Dijkstra, myself - Tony Field, and Michael Sullivan.  Design started in the spring and the first formal release came out in November of that year.

Since then, the FatWire GST enhanced it significantly.  In addition, my company at the time, Metastratus Web Solutions, added to it significantly, with all members of the team contributing at least something to the GSF.

Today, Oracle's Architecture Team (A-Team) adds to it, and now that Metastratus and Function1 have merged forces, the new Function1 team is continuing to add to it too.  Various customers have contributed parts throughout the years as well.

However, the GSF is NOT supported by Oracle.  While it is built entirely on supported libraries (just as your website would be), Oracle does not own it nor do they support it.  Clients have to treat the GSF as though it's part of their own website solution.  If you try to log a case with support about the GSF, they will refuse the ticket.  This has been problematic for some GSF users.

The community has been very supportive of it though.  The WebCenter Sites communities are busy with many GSF discussions, and they are great resources for developers.  Function1 participates in these regularly, and we will continue to do so as we grow.

Function1 GSF Support

Sometimes, though, an online forum is not what is needed.  Production systems cannot be supported by an online community, and there is no guarantee that an answer is forthcoming.

Therefore, I am pleased to announce that Function1 now offers GSF support as one of our many product and service offerings.  Customers can purchase a support plan that allows meaningful support on the GSF, over and above the regular forums.  Details about this package will be posted online in the near future.  Please don't forget to subscribe to learn more about it.

Where do I get it?

The starting point for the GSF is the GSF website, at gst-foundation.org.  The site is evolving, and the 11g version of the GSF is currently being finalized, at which point the site will be overhauled.

What if I have questions?

Post them in the comments or email me directly!

Conclusion

The GSF speeds up website development by about 40% and is in wide use around the globe.  It's a pleasure to work with, and I hope that you try it out on your next WebCenter Sites development project.

Happy coding!