JSF Central - Ian Hlavats discusses Designing for JSF, Dreamweaver, and JSFToolbox
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Ian Hlavats discusses Designing for JSF, Dreamweaver, and JSFToolbox
by Kito D. Mann
06 Feb 2009 01:00 EST

In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Ian Hlavats about designing for JSF, working with teams of developers and designers, and the JSFToolbox Suite, a set of Dreamweaver plug-ins for JSF.


Podcast (MP3)
Welcome to the JSFCentral podcast #10 for the week of February 2, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology. In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Ian Hlavats about designing for JSF, working with teams of developers and designers, and the JSFToolbox Suite, a set of Dreamweaver plug-ins for JSF.
Kito Hello. My name is Kito Mann and I am here at JSFOne 2008. We are at day two of the conference in Vienna, Virginia, covering all things related to JSF and Seam. I am here today with Ian Hlavats who works on the JSFToolbox Suite, which is a set of Dreamweaver plug-ins for JSF. Ian is one of our speakers. We are going to chat a little bit today about JSF and designing with JSF from a designer's perspective, what it's like to work for different teams-a design oriented team and a development oriented team that work together. We will also talk about Ian's product as well. So Ian why don't you start just by telling us a little bit about yourself.
Ian First I want to say thank you very much for this opportunity to be here at JSFOne as a speaker and to meet all these great people and learn a lot about different JSF technologies, and also to showcase my company's technology which is -- as you mentioned -- JSFToolbox for Dreamweaver.

A little bit about myself, I actually have a background in philosophy. I have a Bachelor of Humanities degree, which is interesting if you think about it. Now I am working in IT in a Java capacity; it wasn't necessarily a linear path from one to the other. In fact, over the last seven or eight years or so, I have been progressively learning more about the web and about Java development. I have always had an interest in the potential of the web as an interactive medium. I have been working as a Java developer and instructor and trainer now for the last four or five years, and I became quite interested in JSF a few years ago when I discovered it and decided, "You know this is a pretty good framework, actually. We could build some really good web applications on this."

Having come from a Struts background I decided that this is an opportunity to improve on -- at the framework level -- a lot of the things that Struts didn't quite provide and as a consequence developers had to provide for themselves. JSF was a real light at the end of the tunnel for me in a sense, having written Struts apps for a couple of years, with all the plumbing code you had to write to do that. Discovering JSF and seeing how it does the conversion, it does the validation for you, it does the model binding for you, and it has this wonderful UI component model, I thought, "this is really a great framework. I want to invest a lot of time in this." So having taken a web designer certificate program in college a few years ago and being a web designer by trade, I was trained on and regularly used the Adobe products. At the time it was Macromedia but Adobe acquired Macromedia, so today it's Adobe Dreamweaver, Adobe Photoshop, and basically a whole creative suite. Those were the standard tools for web designers so those are the tools I was used to working with.

When I got into JSF as a developer, I thought, "Great! I am going to do my front end in Dreamweaver and then do my coding in whatever IDE I happen to want to use." I discovered that actually it is not quite that easy. Dreamweaver has no native support for JSF, and I found with all the custom tags or standard tags in JSF, it was quite a challenge to get the tools to behave and cooperate and support the tag libraries. All the basic things you would expect, like auto-completion, context sensitive help, and code hints for EL expressions, all this stuff was simply not there. Having been a Dreamweaver user for a few years I decided, "There's an extensibility API here. Why don't I learn it and see what happens." The consequence was two years later, we released JSFToolbox in May of 2006 and at this stage we have products now for Facelets, for Seam, and for Tomahawk available. We are working on two other extensions for Dreamweaver now: one is for Trinidad and one is for ICEfaces. So that's a short history of my career in IT and Java in particular, and how we got to where we are here today.

