Level: Intermediate Dick McCarrick, Content Developer, IBM
14 Jun 2005 What better way to learn about IBM Workplace Designer than to talk to the people who built it? In this interview, we speak with three members of the IBM Workplace Designer team, discussing its main features and what we can expect in the future.
IBM Workplace Designer is an Eclipse-based development tool that allows you to develop applications for IBM Workplace Collaboration Services and other members of the IBM Workplace product family. You can learn more about IBM Workplace Designer by visiting the IBM Workplace application development page. On this page you will find links to the latest articles, videos, brochures, and other sources of information that can help you get started. You can also check out the IBM Workplace Designer online help, which ships with the product. IBM Workplace Designer is now available for customers to purchase and use; this interview was conducted shortly before the product was released.
In this interview, we speak with three members of the team that designed and built IBM Workplace Designer.
Please explain your role on the IBM Workplace Designer team.
Maureen Leland: I'm a Team Lead for Workplace Designer. I cover the overall UI: forms and controls, views, and so on. My team does a lot of work in this area. I think I bring the vision of Domino Designer to this product too, as I was Project Lead of the Domino Designer for approximately five years.
David Taeib: I am a Team Lead covering the scripting part of Workplace Designer and the underlying infrastructure connection to Eclipse and the Workplace Managed Client. I've been working at IBM for nine and a half years. Most of my life as a developer here was to work on a project called Domino Global Workbench. I've been turning my development path to Eclipse over the past few years, after discovering that has a lot of potential. I was very excited to see that Workplace Designer was going to be based on Eclipse because this is the perfect match -- Workplace Designer and the concept of Domino Designer-like artifacts and UI built on Eclipse was like a perfect match for me.
Philippe Riand: I am the architect of Workplace Designer. My role is mainly to drive the specifications and ensure that implementation conforms to these specifications. I've been on the Java platform since the early days because I think I was one of the early developers using JDK1.0. I also developed lots of Notes applications, and I'm very excited by Workplace Designer because it's bringing to the J2EE table the same concepts that we have in Domino.
Very briefly, what is Workplace Designer and what can you do with it?
Maureen: You can build a Workplace component that consists of forms. It lets the developer build a Workplace component in the constructs they are accustomed to. You're not building this J2EE thing; you're not coming up with servers and beans and JSP pages and all this dorky stuff. You're actually thinking "I have a form, I have buttons, I have edit boxes. I can script them." It's a form-based scripting tool like what developers are used to in Domino Designer so they can build a Workplace component in a way that makes sense with their existing skills.
But it's not just Domino -- if you don't know Domino, you'll still be OK. Visual Basic users will also be comfortable in this environment.
Philippe: I want to further this idea by saying that we want to work with the Domino community by bringing concepts that are friendly to them. But we want also to attract Java developers because currently the only options are really J2EE-based and are complex. And certain tasks such as deployment are not easy to do in J2EE. So, we want to move Java developers a step higher so that they can concentrate on business application and business code rather than on low-level code. So, Workplace Designer offers something that is not currently available in this world.
David: I'd like to further dive on what Phil just said. The key word, I think, is productivity. How can we keep the power of J2EE while at the same time removing its complexity and increasing productivity by developing in a very rapid way? Domino developers know how to do this. They develop applications in an environment where they can create and test an application with few modifications. They can then come back and add a new field, make a few aesthetic modifications, and then retest. So, for Workplace Designer, we tried to bring these features for automating deployment and testing to the Eclipse platform -- enhancements that make your life easier, that make you much more productive by automating a lot of little things that you would do manually otherwise. That, I think, is a big winner because in the J2EE world, mundane tasks such as writing the deployment descriptors and testing can be very lengthy and tedious.
In what ways is Workplace Designer comparable to Domino Designer? In what ways are the two products different?
Maureen: When you look at Workplace Designer, you see an environment that looks familiar -- not the same, but it's clearly updated. It's got a new look as is appropriate, but on the left you see your design components. They're parallel to the databases or templates you would be designing in Domino Designer. As you expand those, it's very similar to the Domino Designer bookmarks paradigm. And you've got forms, you have lists of design elements, you have script libraries.
Maureen Leland
One difference is that Workplace Designer has schemas whereas Domino has shared fields. The way we treat data is very different, that's a place where, frankly, I think Domino users are going to be happy because one of the great things about Domino is how easy it is to work with data, and one of the bad things about Domino is how easy it is to work with data! It's easy to work with data in Domino, but very difficult to manage the data in your application once it's all there. For example, you can use shared fields, and a shared field is really just one big, flat schema. In Workplace Designer, we formalize the schema as a way of representing your data. Over time, we expect to make Workplace Designer as easy to use as Domino, yet have the ability to control the structure of your data. If it's hierarchical, you can build your hierarchical schema and work with it in that way. It's powerful and controllable, and we're making it just as easy to use as Domino.
Another area of similarity is the programming pane. This looks very familiar, but thanks to David we were able to leverage the Eclipse script editing and we got -- well, I won't steal David's thunder but it's really cool (laughs). The programming pane will include things you've always wanted.
Philippe: Domino is document-based. In Workplace Designer, we are using XML, which is a well-known document format used to send data between the different ports. This is very important because currently when Domino developers are moving to J2EE or to this platform, they are facing an object programming model that they are not familiar with. They have to have classes, they have to deal with EJBs, they have to deal with these kind of things. The second thing is dealing with script. You don't have to create Java classes to be able to do some code on Workplace Designer (although you can if you want to). We have a JavaScript interpreter that also provides some @functions in relation.
David: The main message is that we are keeping the best of Domino and enhancing certain areas, particularly the use of standards. We are building Workplace Designer from the get-go as being industry standard. We're using XML, we're using XPath, we're heavily CSS. We are really trying to make it easy to interact with any other tools out there by bringing those and this component of standardization. Industry standard, quality standard, things like W3C raises all those kind of standards, that's the name of the game today. If you want to be successful, you have to be open, interoperable.
Philippe: You may want to get some documents coming from your partners and just deal with these documents in Workplace Designer and then send them out. And in this case you need a common format. This is why standards are very important.
David: It's very important and I do believe that this is going to make a big difference. We want to be comparable with any other big platform out there. We want to be able to eventually keep the door open to all kinds of standards.
The second thing is bringing the best of Domino to Workplace Designer, for example the concept of simple actions. We want those and we kept those in Workplace Designer, although very limited in the first release. We want to keep going on this concept of simple action because it allows you to do the job quickly. Going forward, we want to make it easy for you to construct the code and bundle it into simple actions that you can freely distribute as a plug-in, which is what Eclipse brings. This makes Workplace Designer as extensible as possible -- a very important point.
Much of our audience has a Domino background. How much of what they've already done can be leveraged into the Workplace Designer environment, without having to re-code?
Philippe: When you think about leveraging your assets, you have two different parts. The first one is leveraging your skills and your knowledge about this platform, and the second is leveraging what you already built with these skills. So, what we've got to do first is leverage the user's skills as much as possible. As we've already mentioned, we are bringing many Domino Designer concepts to Workplace Designer. That will help you leverage your skills as much as possible right now.
Philippe Riand
The second thing about leveraging assets is moving your application from Notes/Domino to this platform if you want to, if you have a reason to. We provide an import tool, but this tool is not designed to migrate an application to say, "Oh, I have my application in Notes. I want the same one in Designer. Let's push a button and I will have this." This is not the goal. The goal of the import tool is to let you quick-start your new Workplace application, but you are not migrating one-to-one. Experience proves that when you want to move from Notes to another environment, leveraging the new capabilities of the target platform for a one-to-one move is more work. So, we are letting people get a start with this Designer application by using an existing Notes form.
David: The import feature that Phil is talking about only targets the design of the application itself, not the data. It's pretty comprehensive. Of course, you will never get 100 percent of the design -- that's impossible except for a very simple case. The goal is to jump start your application in the Workplace world by giving you a head start. That's what the import from Domino is about in this release. In future releases, we'll be looking at ways to enhance this, based on user feedback.
Maureen: You can think of importing Domino data into Workplace, but you can also think of sharing it with Domino by having the Workplace Designer component operating on this data and having a Notes application operating on this same data. So another future goal is to be able to work with Notes data. I think that's an incredibly important goal and will help interoperability because there could be a standalone Notes client working on a database full of data, or it could be in the Workplace client or even some other client.
David: A new feature coming up in Notes/Domino 7 allows Notes to access DB2 data. This can also be seen as a conversion point between Notes and Workplace because now we are dealing with two platforms, working on the same back-end system.
What other areas in Workplace Designer will Domino programmers find surprising or unfamiliar?
Maureen: First, they're going to look for their view design element and it's not there. A view is not a design element in Workplace Designer. We have a few controls in Workplace Designer to encapsulate the visualization of a query, which ultimately is what a view really is -- in Domino, a view is a selection formula plus the visualization of that formula. In Workplace Designer, we have architected a separation of those under the cover. We haven't had time to do the full separation for the first release, so it still looks tied together. But ultimately you will have a query design element that represents your selection formula that you can apply to different visualizations, one of which is a view control which is a grid. So, when you're looking for your normal view design element, you have to go into a form -- effectively all views are embedded views now -- but we've architected it in a way to get that selection formula and we've allowed for future visualizations. That's one big difference between Workplace Designer and Domino.
Philippe: We are using XML on the schemas and I know that Domino designers may not be familiar with this. So, the first time it may be confusing for them because the Domino way to do things is to create fields -- multiple fields. And here they can change their minds because there are multiple documents, and the move is not automatic because they have to think a little bit differently to leverage this capability. Also, Domino developers are used to computed fields, and when they want to compute something, they put the computed field into the document and that's all. The way it works with Workplace Designer is a little bit different.
David: One thing that Domino Designer doesn't do is to save a form that had errors in the scripts. We are allowing it. (laughs) I'm sure that's going to be very popular. In Workplace Designer, you are allowed to save anything, even if it has errors. We centralize them into a special tab where you can see all the scripting errors that you have for all your forms. You'll be able to double-click and automatically open the form and go directly to the piece of script that has the error. This allows you to very easily manage all of the errors that you have in the scripts -- we built that from Eclipse. Another thing is images. You cannot have images embedded inline with the text. You cannot just add an image into a document. You have to bring the image into the component first, where it can be shared. We have an image design element which Domino has too.
Maureen: That's the advantage of being able to say "OK, we're starting fresh. How do we want to do it?" Now, all the images in your application are image resources so you can control them.
David: One other difference is the Workplace Designer palette, which Domino didn't have. You can drag and drop. We use a lot of dragging and dropping of controls. In Domino Designer you position your cursor into the form and say, "File and fill create fields." Here we have separated the concept of fields into multiple controls, into a palette, and now you will have a list of controls -- the edit box, button, they're all separated now. They are not like in Domino where you add a field and then you choose what it is.
David Taieb
We provide a very rich environment where we allow drag and dropping. You have a palette where all the contextual components that you are allowed to use appear and you grab them and drag and drop them anywhere you want into the form.
Philippe: And there is a very big difference between Domino and Workplace Designer in that in Domino, when you design a form, you design both a UI and a key amount of data from implementation of your documents. In Workplace Designer, these concepts are separated. But we know that the way people use Domino is very popular, and it's great. So, you can have the exact same user experience that you have in Domino but now the concepts are greatly separated and everything is automated. You can use the 'Domino way' to develop your form or you can use, let's say, another way in which you design your schema or get your schema from a third-party provider, and then just put a UI on top of the schema. Both modes are available.
What scripting language support is available in Workplace Designer?
David: At the moment, the main scripting language where you can write business logic is JavaScript. So, we have JavaScript Interpreter in the runtime that allows you to write business logic. We have decorated this engine with a set of @functions that looks like Domino, so that the user will be able to use them the same way they use it in Domino Designer. The environment itself uses the Content Assist, which allows you at any point to break, to call out some kind of a helper that will tell you what can you do to complete the current keywords that you were trying to find. So, let's say you type the @ sign and you type Ctrl-Space and automatically there is a pop-up window that lists for you all the available @functions that you could use. Again, this allows you to increase your productivity.
On the left side of the UI we have a contextual reference tab that shows you all the objects -- the global objects that are available to you at any time. So, it is very contextual. It's a very rich experience for the user to use JavaScript in such an easy way.
We also support the concept of a script library (borrowed from Domino) where you can encapsulate snippets of code such as JavaScript functions into design elements and then invoke them from anywhere in your form by importing them. You use "import" and you go. You will see all the script library available to you and as soon as you implode them, the reference tab on the left shows all the functions and global objects available. You don't have to go and say, "What did I put into that script library?" It's right there. And we also allow you to directly jump into opening this script library by using the control key and hovering the mouse over the import statements -- click on it and this quick library is open for you to review.
Philippe: We provide a set of JavaScript wrappers with Java API, which makes access to these APIs a little easier. We've provided a set of libraries that really ease the access to this library by just calling one function. And the way to carry your XML documents or duplication with your XML documents is the start of XPath. So, XPath is completely integrated with Workplace Designer and you can mix and match JavaScript and Xpath. You can execute an XPath within the JavaScript code just to query a document.
David: We have a very comprehensive XPath editor with helpers and all kinds of goodies around it that make it easier to write XPath for those who don't know how to do it.
What deployment features will be in Workplace Designer?
Maureen: Deployment is fairly easy. We've designed for iterative test and deploy and iterative development of your application. So in short, you have to initially fill out one deployment profile. Your design is in the local file system on your design machine and then these files have to get to wherever the server is. This may be on your same machine (and in our pre-release it will be typically your own machine) or it may be a shared departmental server or test server. For that, you would set up this deployment profile that asks you a number of questions, such as what's the name of the server, what's the user name and password for the server, and what database are you using, Cloudscape, DB2, etc. Once you have that set up, then you just right-click on your component and say "deploy," and boom! It's there. Then you go and change the color of an edit field to yellow and you want to see what that looks like, you just redeploy it and you go look at it in your browser and you're done. So, it's pretty quick.
That's for your testing design phase. Once you're ready to ship this, then you export your application into a WAR file and ask an administrator to put it on a real production server somewhere.
David: All those features are built in to the product. There's a menu for them, just follow them. It's very, very seamless.
Philippe: We know that J2EE deployments in generally are a pain for people, so as Maureen said, we have two different sides. We have the WAR deployment to the server, and we have the database creation. Everything is completely automated for you -- it's a dream for J2EE developers. And then if you are an administrator, and you want to have more control of what you generated and what you're doing on the server, then you can build through the server standard J2EE deployment mode by providing for the database and the Web application. But again, this is not mandatory. You can go the easy way.
David: The first time you deploy your component, it might take a few minutes, but right after that it's a breeze. It takes a few seconds really. That is very important for those who like to have a productive department.
What's the relationship between Workplace Designer and Workplace Builder?
Maureen: Workplace Designer builds Workplace components. Workplace Builder lets you place these components and arrange them on a page. It's a cooperative relationship.
David: Workplace Builder is a higher-end tool than Workplace Designer because Workplace Builder doesn't dive much into the content of your Workplace component. Workplace Builder allows you to parameter things called "points of variability." I'm sure people who are familiar with Workplace Builder know about them, but Workplace Designer allows you to generate this variability that Workplace Builder is going to use to parameter an instance of the component.
One thing we haven't talked about is component scripts. These allow you to add business logic to the event life cycle of your Workplace component. Workplace Builder defines a life cycle for components. When you create an instance of a component, there are a lot of events being fired off, such as create instance, remove instance, and add members. We allow Workplace Designer to put in script, to add programmatic logic to those events that are going to be consumed by Workplace Builder. It's the equivalent -- Maureen, tell me if I'm wrong -- it's the equivalent of the database script in Domino...
Maureen: Yes.
David: ...where you had little scripts that would fire when you opened the database, when you closed the database. Those can be seen as similar to Domino Designer.
What possible enhancements do you see for future releases of Workplace Designer?
Philippe: We'll move the runtime. Currently the runtime is hidden to a user of Workplace Designer but, as we said, we want to really make the platform as open as possible and share some artifacts with Rational. So the next runtime for Workplace Designer will be based on JSF. We are putting some, let's say, framework on top off JSF that will let us put Java in the script engine to do the server scripting. This, obviously, supports JavaScript, but it's also an open door to over 15 languages. A third party can provide its own script language.
David: We're thinking about adding workflow. Another thing is charting -- PI, graphs. All those are going to come alive as yet another design element in your component. It also would be really, really interesting to allow business partners to create their own design element types. That would be very, very powerful.
Philippe: And the new JSF runtime will also provide a comprehensive component model so that you can bring your own components into the form very quickly and you won't have to be a Java developer to develop a component. So, you just take some parts, you add something, and you make a component.
Maureen: That's where our making everything be resources really helps with componentizing and sharing things. That was important to our design.
David: Debugging. In the first release of Domino Designer, we have a debugger file, JavaScript Interpreter that's not officially part of the product, but is included as a technical preview. This will be a fully implemented feature of the next release. Debugging is very important, and we plan to add as much functionality around the debugging as we can.
Philippe: I can't give you a date right now, but we plan to support Portal development. We plan to synchronize; we have Rational Application Developer 7.0 coming that will provide Workplace Designer with a set of plug-ins. This is related to what I said at the beginning of this interview; we want to interest the Java community by giving them some high-level concepts that can enhance their productivity. They will be able to use Workplace Designer for that. Of course, developers don't have to use Rational to do this, it's just one option.
David: Once again, we are a set of Eclipse plug-ins that we have this ubiquitous way of doing things. We will be able to be used in Rational Application Developer 7.0 and automatically use all its features.
Anything else you'd like to tell our readers about Workplace Designer?
Maureen: It's the coolest product on Earth!
Resources
About the author  | | | Dick McCarrick is a content developer for developerWorks: Lotus. Previously he was a member of the Domino/Notes Documentation team for over 11 years, playing a variety of roles in documenting many major components of Domino and Notes. He also wrote the occasional article for Iris Today (including Ask Professor INI) before joining the Notes.net/Lotus Developer Domain team permanently in 2002. In his spare time, Dick's leisure activities include running, fishing, woodworking, and reading about the natural sciences. An avid astronomer, he's former director of the Bridgewater (Mass.) State College Observatory. Dick lives in Vermont. |
Rate this page
| 
