Jan Haderka's Blog

Jan Haderka is an independent software developer and technology consultant focusing on desktop and enterprise applications. He has been writing software for number of years and since 1995 he has been doing so for living, working for various companies from small startups to big corporations. Lately he has been involved in number of projects, Swinglabs and Magnolia among others.

Templaters nirvana

Just to give you a short peek under the hood of development going on for Magnolia 3.7, here come three different examples of writing paragraph templates for Magnolia. The example is actual textimage paragraph from the current samples.

The first code snippet shows how things have been done up until now with JSP paragraph renderer. And it will still work in 3.7, so don't worry, you don't need to throw away your existing templates

<?xml version="1.0" encoding="UTF-8" ?>
<jsp:root version="1.2" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:cms="cms-taglib"

  xmlns:cmsu="cms-util-taglib" xmlns:c="http://java.sun.com/jsp/jstl/core">
  <jsp:directive.page contentType="text/html; charset=UTF-8" session="false" />
  <cms:ifNotEmpty nodeDataName="image">
    <cms:setNode var="imagedata" />
    <cms:out nodeDataName="image" var="imageurl" />
    <img src="${pageContext.request.contextPath}${imageurl}" 
      class="contentImage_${imagedata.imageFloat}"

      alt="${imagedata.imageAlt}" />
  </cms:ifNotEmpty>
  <cms:ifNotEmpty nodeDataName="title">
    <h2>
      <cms:out nodeDataName="title" />
    </h2>
  </cms:ifNotEmpty>
  <cms:out nodeDataName="text" />

</jsp:root>

The second example is the same paragraph, again written using JSP, but taking advantage of implicit objects made available to templates through EL, as will be from 3.7 on.

<?xml version="1.0" encoding="UTF-8" ?>
<jsp:root version="1.2" xmlns:jsp="http://java.sun.com/JSP/Page" 
xmlns:c="http://java.sun.com/jsp/jstl/core">
  <jsp:directive.page contentType="text/html; charset=UTF-8" session="false" />
  <c:if test="${not empty content.image}">
    <img src="${pageContext.request.contextPath}${content.image}" 
    class="contentImage_${content.imageFloat}"

      alt="${content.imageAlt}" />
  </c:if>
  <c:if test="${not empty content.title}">
    <h2>
      ${content.title}
    </h2>
  </c:if>
  ${content.text}

</jsp:root>