Kito Wow! That was very detailed. I am impressed that you just managed to say all that in such a concise manner. You said that you got the certificate in the web design stuff and everything, what made you move from the design into the programming end?
Ian To development? There is only so much you can do with static HTML, right? Inevitably as a web designer I was building websites for customers and clients that wanted more than simply static HTML, so I decided to learn scripting languages. I started with ASP, and then I got into PHP, and took a Perl course and learned to do some Pearl and CGI. It was really a very basic level of knowledge at that point, doing what we call today Model 1 development, where the view and the data access logic are basically together on the same page, in the same place. The problem with that, of course, is that maintainability becomes a real issue. Trying to maintain HTML when it is mixed together with scriptlets is a real challenge -- it is a spaghetti code problem, basically. Similarly, maintaining code when it is mixed together with HTML markup is also a challenge, so I knew that something more was required as far as the technology and the approach, and that this wasn't really maintainable, the Model 1 approach.

I have always been intrigued by Java. When I first heard about it, it was in the mid to late 90s when applets were sort of the rave at the time. I liked the idea of the web as more than just a static medium, and having rich internet applications and applets to enhance user interactivity - there was something that really intrigued me about that. It was just a matter of time before I learned Java. Eventually I decided to enroll in a program in the college in the town where I live, Algonquin College in Ottawa, Canada. I took an Enterprise Java Developer program for about a year and a half. I became good friends with the instructors there, and eventually became a TA and was invited to actually teach the courses. That is how I got into teaching and training.

Kito Interesting, ok.
Ian I had a really strong interest in it from the beginning. I just like the elegance of Java, the way things are all separated into objects, and you design classes and the runtime creates objects. With JSF it is just a natural extension of that beauty, if you will, where you are binding your HTML to these objects that are running in this container. Even to this day I find it very intellectually satisfying to work in Java. That is how I got into development, to answer your question.
Kito Ok, one of the great things I think about your background is that you have the web designer background and the developer background. Most people generally end up with one or the other. Or they may do a little bit of HTML, or they build websites and do a little bit of scripting, but not so many people are very well versed in both of them. What are your thoughts on the way you build applications when you have a situation where you have separate groups, like some people that do design and some people do back end development? What are your thoughts on how those groups work together in general, and then also how they work in terms of JSF?
Ian That's a great question. I guess I am probably unusual in that sense because I do have a web design and an Enterprise Java background and training. I know from experience and from talking to a lot of our users -- JSFToolbox users -- who have contacted us for support by email or phone, that the stories I am hearing from people is that there are difficulties in team environments where you have dedicated staff who are doing the design work, and you have a dedicated development staff, and they are trying to work together.

So I guess I do have a unique perspective on it, because I am sort of on the fence in a sense -- I can see both sides. In terms of team environments, with different skill sets, I think that's a necessity. You do need significant knowledge in JSF in both areas. You need the web design, web standards, HTML and CSS, usability and navigation design, and a lot of the other skills that you need to acquire as a web designer to be competent. On the other hand, you need the development side and development skills, programming knowledge in a strongly typed language like Java, testing methodologies, development methodologies, design patterns, learning IDEs which are complex tools, debugging, and all these other skills as well. All these skills are necessary, so the challenge is almost an interpersonal one at times. How do we get teams of individuals with different skill sets, different mindsets, different cultures, different knowledge and experience to work together effectively and to overcome any kind of obstacles that they might encounter? That has been an area of interest of mine for a while now. My tools try to address that barrier and try to eliminate it.

In terms of JSF--Clearly as an MVC framework, JSF is targeted towards web applications and web users, and therefore you need the web design skill set as well, to create the user interface, to create the layout and presentational elements of the application-the view, in MVC terms. On the other hand, you need the Java skill set, of course, to write backing beans, to write converters, to write validators, to write UI components, and to tie things together at the application level. I am not going to touch on the database tier at this point because that is a little bit out of scope. I am assuming that there is a database behind the scenes and there is a team working on that as well. Really we are concentrating on the interaction between the web design or UI design side of it and the development side of it. I can see synergies that could be happening that may not be happening as well as they could be. For example, if you look at the workflow of a web designer compared to the workflow of a developer, and how it overlaps in a JSF context, you have different points in those workflows where there is a need for some kind of connection or collaboration with the other team.

