Ed Burns's Blog

Let's learn about ourfaces

The ourfaces project is intended to be a casual, yet very useful repository of JavaServer Faces components. I say casual because we want have a low barrier to entry for adding new components to the repository. The project leader, Matthias Unverzagt, has made it very easy to get started as a contributor, in four simple steps. Of course, if it's easy to be a contributor, it's even easier to be a user.

If you look at http://www.jsfcentral.com/ you'll see there are at least ten different entries for JavaServer Faces component libraries, and most of them are not dollar cost free, nor are they free software. I feel it is important to have a high quality, open source, dollar cost free component library for Faces, and the OurFaces project intends to be just that.

Let's take a look at how the project is structured. We've made the project easy to access by building the component catalog in an easy-to-deploy WAR file during the standard build process. This enables you to explore the runtime performance of the components. The source tree is broken down as follows.

ourfaces/

  licenses/ 

    Any licenses that apply to this project go here

  src/

    <component>/

      Where <component> is one of the components in the catalog.
      Currently, we have calendar, code, tree, and table.

        catalog/

          Any artifacts relating to displaying this component in the
          catalog.  These are user-level artifacts, not core component
          artifacts.

            java/

              Java code for displaying the component in the catalog

            web/

               Any non-java code artifacts for displaying the component
               in the catalog.  This includes skinability, sample HTML,
               CSS, XML config files, etc.

        owner.xml

          The XML file that declares the owner of this component.  The
          owner is responsible for everything in this component,
          including its display in the catalog.  

        taglibrary/

          The java code that makes up the UIComponent subclass,
          (optional) Renderer, and UIComponentTag subclass.


    code/

      Any supporting code relating to the display of the catalog

    platform/

      Any supporting code used by the components.

This framework allows the component library to accept contributions from arbitrary parties, while allowing each party to own their components in the repository. As you can see, we currently only have three components, so we're eager to accept more contributors. We hope that becoming a member of the java-enterprise community will give us more visibility.

Please feel free to read and post on the discussion forum!

Comments

• Any thought on sharing?
  So Ed,

  What's the likelihood that components could be written for Tapestry, Echo, and JSF? Seems like a lot of the client-side Javascript could be reused... and I'd love to build yet another version of hangman ;-)

  Posted by: johnreynolds on August 19, 2004 at 06:19 AM

• Any thought on sharing?
  In this project? We're going to keep the components in this project strictly for JSF.

  Technically, I'm sure it would be possible to have a repository that targeted multiple web-app frameworks, but you might have to resort to doing the sharing at the build level. For JSF, the client side javascript would reside in a Renderer. I'm not sure what would happen for the other frameworks.

  Ed

  Posted by: edburns on August 19, 2004 at 07:28 AM

• Re: Any thought on sharing?
  John,

  I think a better goal would be to integrate JSF support into these other frameworks. Doing so will help facilitate a single component marketplace.

  A lot of people forget that it's entirely possible to support JSF components within other framework environments.

  Kito D. Mann
  Author, JSF in Action
  http://www.JSFCentral.com - JSF FAQ, news, and info

  
  

  Posted by: kito75 on August 19, 2004 at 11:07 AM

• Re: Any thought on sharing?
  But Kito,

  Ourfaces is open-source... there's not going to be a marketplace for components, they're going to be free ;-)

  Ourfaces could get a huge infusion of free components if they could leverage the Echo components that have been developed by the EchoPoint project.

  Posted by: johnreynolds on August 20, 2004 at 06:58 AM

• Hi,
  Our project is just getting off the ground using JSF and I'm still in the process of ascending the learning curve. But one thing struck me immediately as I read through the JSF tutorial at Sun's site - how rudimentary the JSF components/renderers were. Surely, there must be some good, open-source components out there so I wouldn't have to implement a bunch of components first.
  So I came across two sites: ourfaces and myfaces - the latter of which is actually a whole open source implementation of the JSF spec PLUS a bunch of components that the reference implementation doesn't provide. The question, naturally, arises: why does ourfaces exist? Its main goal, to provide open-source components for JSF, seems already encompassed by the myfaces JSF effort, no? Wouldn't it be more productive to add to that library than create a competing effort (e.g. the currently existing ourfaces component also have an implementation in myfaces.)

  Maybe I'm way off the mark - I'm no expert on open-source anything and perhaps there are some license differences? myfaces uses the Apache license. What does ourfaces use?

  Thanks for all information,
  tom
  

  Posted by: tjwolf on October 28, 2004 at 01:04 PM

This work is licensed under a Creative Commons License.