|  | Matthias Wessendorf talks Ajax, Trinidad, and ADF Faces
by Kito Mann
09 Aug 2008 19:00 EDT |
This podcast is an interview between JSFCentral editor-in-chief Kito D. Mann and Matthias Wessendorf, a software engineer at Oracle. This was recorded in March of 2008 at AjaxWorld East in New York City. You can catch Matthias Wessendorf and other expert JSF speakers at JSFOne.
Podcast (MP3)
Welcome to the JSFCentral podcast #5 for the week of August 4, 2008. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
We' re proud to announce JSFOne, the one event exclusively focused on the JSF ecosystem, taking place September 4th through the 6th in the Washington, DC area. JSFOne is a conference for application developers, solution architects, and project managers who develop applications with JavaServer Faces, Seam, and related technologies. Our speakers are deeply involved in every aspect of the JavaServer Faces ecosystem, from developing core technologies to building real-world applications. JSFOne is hosted by JSF Central and the No Fluff Just Stuff Symposiums.
| Kito | I’m here at Ajax World East 2008 in New York City. I am talking to Matthias Wessendorf. Matthias works on the Apache MyFaces Trinidad project as well as Oracle ADF Faces. Matthias, why don’t you tell us a little bit more about yourself first, and then about those two projects.
| | Matthias | My name is Matthias Wessendorf, I work for Oracle and part of my job is working on the Trinidad project that is hosted at Apache MyFaces. Also a huge part of my job is actually working on ADF Faces. ADF Faces Rich Client is a library that addressed Web 2.0 DHTML applications. My name is Matthias Wessendorf, I work for Oracle and part of my job is working on the Trinidad project that is hosted at Apache MyFaces. Also a huge part of my job is actually working on ADF Faces. ADF Faces Rich Client is a library that addressed Web 2.0 DHTML applications.
| | Kito | Okay, just to take a step back; Apache MyFaces, Trinidad, and ADF Faces are essentially JSF component suites, right?
| | Matthias | That’s right, both of them are first-class citizens in the JSF world. The Trinidad project was donated by Oracle in 2006 to the Apache Software foundation. It was part of the incubation and it took a little while to build a community around it. We were able to get committers to Trinidad from outside of Oracle, which is a good sign that there is a healthy community around it. After the incubation phase did very well, we decided to leave the incubator, and as our final destination we chose the Apache MyFaces project. Trinidad is now a first-class citizen within the Apache MyFaces project. The newer version of ADF Faces, ADF Faces Rich Client that is based on JSF 1.0 and 1.2, is really using lots of bits that are provided by the public APIs offered by the Apache MyFaces Trinidad project.
| | Kito | Essentially Trinidad is a set of JSF components, and the ADF Faces Rich Client is kind of a next-generation set of components built on top of Trinidad, is that accurate?
| | Matthias | Right. Basically, the Trinidad project is kind of what was donated two years ago, and ADF Faces Rich Client is a library that is Ajax-style with really rich widgets, the full DHTML style. Internally it is using stuff from Trinidad, like APIs that we use for rendering all the styles and developing components. For instance, every component that is available in ADF Faces Rich Client has a path and hierarchy to Trinidad, which itself has a reference to basic, standard JSF -- so that’s how the game works.
| | Kito | Okay, so just to take a step back, Trinidad was originally donated and it was originally ADF Faces. Can you explain what the difference is between ADF Faces and Trinidad?
| | Matthias | The Trinidad project is a little similar to the old ADF Faces project -- ADF Faces 10 G -- so it already has an Ajax API on the client and on the service side. It also has partial page rendering. The old ADF Faces introduced the term “partial page rendering,” because at the time when we actually were doing stuff to update a little part of the page, the term Ajax didn’t exist. In the past we were using the IFrame as a communication channel to queue the event down to the server and receive some HTML back, to only update a little part of the page and not do the full page review. The ADF Faces Rich Client is kind of taking another approach in a more modern direction; it is really like a full DHTML Ajax-based library, but what is different that we have other components in ADF Rich Client. For instance we have two slider components; a number slider and a range slider and all of them look like rich components, like perhaps what the Dojo slider is doing or what the Yahoo slider is doing. Also in ADF Faces Rich Client we have some fancy stuff like Ajax-based scrolling on large tables where data is loaded when you do the scrolling
| | Kito | So basically like lazy loading?
| | Matthias | Yeah, somewhat like that. Trinidad is a more straightforward approach so not really that Web 2.0ish. The whole API is pretty stable and pretty solid. The rendering is not really like when you have a lot of data, and you scroll down and get a kind of lazy loading of the content. For instance, when you enable paging on the table, you don’t need a special component for that one. Just specify with an attribute that you would like to display five or six items on a page and your table contains 20. By default the component is rendering for you the next and previous link -- it is automatically built-in into Trinidad, and in ADF Faces Rich Client as well. Under the hood it is using Ajax technology to actually update the table. Ajax is used in Trinidad as well but not in the fancy terms that you actually have in other frameworks, like you can drag and drop stuff or that you can do lazy loading with scrolling down and stuff like that.
| | Kito | Okay, cool. The MyFaces project has a few different component suites, right?
| | Matthias | Right.
| | Kito | MyFaces Tomahawk, MyFaces Tobago, and then Trinidad, right?
| | Matthias | Right.
| | Kito | Those are the only actual component suites right?
| | Matthias | There is also Sandbox for Tomahawk
| | Kito | Right.
| | Matthias | But the base of that one is basically really Tomahawk. Once in a while some components get promoted and they end up in Tomahawk. We recently started to have Sandbox for Trinidad as well.
| | Kito | Oh really?
| | Matthias | So, the approach is pretty valuable -- whenever a guy is interested in donating some stuff, it depends on the good API and the good facilities of Trinidad. Let’s say he just creates a component and decides “okay I would like to contribute it,” but for some reason the testing wasn’t there, or it’s not really done in 100% mode because he only was addressing some problems. We now have also the Sandbox approach so the components can grow in there, and when they are done and really stable and solid, then it is likely that they also get promoted there. The Sandbox approach is still available in Tomahawk and recently was added to Trinidad as well.
| | Kito | Okay cool. How is the Trinidad suite different than Tomahawk or Tobago?
| | Matthias | The Trinidad suite is different in that it offers a lot more components, and in a way it offers more accessible components. For instance, let’s go back to the example of the table. In Trinidad, say you just have the one table and you specify the rows to display based on their attributes. Also you can have selections, so there is an attribute where we can turn on selection. That means you have single selection with a radio button renderer. So it is really a hidden detail by the renderer. The page author doesn’t need to worry about adding checkboxes within the column and stuff like that.
You can also have multiple selections, meaning by default the component is generating the checkboxes, and everything like that is a little bit different in the component suites. In Tomahawk, when you want to – for instance – have a scroller, you need a separate component; you add the scroller component and you reference the table that it should do the scrolling for.
In Trinidad this is kind of built in. Basically you have a large set of data and you specify that you would like to present 10 or 20 records on a page, so automatically when you navigate through the table it is all done by the renderer of the table component for you. Really, you work with the Trinidad table with one component, meaning you have the table, and you don’t really need to worry about selection. You don’t need to really worry about the navigation through the large data set -- it is all done for you by the component. So you don’t treat scrolling or selection like a special case.
So you don’t have to add additional mark-up, additional logic, additional components to the page, and you don’t bloat up the page because everything is really served by the component.
| | Kito | So basically you are saying the components seem to be a little more “feature rich".
| | Matthias | Yeah.
| | Kito | More complete in a sense.
| | Matthias | Yeah, they are there and they are different. Some other component libraries out there also have that -- you have a table and you combine a table with a component scrolling, but I personally believe that it might be more intuitive to have actually the one component – meaning the table – and that, with an attribute, you pretty much drive what the rendering result is. Do I want to display everything? So I forget about the rows attribute. Do I want to display only 15? Okay, specify that. Don’t worry about the scrolling. That’s all done for you by Trinidad using Ajax technology. You don’t really need to treat that as a special case, or add other components in there to actually insure it. It’s all done for you by the toolkit itself.
| | Kito | Okay and how is that different from Tobago?
| | Matthias | I’m not really that familiar with Tobago, but from what I saw, it looks like Tobago is also offering kind of a stable API. But I have never really used the components in the project so I am the wrong person to answer questions about that. I know a little more about the Tomahawk stuff because I was part of the Apache MyFaces project when there was only Tomahawk. Even the name Tomahawk wasn’t there. It was in the old SourceForge days…
| | Kito | When it was all one big project.
| | Matthias | Yeah it had ”x:” like MyFaces Extension or so and the name Tomahawk came up when MyFaces decided to go to Apache, and when they also decided to have a more loosely coupled framework. So you have MyFaces Core, and then there was the good old Tomahawk one, then Tobago joined as another component library that is more layout based, and then the Trinidad approach arrived after the successful incubation phase. They are all a little bit different. They all have their own idea. They all have their own philosophy.
| | Kito | Can you use them together? If you wanted to use Trinidad with Tomahawk and Tobago or something, could you do that
| | Matthias | I know there is some work ongoing that you can, for instance, combine Tobago with Tomahawk. There is something in the Tobago Sandbox (you see, there is a sandbox as well!) So that kind of is trying to get them to work together, as far as I know – I’m not really 100% sure but last time I looked it was like that. They also try to integrate Tomahawk components like the Schedule component within Tobago. There was a lot more effort put into ensuring that Trinidad and Tomahawk were working well together. To give a simple example; we have our own formula in Trinidad which is not extending the standard UIForm. Most component libraries basically do a cast in UIForm, so we ended up having to work around that one and compare the strings which are component families, which is kind of weak because JSF itself doesn’t offer you a marker interface for a form. So we ended up doing all those hacks. I think it is pretty solid that you can use at least most of the Tomahawk component. There may be some like the JavaScript menus that don’t work that well.
| | Kito | But most of them will
| | Matthias | Yeah, most of them. There are some projects out there that basically use a bunch of Trinidad components and some additional Tomahawk components, and it’s going very well. I am not saying that every component from Tomahawk is working well with Trinidad or vice-versa, but basically there was already some work done to actually ensure it. The previously mentioned case, where we were having the comparison of the families instead of having real strong stuff like JSF itself, we did those work-arounds to actually ensure that it is working, that you had a Trinidad form and that you can use some of the command components from Tomahawk.
| | Kito | Cool. If you had to pick one feature and one component from Trinidad that were your favorites, what would they be?
| | Matthias | From Trinidad I really like the richness of the table. I really like that you can have easy integration with selection and with the navigation. There is also a very cool component called "input list of values" -- basically it is kind of a special version of the input field. It has a nice little icon on the right of the input area, and when you click on it you launch the Trinidad dialogue framework to serve another page. In this new dialogue you can nest the search engine and a little table, and you can do some searches and then use the facility of the table to select the item you are really interested in working on. For instance, you create a new invoice for a customer and you want to search for the [customer] number -- obviously it is critical to search all the customer numbers, so you click on the button, the dialogue opens, you have a search engine and can search for the name of a customer. You can select “okay customer X, I want that one,” and you have a listener behind the dialogue that is reading the selected value and with that you can really extract the ID of the underlying object and place it into that input component. So you have really good opportunities to combine component and framework features. Just to mention, there is also a very cool and solid Ajax API on that one, so we have bits for the client side. For instance, it is possible that you can queue – whenever you need it – a request to a separate servlet in your application, like if you have a large set of data and you don’t really want to display them the standard JSF way such as using a table, or whatever, to have the representation. You can write your own servlet to get a JSON serialization of that one. So you can use the client side facility to just send down a request to that particular new servlet, and the callback is registered on the client side, and that callback takes care of the result that has been returned by the other servlet. So you have bits like client side API.
On the server side it is also possible that you can call JavaScript functions after you have invoked an action method. We have a render kit facility and you can basically add script to it. Add script means you just put in a string that is basically a function call of JavaScript and after your response has been executed, at the very end of the response there is a script tag that contains the function call of the JavaScript function. So it is interpreted by the browser and it really looks like your action was invoked on the server, and is kind of causing a client side, function to be called. So you can for instance have an action to create customers, and invoke afterwards this JavaScript function, and in your custom JavaScript function already sitting in the page, you can launch third-party libraries like the Dojo dialogue saying customer X has been created for you. That is really a rich toolkit. It is not only that there are some feature richness of the component library itself, there are also really solid APIs for integrating Ajax in a custom way. It is mostly good to use the built-In Ajax facility, but in some cases it can happen that you actually really need to send down a request to another servlet to get a JSON string of the underlying data. For instance, if you would like to put it into another mashup that is expecting data source as a JSON or whatever.
| | Kito | Right, so it sounds like the API is really friendly for integrating with third-party JavaScript libraries and kind of rolling your own Ajax type behavior.
| | Matthias | Yeah we have our Ajax library -- we don’t use Dojo so we have our own little library there. It is really easy to integrate other stuff like that as well. Like I said before, you can combine those function calls and those callbacks, and within the callback you can launch whatever third-party library you really want.
| | Kito | Cool. You mentioned the dialogue framework feature. Can you tell us more about that, and how that relates to all the other dialogue frameworks like Spring Webflow or Shale Dialogue, or Seam’s conversation dialogue stuff?
| | Matthias | It’s a little bit different. The main use case here that you actually can open a new window, and we also provide a page flow scope for that one. The idea is similar -- it is just named a little bit different. In Orchestra it is named “conversation.” The page flow is basically kind of a map where we can put stuff in, and when you are done with it you still need to do some clean-up like clearing the underlying map. The page flow scope can be used within the dialogue to actually have a wizard where you put some data in. It doesn’t get lost during all the requests, and after you are done you do the clean-up and you are set. The little difference here is that you are also able to launch with it. Like you have a special expression that you tie to your action attribute, and you specify a special navigation rule within the Faces config, and that basically points to the page that should be displayed in the new window. Our command button and our command link also have properties to define the height and width of the new window.
| | Kito | Interesting.
| | Matthias | Recently there was something added so that you have a more lightweight version, not really using “window open” so it is within the page. This is optional, so when you don’t have a separate configuration parameter for that one, you get by default the kind of standard way where you have a new window where you actually launch the dialogue. You can specify with an attribute if you really want to use the new window or not, but it’s up to you.
| | Kito | I see. Interesting. So the page flow scope is basically a conversation scope. Some sort of scope that is longer than a request but shorter than a session.
| | Matthias | Right, the idea of that one is pretty much older. I mean the whole history of ADF Faces was already there before JavaServer Faces was there. In the past it was named UIX, and even the previously mentioned partial page rendering using IFrames instead of XMLHTTPRequest is also coming from that area. At that time there weren’t many toolkits out there that offered such a special scope between request and session, so that is the reason it is in there.
| | Kito | Trinidad is – like all the Apache stuff – open source. ADF Faces Rich Client is not currently open source, right? So if I wanted to get it and play with it, can I just download it by itself? What’s the story?
| | Matthias | Currently there is a JDev preview and within the preview you can get the references to ADF Faces, and you can also see it on the webpage of ADF Faces – just go to Oracle.com and search for ADF Faces, or Google for it and go to the direct link, I don’t have it memorized. The very cool thing about this little demo is that you can see screenshots of the over 120 components that we have.
| | Kito | Nice.
| | Matthias | Really before you get your fingers dirty in downloading and launching the application you also can really enjoy the extended tech documentation. It gives you a little description of what the component does and you see a screenshot, like for instance how the table is looking, how rich it is, what our dialogue is doing, drag and drop stuff, how sliders look, our layout based components. For instance we have menus that look similar to what you know from your native file explorer and stuff, You can also nest menus inside menus to get the complete richness of having this new file open and stuff like that. To basically see really what every component is offering you, you have a screenshot of it, so you get the idea of the rich user experience provided by that particular component. After that, if you really like the stuff, I highly recommend you download the preview, start the JDev, and just play around with it.
| | Kito | By JDev you mean Oracle JDeveloper right?
| | Matthias | I mean Oracle JDeveloper 11G. There is currently a series of previews and the current preview is number 3. It is downloadable from the Oracle website. Just go there, download and try it, and feel the rich experience.
| | Kito | You could also use JDeveloper if you were working with Trinidad components right?
| | Matthias | Right, the interesting thing is now, in JDeveloper 11G, which is currently the new one and under preview -- it is now treating Trinidad as a first-class citizen. This means that when you have your old ADF Faces 10G project, and when you open it, a wizard comes up and helps you migrate the old ADF Faces application to a Trinidad application. We are still interested in maintaining the API bits of Trinidad, because we use Trinidad API and all the utilities and facilities within the ADF Faces Rich Client. Still we have several customers who still have the old ADF Faces 10G project that want to migrate to Trinidad because it is currently maintained by the whole community. It is really possible to have that one as well. There is an article out there from Steve Muench, who is a product manager of Oracle, and he is explaining how the migration of old ADF 10G projects can be migrated to a Trinidad one using 11G.
| | Kito | Cool. You are also the founder of the Faces Goodies project, did you want to say anything about that?
| | Matthias | That is just a little playground. Usually when I go to conferences where I am not only presenting a session, but I have technical hands-on for a whole day or half day, usually you need some setup, because you can spend the whole day setting up your infrastructure, like explaining what is this in web.xml, when you have Spring or Orchestra and that kind of stuff -- you really can lose time. My idea was basically to have all these configuration steps already done so that you can use the Faces Goodies as kind of a kick-start. It also has some very, very simple CRUD examples where it shows you how to use some of the familiar elements that we offer like inputDate or whatever -- how the table is working and how the dialogue is working, or how you integrate custom libraries. I have a little example where I am actually displaying the address of a person within the Google Maps. I also have a little example on how to use Dojo for creating custom components with Facelets. It is a project I created for technical workshops I am giving at conferences. Over time, I add more content. Basically that is it. I see that a lot of people are using it for their starting ground because all of the stuff is already set up, meaning kick out the little CRUD example -- it’s not much to kick out those five classes and five files. Still you have the whole configuration, meaning Spring is set up and tied together with JSF. Orchestra is already set up. All the things that you need to configure for Trinidad, Facelets, and JSF itself, like the web XML and stuff like that. Even the rare issues like having a template for custom Facelets stuff, pretty much everything is already in there: a custom skin for Trinidad where you actually can replace the default images, the default font sizes, the default colors. It’s not really a full skin, but at least you get the idea what file you have to touch.
I recently looked and more than 2,000 people were already downloading it, and it is still downloadable with Subversion. I don’t have the number on that one but at least the two binaries that I offer have more than 2,000 downloads right now.
| | Kito | I have a project with Chris Richardson of my ProjectStack case study application but it’s the same way, I don’t think we even have binaries, you can just go to source Google Coding and download it from subversion. I doubt that many people have gotten ours.
| | Matthias | The whole stack is really, really great but when you are new to it, you really would like to use the technology of JSF. You really want to use Trinidad with it, you may use Facelets, you may use Orchestra. It is really a great stack. The big problem is mostly doing the initial setup of all the XML files.
| | Kito | Yeah, unfortunately.
| | Matthias | When we would do that at a conference, basically you have six or seven hours of practical hands on at a conference, you can easily spend two hours or so with that. It is sometimes really a pain to write them and when there is a class of 80 people, it is pretty tough to ensure everybody is typing the configuration in the same way. That was really the original idea behind the project. I prepared it on my own and I thought the guys at the conference found it useful, so put it to Google Code at the open source platform there, and some people may find it interesting and useable.
| | Kito | Anything else to add? Are you enjoying the conference?
| | Matthias | So far it’s good. My talk is tomorrow. I am also enjoying New York, of course.
| | Kito | Of course. Thanks a lot Matthias, good talking to you.
| | Matthias | Thanks for having me Kito.
| | Announcer | That's it for this edition of the JSFCentral podcast.
Don’t forget, you can catch Matthias Wessendorf and other expert JSF speakers at JSFOne, the one event exclusively focused on the JSF Ecosystem, taking place September 4th-6th in Vienna, VA. For more info, visit www.jsfone.com. The music for this podcast was composed and performed by Kito Mann. Thank you for listening... |
|
|