For example, internationalization is one case. At some point all these localized strings have to find their way into message bundles that need to have the proper naming conventions, so the Java internationalization framework can pick them up and they are registered in the Faces config XML file, so the framework can expose them. Also, the tags have to be added to the pages. I think this is one case where you can have some interoperability between the teams, or encourage collaboration between teams. Designers could provide the developers with the localized content, if they were dealing with content experts or editors or subject matter experts in the team to prepare the tags, hand it to the web designer so he can hand it off to the developers to put it into message bundles. Then they give it back to the designers so they can expose the strings in the view as EL expressions through the tag, or through the various methods that we have available to expose localized strings in JSF.

Another case where I think designers and developers can work together is creating the visual assets for the site. A web designer will typically work from an image template provided by a graphic designer, and take this image template and slice it up, then generate some HTML from that using Adobe tools. Once you have the raw HTML that the graphic design produces, then you have to take that, massage it, work with it and prove it, make it standards compliant, optimize it in various ways, and make it manageable and maintainable. That's the process of creating the HTML, the CSS, the images, and the static content of an application for the user interface level. Handing those creative elements off to the development team is one of those contact points in the workflow that we are talking about here.

Developers will receive the HTML and the creative assets from the designer. At that point they can mark it up with JSF tags. That is one way to work. However, the problem with that is, what happens if the design changes, the users come back and say, "You know, we liked that initially but now we want to alter the layout, we want to move things around." Developers are not necessarily trained in HTML and the prospect of going into HTML and changing the markup and editing things is a little bit daunting for some developers. You might not get the results you expect, and dealing with browser quirks, things like that, is not really our bread and butter, as developers. So it makes sense for an iterative workflow to happen where developers can say, "ok this is great. Now we need some JSF tags in the view. We want to change the layout and hand back the artifacts, the views at this stage, back to the design team and have them make some changes to it as well." This could continue until the UI is developed into something the users are happy with and the team is happy with. That's the collaboration model that I think is effective. There are several of these opportunities in the JSF workflow for teams to interact and to exchange resources and work together. I will talk about binding forms in a moment, that's another opportunity I think where we can collaborate.

The issues that I am seeing, some of the strategies I have learned about in my research and reading from experts like Jacob Neilson; sorry. Yes, Jacob Neilson is one of the experts I have read - he talks about web usability. I was actually thinking of another Jacob: Jacob Hookum who is, as you know, the Facelets creator. He has some interesting views on programmer friendly web pages, and how to organize things in a team environment so it minimizes the pain for the development team and the programmers. I can understand that. I think Jacob is a really smart guy and he has a lot of interesting ideas about JSF. Facelets clearly required a lot of thought and effort on his part and it's a fantastic contribution to the JSF ecosystem. At the same time I also enjoyed reading his blog and in particular his blog entry about programmer friendly web pages, where he talks about semantic contracts for JSF. He sees the problem I was describing, about the iterative workflow and what happens when a development team has already marked up or added JSF tags to a view. Handing that back to a design team that doesn't know JSF is a problem. I think Jacob's approach is what he calls semantic contracts. He describes it as an approach where design and development teams will meet at the beginning of a project, sit down, and agree on a set of CSS selectors for UI components.

What I think that entails is deciding ahead of time "for buttons we are going to use this class, .button for example. For text fields we are going to use .textfield. For data tables we will use .datatable. This establishes some set of CSS selector names, so that the designers can then go off and will understand the meaning of each of these selectors and can try to design around those semantics. The end result of this approach is the design team handing off CSS files to the development team, and the development team continuing from there on their own. Jacob talks about the idea of the development team being at this point basically free to do whatever they want with the view. They can write UI components. They don't even have to work within the page metaphor. While this makes sense from a development point of view, I find it somewhat of a programmer centric approach. What I am not thrilled about is that it limits the interaction between design and development teams.