The last (and I'm personally most fond of that one) is again the same paragraph, but this time written using Freemarker and again taking advantage of the implicit objects that Magnolia makes available for you automatically.

[#if content.image?has_content]
  <img src="${contextPath}${content.image}" class="contentImage_${content.imageFloat}" 
alt='${content.imageAlt!""}' />
[/#if]
[#if content.title?has_content]
  <h2>
    ${content.title}
  </h2>
[/#if]
${content.text!""}

Another goodie worth mentioning here is jsp tag support that will be available in freemarker based templates from 3.7 on.

The last one is clear winner, at least for me. Even if you don't want to use Freemarker and like to stick to the JSP, you can make your template much cleaner by not obstructing it with extra tags to provide what is anyway always necessary - the content for the paragraph. I hope it will make writing templates much easier and let you concentrate more on the presentation layer then on the hacking access to the content nodes in the underlying JCR repository.

The implicit objects provided in Magnolia from version 3.7 are:

• content
• paragraphConfig
• templateConfig
• ctx (magnolia context)
• actpage (current page)
• aggregationState (aggregated state of the page with all the extra info accumulated about page while being processed)

All of the objects above are being exposed the way that no matter if dealing with subnode or node data you can access those as if they have been normal bean properties.

SwingX 0.9.4 Released

Finally, after having to wait for few more weeks then originally planned, SwingX-0.9.4 is released. The main changes in this version were previously announced cleanup of the API, added switch to completely disable caps lock detection in LoginPane and about 45 bug fixes. Read the release notes to see complete list of resolved issues before downloading the release from SwingLabs website.

The SwingX team would also like to thank to everybody who reported or voted on issues and/or provided patches for issues. Your continuing interest helps us to make SwingX better.

If all you need is just one more RSS feed

Not so long ago I talked to Boris about Magnolia's new website and the problems with displaying blogs of developers using existing rss paragraph. While this paragraph allows displaying content of the feed on the fly there are several issues with the paragraph. First is the connectivity, paragraph doesn't keep the content of the feed, just a url to it and has to obtain fresh version on the fly. In my experience this doesn't always work. Whether it is because feed is not available while server producing it is too busy or there are some network fluctuations in play I've seen many clients to intermittently fail to obtain feed data. Normally with average RSS reader this is not an issue as reader has previous version of the feed locally and treats such situation just as if there were not updates at the moment. Unfortunately this is not the true for the rss paragraph.

Another side effect of current RSS paragraph is that it has to retrieve and parse feeds for every client who tries to see the paragraph. This of course generates unnecessary load on the server.

Evening after the discussion it occurred to me that in Magnolia, we already have all infrastructure we need to make manipulating feeds more robust.

The key is a data module with support for scheduled tasks. Defining the right structure it should be easy to have data importer to periodically check and get fresh version of the feed into the repository. Having content repository, it would be stupid to just import the rss xml when we can already convert it into content during this step. Also having content of all feeds in interest in the repository, we can easily create combined feeds in the planet like style.

Few hours later (well, really few days later as I was busy with 3.6/3.6.1 release of Magnolia at the time) the RSSAggregator module have been born. For now all it can do is to let you define feeds aggregates, periodically update their content and let you render them in paragraphs, but hopefully I'll have some time to extend its functionality even more.

It all starts with defining your aggregate:

You can define unlimited number of feeds to put into the aggregate, optionally if you don't like the title of the feed you can define your own (you will see where this is used later). Another thing that you can do here is to define filters if you are interested only in some entries from the feed. The Categories, Author, Title and Description can be used to do the filtering in first version. The text you can put in here is a normal regex acceptable for String.matches(), so using "AND Category .*" would have same effect as not using filter at all, while for example, using "AND Category UK" on a BBC news rss feed would give you only news from UK as the result. The tricky part in using the filters is to remember that currently filters are applied to all the entries in the aggregate not only to one feed.

Once you have defined your feed, you can start playing around with scheduling refresh intervals for the feed data. This is one of the main differences in comparison to current rss paragraph - rather then trying to obtain fresh feed data on every display of the paragraph, data module is going to check for it periodically no matter if/or how many times the paragraph(s) associated with the feed have been displayed. To do so all you have to do is to select update interval for the RSSAggregator module. Alternatively you can trigger the update manually.

Now we have the feed aggregate configured and being refreshed automatically, we can have a look at what to do with data. Module comes with two paragraphs already, but I'm sure there is still plenty of space for creativity.

The feedListParagraph renders feeds from the aggregate one by one below each other (in the order in which they were defined), using feed title (or custom title if specified earlier) as a heading for each feed. It will also let you to configure number of entries shown for each feed, ordering and how much of the entry description should be displayed.

The combinedFeedParagraph on the other hand, takes entries from each individual feed in the aggregate and combines them together in one giant feed. Again it let you specify the order, amount of entries displayed and how much of the description for each entry will be displayed.

Paragraph can also optionally provide link to the rss of combined feed so instead of subscribing to individual feeds you can have Magnolia to combine them all together and then subscribe to the aggregated feed. This is useful for example if you want to create one feed from individual blogs of all developers working on your project.

There is for sure still place for improvement. Here goes my individual TODO list. Feel free to suggest more useful things the module could provide.

• Allow to specify filters per feed rather then per aggregate
• Have different refresh times for each aggregate (at the moment they are all going to be refreshed at same interval)
• Have a choice of different feed types (RSS, Atom) when generating combined feed
• Store more details about each individual feed/entry (right now Title, Link, ID, Description, Author, Publication date, Categories are stored)

Just few more remaining details:

• Module is using Rome Project to process and generate RSS feeds
• You can get Magnolia from www.magnolia.info
• You can get source of the RSSAggregator module from svn

Caching strategies for Magnolia 3.6

The stable release of Magnolia 3.6 will soon be out and it will ship with a brand new cache system implemented from scratch. The intention was not to reinvent the wheel, instead, the new cache system decouples Magnolia's presentation layer from the underlying cache mechanisms and allows to plug in any cache engine of choice. Magnolia 3.6 will be distributed with EHCache as the default cache engine, but anyone who is willing to implement a custom cache wrapper can run Magnolia with any other cache engine from the upcoming 3.6 release onwards.

With the new cache system in place, we, the Magnolia developers started to look into which advanced cache strategies should be included. The cache strategies that would allow server administrators to quickly achieve the best cache configuration for their particular use case with minimal effort. New strategies will be available in Magnolia 3.6 Enterprise Edition, adding more in subsequent versions of the Enterprise Edition (EE). We have a bunch of ideas on what strategies we would like to implement based on custom solutions implemented for clients in the past. Some of the cache strategies are more difficult to implement then others. Which ones we deliver with Magnolia EE 3.6 depends on how many obstacles we hit during implementing them and how well we can test those strategies before the release.

The picture below shows a graph of what we ended up on the whiteboard while brainstorming possibilities for advanced strategies to be delivered with Magnolia 3.6.

One option is a more granular cache to minimize server load by re-using previously generated output of single page elements. Instead of re-creating a page's complete HTML by retrieving all content elements every time a page is being requested, the granular cache would fetch all the content pieces only once and keep them as gzipped cache entries to assemble a complete page by re-using unchanged cachied content and re-building only modified content pieces.

Implementing the granular cache mechanism is actually quite tricky, because Magnolia allows content to appear as page element on various other places of a website for dynamic content reuse. For example, the title of a page in one part of the site can be used in the navigation menu at some only remotely relevant part of the same site just to provide link to it. Tracking all the places where content elements appear is actually nearly impossible without constructing a complete content usage graph within Magnolia. Hence, a basic cache flushing strategy would be to simply flush all cached pages of a website content has been updated.

The main problem with such an approach is that the user who visits the website immediately after the cache has been flushed will be the one who suffers from the performance penalty imposed by the server that will now need time to generate all the new cache entries. While this approach to caching is quite safe it is also quite heavy weight. Rather then relying on this brute force solution, Magnolia EE 3.6 will be delivered with different re-caching strategies that will be more appropriate for different scenarios.

Another typical issue is the fact that many concurrent requests affect frequently accessed entries. (Isn't that why they are called frequently accessed after all? ;) ). It is absolutely correct to trigger the generation of cache entries upon the first request, since they do not exist yet. It might happen that more requests hit the server while requested cache entry while it is still being generated. In this case it would be a waste of computing power to again trigger the creation of the same entry for those other requests. In fact, requests that have been issued after the first one won't get the results faster then the first request can be served. Additionally, if they triggered the retrieval of complete representation of a page composed from all the pieces in the repository they will increase the load of the server and slow it down. Mind we are talking millisecond differences here, but it still matters. For this reason, the cache system included in Magnolia 3.6 blocks all subsequent requests to the cache until a cache entry is ready and then Magnolia will serve it to the visitors.

Then again you don't want your server to hang forever in case such an entry can't be generated, no matter whether it is due to a page that doesn't exist or content that is corrupted or even due to a broken template. Since we implement scenarios for Magnolia EE where access to the cache is distributed over multiple modules and comes from multiple threads we made extra effort to make sure the new cache system never ever ends up in a deadlock.

As for the new cache strategies considered for inclusion, let's look at few examples of what we consider implementing.

Serve Old Content While Re-caching Strategy: Instead of flushing the cache on update, old content is kept and served until updated cache entry is created.This way first request for content after an update will trigger generating of new entry, while all the subsequent requests for same entry will be served old content until it is re-cached.

Eager Re-cache Strategy: It allows to serve already cached content to website visitors while re-caching the most accessed pages (e.g. the top 100 high traffic pages) in the background before flushing the cache. The idea behind this is to be able to have highly demanded content being served by Magnolia at highest possible speed at all times. With the Eager Re-cache, visitors will not have to wait for changed content to be cached, because this has been done in the background before they accessed the page. The ability to configure a specific number of entries to be re-cached makes it possible for server administrators to balance the trade-off between time-to-publishing and a performance penalty for users.

Another example would be what we call a Content Driven Timeout Cache Strategy that allows authors of a page to mark a page as expired based on a time set by the author. Currently such scenario is already possible to implement, but requires collaboration between a Magnolia template developer and page author instead of leaving the decision making power completely in the hands of the author.

Why would you use such a timout cache strategy? Just think of a situation where a page includes the results of a news feed and the content editor wants to make sure it is updated at least once a day even though there is no actual content update since the data is being fetched from a third-party RSS feed. Or imagine the opposite scenario that could be handled with same strategy: a page that triggers data mining mechanisms which are quite expensive in terms of server load to generate the output while it has no dependency on any other content. You would be able to mark such a page as expiring in specified intervals only and ignoring all other content updates knowing that that page is not affected by modifications of authors at all.

In sum, the new Magnolia cache implementation - apart from being more efficient in storing and serving the content - also allows for more advanced handling of the cached entries in the Magnolia Enterprise Edition.

September 2008

Search this blog:

Categories

Archives

September 2008
August 2008
June 2008
April 2008
March 2008
December 2007
November 2007
October 2007

Recent Entries

Templaters nirvana

SwingX 0.9.4 Released

If all you need is just one more RSS feed

Articles

Fling Scroller
Does your Swing work focus on "look" and not so much on "feel"? The gestures available to a user can make a big difference in how your UI is enjoyed. In this article, Jan Haderka introduces a new behavior to JLists to allow users to "fling" off the top or bottom of the list and have the scrolling continue briefly as a result of the gesture. Sep. 27, 2007

All articles by Jan Haderka »

This work is licensed under a Creative Commons License.