Latest Posts

Archives [+]

Archive for 'March 2010'

    Posted by David Nuescheler MAR 29, 2010

    Posted in awards and the web Comments 2

    Last week I had the honor to present the co-developer of the world wide web, Robert Cailliau, with a life-time achievement award of the Best of Swiss Web Association.


    I was very flattered to be the person to present all his achievements during a gala dinner in the Kongresshaus in Zuerich. It was interesting for me in various different ways.

    First I learned a lot of detail about the very beginning of the Web that I did not know before and it was a great opportunity for me to catch up with Robert and talk about old times.

    Also I realized that we have a shared passion for standards which is really reflected on his website so we decided that I would not use Apple's Keynote  for the presentation (which usually would be my tool of choice), but I would use just a browser and XHTML, CSS (& friends).

    Please find the "Directors Cut" of the presentation here, this version contains a number of extra slides as a little bonus.

    Just like Roberts personal website it has not been tested with Internet Explorer and works best with Firefox & Safari on a Mac. Either click through the presentation or use the cursors on your keyboard to move through the presentation. In Firefox you may want to hit Shift-Command-F (on a Mac) for a fullscreen experience.

    It definitely was a very interesting experience to give a presentation infront of 800 people without keynote as my trusty companion, but I have to say the rendering engines of browsers have come a long way, and it all worked out beautifully.

    Presentation

    To give you a little bit of context I thought I'd write down some of the content of my presentation.

    Robert and I met about 11 years ago when he was responsible for the public websites of the Cern. As a WCM Vendor we were invited to go and present our technology. I was fully aware of the importance of the Cern relative to the Web's history, but I was not prepared to meet one of the two developers of the Web in that meeting.

    After the meeting I was deeply impressed with Roberts insights and went back to the office and googled him, which was when I realized who I had just met. It dawned on me that I had the opportunity to take a deep look into "Web history" that day.

    Congratulations to Robert Cailliau, who I think of as a great visionary, but more importantly as a fascinating and charismatic genius who profoundly impacted all our lives.

    Posted by Bertrand Delacretaz MAR 25, 2010

    Posted in apache, open and sling Add comment

    The 2010 edition of the Google Summer of Code program (GSoC) is getting started, now's the time for students to apply! See the FAQ for the timeline.

    The ASF is participating again, and the newly created Community Development group should help better coordinate things.

    See http://community.apache.org/gsoc.html if you're interested in helping an ASF project as part of GSoC.

    I have suggested two projects related to Apache Sling, there's a large list of projects to choose from at the ASF, and students are also welcome to suggest projects.

    As usual, my recommendation to students is to get familiar with the ASF projects that you're interested in rather sooner than later.

    My previous experiences with mentoring GSoC students have shown that being able to communicate effectively with our project's groups is a key success factor, so students who are already in touch with our communities get a better chance of being selected. That's as far as I'm concerned of course - other projects or organizations might have different criteria.

    Could we have some students from Switzerland this time? I tried to motivate some when I was teaching at comem.ch before joining Day, but no one stepped in for GSoC. Where are those swiss genius student programmers?

    Posted by Michael Marth MAR 12, 2010

    Posted in cms Comments 6

    When you look at the technology options one has for a CMS authoring interface there are two big camps: the web UI and the fat client (be it a Java client, .net or similar). The relative pros and cons of these two technology choices are usually described along these lines

    • web clients are easy to deploy whereas fat clients are not
    • on the other hand, fat clients provide a richer user experience and better usability overall.

    Consequently, fat clients are often suggested as the preferable solution for so-called power users whereas web clients are supposed to be the right thing for occasional CMS users.

    Well, these considerations have been around in the CMS community for about 10 years and I have not seen a lot of discussion about them. But I think they are not true anymore. The world has moved on and browser-based user interfaces have not only caught up with fat clients in terms of usability - I think they are even about to provide a better user experience.

    This is part of a very large trend in the computer industry: applications that were once desktop-based move into the browser with the primary examples being GMail or Google Docs. This trend has been facilitated by vast increases in browser performance and better widget libraries like JQuery or Ext. These improvements have made it technically possible to implement user interfaces that are as rich as desktop applications.  Drag-and-drop, tree widgets, responsiveness of the UI - most of what was once thought to be the desktop app's advantage now also exists in the browser.

    However, there is more to this trend: I, for example, have grown completely accustomed to having all my productivity apps within the browser. And because I spend most of my time within the browser it is the browser's infrastructure that defines "convenient" for me, be it password management, download- and upload-behaviour, the browser extensions I have come to rely upon or simply the fact the the browser is always running anyway.

    In my case the increasing tendency to use browser-based apps rather than desktop-based ones even goes out to the choice of my IDE for component development (arguably the most power-user-y thing to do). Day offers the Eclipse-based CRXDE as well as the browser-based CRXDELite and I find myself starting to the latter more and more often - because it is often simply more convenient.

    So, coming back to CMS authoring interfaces: In my opinion the fat client's deployment hassles are not compensated by usability anymore. Maybe, it is time for the CMS community to revisit this topic.

    Posted by Michael Marth MAR 05, 2010

    Posted in jcr Comments 5

    Congratulation to the ModeShape team who have just released version 1.0:

    I’m very happy to announce that ModeShape 1.0.0.Final is now available. With this release, ModeShape now implements all JCR Level 1 and Level 2 features and the optional locking and observation features! And as with our 1.0.0.Beta1 release, ModeShape supports querying repository content using the JCR-SQL2 query language defined by the JSR-283 specification.

    It is great to see this project advance so quickly as it stepped onto the scene only 2 years ago (at that time the project was called JBoss DNA).

    ModeShape implements a couple of interesting concepts. In particular, I like the idea to make accessible various siloed repositories through a unified interface (JCR) which is similar to Day's ContentBus (the repository architecture that previous versions of CQ were based on) or the CRX Connectors.

    It is great to have multiple open-source JCR implementations (others are e.g. Apache Jackrabbit or eXo) that compete against each other in terms of features or performance (or have different licenses).

    Posted by Michael Marth MAR 01, 2010

    Posted in osgi, sling and tutorial Comments 3


    In Apache Sling the JCR nodes usually determine the URLs of a Sling-based web app (and consequently for CRX or CQ5-based apps). For example, Sling will look for the resource http://www.example.com/content/a/b at the path /content/a/b in Sling's JCR repository. This 1-1 mapping is often useful, but there are valid use cases for alternative/additional mappings, for example a web site migration from a legacy site onto Sling.

    In simple scenarios Sling's vanity url mechanism can be used: adding a property "sling:vanityUrl" with value, say, "/old/legacy/path" will render the node for the legacy URLs as well. sling:vanityUrl is a multi-valued property, so an arbitrary number of legacy URLs can be specified. As the property's name implies it is also helpful for mapping short URLs (that can easily be communicated) to nodes that are potentially deep down a content hierarchy.

    In more complex scenarios one can resort to Sling servlets. These are servlets deployed into Sling's as OSGi bundles. Obviously, inside of a servlet any arbitrarily complex business logic can be implemented (e.g. for mapping legacy URLs to new ones). The URLs that a servlet shall respond to can be specified through annotations.

    An easy way to create such a servlet is by using CRXDElite, the web-based IDE that ships with CQ5.3. Here's how to do it:

    • Fire up your browser and point it to /crxde at your CQ5.3 installation
    • Create a folder "myapp" in /apps
    • Create a new OSGi bundle and add a servlet

    Here is the scaffolding code for the servlet implementation that extends the convenience class SlingAllMethodsServlet:

    package com.day.dev.servlets;

    import java.io.IOException;
    import javax.servlet.ServletException;
    import org.apache.sling.api.SlingHttpServletRequest;
    import org.apache.sling.api.SlingHttpServletResponse;
    import org.apache.sling.api.servlets.SlingAllMethodsServlet;
    /** * @scr.service interface="javax.servlet.Servlet"
     * @scr.component immediate="true" metatype="no"
     * @scr.property name="service.description" value="my servlet"
     * @scr.property name="service.vendor" value="Day"
     */
    @SuppressWarnings("serial")
    public class MySlingAllMethodsServlet extends SlingAllMethodsServlet {

        @Override
        protected void doGet(SlingHttpServletRequest request,
                SlingHttpServletResponse response) throws ServletException,
                IOException {
            // do something
        }

        @Override
        protected void doPost(SlingHttpServletRequest request,
                SlingHttpServletResponse response) throws ServletException,
                IOException {
            // do something
        }
    }

     

    • Finally, deploy the servlet by executing Tools > Build bundle. Your new bundle should now show up in the OSGi console at /system/console/bundles

    An important aspect are the annotations that determine for which URLs Sling will invoke the servlet. The most important annotations in this context are:

    • sling.servlet.extensions: The URL extensions supported by the servlet for GET requests
      e.g.:
      @scr.property name="sling.servlet.extensions" values.0 = "TEST_EXT_1" values.1 = "TEST_EXT_2"
    • sling.servlet.methods: The request methods supported by the servlet
      e.g.:
      @scr.property name="sling.servlet.methods" values.0="GET" values.1="POST"
    • sling.servlet.paths: The name of the absolute paths under which the servlet is accessible as a resource
      e.g.:
      @scr.property name="sling.servlet.paths" value="/old/legacy/path"