My approach is a little bit different. I will describe Jacob's idea as the enhanced autonomy strategy, where the goal is to support the team's ability to work in isolation, minimizing the dependency on the other side. So from a development team point of view, once you get the creative assets, you are basically done. The interaction ends there so you are autonomous. The approach I have in mind that I would like to encourage teams to adopt or explore is what I call the enhanced collaboration strategy. This is where instead of having a onetime meeting between the design and development teams, you have ongoing meetings. Yes, you can agree on semantic contracts at the beginning of the project, but once the development team receives the creative assets from the design team, it doesn't end there. It is not just a "throw it over the wall" proposition where the design team creates the content and hands it off to the development team.

Rather, it's an iterative project so the development team could come back to the designers and say, "We would like to change the layout in these ways. Can you take it to the next step for us?" They could do it, work on it and give it back to the developers and why stop there? Why not go a bit further and offload more of the work to the design team and say, for example, "Could you guys bind the forms to these backing beans?" and have semantic contracts for your EL expressions. Then decide, for example, "For this form, we want to capture this information about each product: the name, the description the price, and so on. Design the form and then establish a contract based on the EL expression. Our controller for this view will be called the product bean and will have the following properties." Once you have established that, then the design team can go off and bind the form to the backing bean. As long as the properties and the methods of the bean don't change, the work is basically done. In my mind, it is a more effective use of those resources to share the content a little more between both teams and to interact a little bit more frequently throughout the project lifecycle

Just to summarize, basically I see the JSF context as an ideal situation for design and development teams to try to collaborate better. I have in mind an enhanced collaboration strategy as opposed to an enhanced autonomy strategy where teams can integrate more often, meet more often, and practice things like iterative development. If you are coming from an Agile background you know about pair programming. Why not pair UI development? Have designers and developers sit down at the same work station and work off the same set of tools for layout and presentation and work together that way. Pair up designers and developers. I see a more enhanced collaboration strategy where teams work together more effectively. I hope that answers your question.

Kito It certainly does. So Ian, do you think in this enhanced collaboration model it makes sense to work with templates that are pretty much like pure HTML pages? Or ones that are more like tag-centric, like JSP pages? What I am getting at is one of the inititial complaints about JSF was that "oh, the pages have all these tags. It's tag soup, and it is not easy for designers to work with." That is one of the things that people said Tapestry had, was the ability to have these HTML pages instead. Facelets has the ability to do HTML style templates, and also more XML tag based templates. From your perspective in this enhanced collaboration model, which one do you think works better?
Ian Okay, that's a great question. The question of templating has come up from time to time, and I have received questions from users about Facelets templating, and "which templating approach should I use?" As you know there are several options available for templating in JSF today. You can use the Facelets UI composition templates. You can use JSF Templating. You can also use Tomahawk tag or the Trinidad tag, which abstracts the entire document itself, and makes basically the document part of the component model, which then allows you to render the document in different markup languages more easily. You have basic templating support in JSP and in Facelets for doing server-side composite views, where basically you are just including headers and footers and menus as separate view items and combining these together into the page template. There are several technologies available. Questions come up from our users about "which one should we use?"

Fortunately for me, I have no doubt about which approach works best from a design perspective, because having worked with Dreamweaver for years and having significant experience with that tool, I know Dreamweaver has a built-in templating system that works very well. It is very simple, very easy to use, low complexity, and has a very short and shallow learning curve. It can be basically learned by anyone with reasonable skills with a computer in a short period of time. Of course Dreamweaver's templating system targets static HTML pages, which is not the ideal templating solution. But the important part is it can easily be combined with Facelets for a more dynamic templating solution. That is actually what my development team and I have been using for the last few years -- a combination of Dreamweaver templating with Facelets for UI includes.

I would like to touch on one of the points you raised there, which was Tapestry and the potential issue in JSF of the tag soup, and the promise that we could have a solution similar to Tapestry, where regular WYSIWYG tools would be able to render JSF pages without the need for specialized support for JSF. I think to a large degree that has actually been achieved. If you look at Facelets, it has this jsfc attribute which lets you decorate any standard HTML tag and treat it as a JSF UI component at runtime. That allows JSF tags to be incorporated into traditional web design tools that don't have any Java support or JSF support. It does leave a little bit to be desired though, because you are not working in the native markup language of JSF, the natural JSF standard tags, and as a result, it is a little bit unclear as far as which attributes you are allowed to use and which ones you are not. It's a nice low-barrier entry way to get into JSF if you are a designer and not have to learn new tags, but I think there are better alternatives. I tried that initially with Dreamweaver. I tried to just use an <input> tag from HTML and decorate it with JSFC <h:input> tags. It works, but there are better solutions.

I decided one thing that our tools should do is enable Dreamweaver to display visually the JSF standard tags, and allow designers to work in the standard markup language for JSF, the standard tags that it provides. What we have done is basically added support to Dreamweaver for JSF. As a result, now you can use Facelets, you can use Seam, you can use Tomahawk, and you can use Trinidad, ICEfaces. We plan on supporting many more JSF component libraries in the future. You can use these component libraries in Dreamweaver. Designers can work visually with these tags. They can drag and drop these tags to the design view. They can use the code view to do tag auto-completion. They can get contact-sensitive help about these tags as they are working with them, and get examples and reference information.

We have a wide range of features that are designed to support a JSF workflow in a Dreamweaver environment. There are some collateral benefits, which are you can combine Dreamweaver templates with Facelets templating features. This is really the solution that I recommend for design and development teams that are interested in combining the web design workflow with the JSF development environment. For one thing, it makes it really easy for designers to get up to speed. It is intimidating to try to learn Facelets UI composition templates when you have little to no background in Java or in programming at all. Conceptually it's a heavyweight model. It has to be, because without design tools that provide a templating structure, you need something like that.

Kito Right.
Ian You need Facelets UI composition templates to provide the abstraction and the maintainability of the view. Templating solutions in my experience are all designed for basically the same purpose, which is to simplify the design, development, and the maintenance of the presentation layer. I want to make things easier for designers and more efficient. So if you have a repeating view element like a header, that you want visible on all the pages of your application, you don't want to go through each page if you change the header and update it on every single page. That can become quite time consuming. A templating framework will provide you with the mechanism to extract or externalize this view method as a separate artifact and include it in all your pages. That way if you change the actual header file, it will change the header across the entire application. This is the kind of thing that Facelets can do.

Facelets of course goes further than that with composition templates. One of the things that Facelets allows you to do with UI composition templates is to define a template client and a template relationship where the request comes into the template client. The template client points to some template file that defines the layout of the page. So the template client page, or view, has these UI defined tags on it that basically specify the content to be injected into the template at request time. The response comes from the actual template, so the response is the result of merging this template client together with the template itself, and combining all the defined content with the insert tags in the template. This is actually a really beautiful idea and its really similar to what Dreamweaver has been providing out of the box for years and years.

Kito Really?
Ian Yes. It is the Dreamweaver templating mechanism. How Dreamweaver templating works is basically a parent/child relationship between a template and the rest of the pages in your site. You define the template, one or more templates for your application, which is basically just like in Facelets when you define the layout, the headers, the footers, the menus, all the styling and so on, the look and feel of your pages. You can also define what are called in Dreamweaver editable regions. These editable regions become the UI insert equivalent in Facelets. Then you apply this template to your various pages, so anytime you change the template, Dreamweaver will propagate the template change to all the child pages under that template's control at design time. It's a different strategy. Facelets does this strategy at request time whereas Dreamweaver does it at design time. You actually generate these Facelets pages at design time in Dreamweaver. It updates the content for you. This is a great solution for us because...
Kito Let's take a step back. You are saying it generates Facelets pages?
Ian Just to clarify, if you are using Facelets you have to create the pages first.
Kito Ok.
Ian But whatever you put into the template, it will propagate that.
Kito Right, ok.
Ian The reason I like this approach is because you get the benefit. First of all it is very easy to understand conceptually. You have a master template and if you change it, anything that is attached to it also gets updated. At the same time you can go beyond that and have a composite view approach, where the template itself is composed of a header, a footer, a menu, and other elements in the view. If you stick to that approach and combine Dreamweaver templates with Facelets UI includes to do SSI or the composite view style of templating, I think you get the best value because again, a web designer can learn this very easily and you are not limited to producing static HTML. You are actually working with a number of physical Facelets pages in your site, for example. They are being updated at design time. You can also use Dreamweaver to deploy these pages to a testing server or production server. It has some really nice content publishing features built in that can FTP it up to whatever server you want, or access the server on a network share or a local drive. The reason I recommend this approach, again, is because it is easy for designers to learn, and it lets you leverage Facelets templating to some extent.

We also support, by the way -- in Dreamweaver through our Facelets plug-in -- the design time rendering of true Facelets UI composition templates. For example, the Seam booking example uses that approach. The Seam booking example application demonstrates the Seam framework, but it also uses Facelets and it has a template and a variety of template clients that reference the template. We can render that in Dreamweaver. We render it faithfully and it totally leverages the Dreamweaver's excellent CSS and HTML rendering engine. You see not just the web page as it would look in the browser, you also see another layer of information that Dreamweaver superimposes on the view on the page to help you understand its structure.

For example, all the <div> tags will have a dash line surrounding them to indicate where block level elements are located in the view, and so on. There is a visual aid layer that Dreamweaver superimposes. It is very good for designers. You can work with all the design view tooling that Dreamweaver provides, in addition to its outstanding CSS panel, which is really first rate as far as working with CSS based design and augmenting even the layout table-based HTML pages with CSS. Dreamweaver really supports a flexible setup of design approaches in HTML and in web design. Our tools basically allow you to apply all this tooling to JSF and use it to create user interfaces for your JSF applications.

Just to summarize, templating is definitely an interesting area in JSF, and there are a lot of solutions available and that can be confusing. I think the fact that there are so many alternatives is a sign that clearly there is a need for a templating solution. From a UI designer perspective, I think the answer is fairly obvious to a web designer. If you are familiar with Dreamweaver templates, that's your templating solution.

Kito Right.
Ian So combining that with Facelets for UI composition templates, or rather for simple UI included behavior or the SSI composite view approach, I think is really the best bet for a templating solution. This lets you use standard JSF tags, moving away from the jsfc attribute, and actually using the real JSF tags themselves visually at design time in Dreamweaver. You also, again, get the benefit of something that is really easy for a web designer to learn and become confident with.
Kito Alright, so last question. We have touched on different points and different aspects of your product, of the JSFToolbox product. Tell us more about the product and the different variations.
Ian The product is called JSFToolbox for Dreamweaver. It was released in May of 2006. It is basically a suite of extensions for Dreamweaver, so it includes component support, syntax auto-complete for EL expressions. It includes drag and drop tag toolbars for all the JSF tags. It includes property inspectors for each JSF tag so you don't have to edit it in the code view -- you can actually edit it in the design view and set the attribute values through the property inspector. We have all kinds of extra goodies too. For example, we have this UI component tree panel which introspects the JSF component tree at design time. It lets you see a tree structure that represents the view, the UI component tree. This tree structure is navigable, so you can click on the various nodes and actually navigate the selection in your document to each of these nodes. If you know that there is an input text component in your form and it is inside of a panel group, and that is the specific component you want to access, you can navigate to it directly from the UI component tree.

We also provide visual tags for all the JSF tags, so for Facelets you will get visual tag support, from simple to complex Facelets templates. We also provide Seam tag support, Tomahawk components - for example, calendars and all the other input components and widgets that Tomahawk provides, like trees and so on. We provide visual rendering for those components in Dreamweaver. Trinidad, the same thing -- tabbed layouts and the rich variety of components in the Trinidad library -- we support all of them as well, visually at design time with all the same features that I have mentioned up to this point, so syntax auto-complete, context sensitive help, code hints, and all this stuff.

We also have product specific features, so for example in Seam, one of the value propositions of Seam is it allows you to use annotations to annotate your backing beans and to declare your backing beans instead of using XML, which is a nice alternative. What our tools do, if you have Seam tools installed, JSFToolbox will scan the classes in your web application's (WEB-INF folder and anything it finds in there that has a Seam @Named annotation, it basically will detect that and recognize it as a backing bean, and provide the code hint support for you. That's one feature that we provide specifically for Seam. We also categorize all the artifacts in the site in the components panel so you can see all the Java beans in there and everything gets categorized. UI components are categorized, message bundles are categorized, and you can navigate and browse through these artifacts that way. There are actually quite a lot of features. I don't think we have time to discuss all of them. I will just say quickly that basically we support JSF standard tags, we support Seam, Facelets, Tomahawk, and we have two other products coming out: Trinidad tools for Dreamweaver, and ICEfaces tools for Dreamweaver, which we hope to have out in the next month or two. We are also aiming to support the Mac OS 10 environment. We should have a version of our plug-in for Mac very, very soon.

Kito Ok, excellent. I do have a really quick question: what language is the plug-in written in?
Ian Great question. Ok, here is the situation. Dreamweaver does include its own JVM. It happens to ship with a Java 1.3 VM to do JavaBean introspection, which doesn't make it the most useful element of that tool at all. This was one of the issues we ran into right away. Yes, there is a VM available for Dreamweaver but it's 1.3 so if you write code in Java 1.5, compile it with the 1.5 compiler, and then try to import that code into Dreamweaver for bean introspection and code hints and all this stuff, it doesn't work because of the major/minor version conflict. You can't read code or run code with an earlier version of Java that was compiled with a later version. What we had to do was figure out a way to get a more recent version of Java available to Dreamweaver.

Our code actually has several components, several layers. There is a native layer, which is basically a set of DLLs that Dreamweaver loads in process at startup. What these DLLs do is, first of all they check your computer for a version of Java. We require Java 1.5 or later for our tool, so if we find Java 1.5 or later on your computer, great, we use that. If not, we warn you about it and say "you need Java installed for this tool to work." We also have a version available that includes the Java 1.5 VM that you can install. So for designers that aren't Java savvy and don't know how to download a VM from Sun we provide a distribution for them. They just have to install the plug-in and it includes Java. The native components check for the VM, either JDK or JRE, on your computer. If they find one, great, we use it. At that point we bootstrap a Java virtual machine - we actually load a VM in process with Dreamweaver and then kick off our main class which is basically our custom JSF implementation that runs in process with Dreamweaver.

Kito Really!
Ian Yep, the product is mostly written in Java.
Kito Fascinating.
Ian The UI is actually Swing based, so when you see progress dialogues and you see the JSF site wizard, you are looking at Swing dialogues that are running basically in native Windows application. That also allows us to do the introspection using the Java reflection APIs and work directly with your bite code. That's the other layer. Most of the code is actually in the Java layer.

There is also a JavaScript layer which is basically glue code between Dreamweaver and our DLL. There is quite a lot of JavaScript as well, that we wrote to actually process the data. We scan your class path and look for all the interesting artifacts like backing beans and converters and UI components and so on - we index all of this good stuff and put it into a little database. Then we send it up to Dreamweaver, to its JavaScript layer where we basically export it to all the Dreamweaver UI components, like the panels and the combo boxes and the code hints view and all that stuff. We just feed all this information up to Dreamweaver and it displays it to you. That's basically how it's implemented.

Kito Wow, that's cool. I was wondering about that because I don't know much about writing in Dreamweaver plug-ins, and I was thinking "they can't just have a Java interface for all this stuff."
Ian It was quite a challenge but we managed to do it.
Kito Cool. Alright Ian, well it's been a pleasure chatting with you. Thanks for coming to the conference and speaking. Hopefully we can have you again next year.
Ian Thank you very much; this was a great time for me. I really appreciate being here with all my mentors. I have your book, I have Ed Burn's book, I have David Geary's book, so for me to be here at this conference with all my mentors is a huge experience for me. Thank you very much.
Kito Alright, thank you.
Announcer That's it for this edition of the JSFCentral podcast .The music for this podcast was composed and performed by Kito Mann. Thank you for listening.


RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2014 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.