Tuesday Nov 29, 2005

JavaPolis 2005

I will be speaking at JavaPolis in Belgium in less than two weeks. I hope to see some of you there. I'll be doing a Creator talk from 3:30 to 6:30 on Monday Dec 12th. Wow, three hours... Seems like a lot but I bet time will fly by. It certainly did during my Creator demo at NetBeans day where I only had one hour. Here's the agenda:

  • Leveraging Java Studio Creator's JavaServer Faces component library
  • Using simple drag-and-drop data binding procedures
  • Using an AJAX test completion component
  • and much more.
NetBeans has a strong presence too.

Media Player

Marco has developed a JSF component which lets you embed a media player in your web pages. Given that it's a media player, not a simple HTML include, you can control the player url etc. from java code in the page bean. See Marco's blog for more - and note that there's an installable component library inside the distribution file (which also contains all the source code).

Here's something you can play with that media player: Sun Developer Network, SDN, has started a monthly developer TV channel featuring interviews and topic segments. The first show aired two weeks ago - but of course you can download and view the video anytime. The first program was directed at college students and talked about how to get into the industry. I'm one of the interview subjects.

Thursday Nov 17, 2005

A Personal Touch

The Creator website has had an extreme makeover. In addition to the new organization of the material, most of the graphics feature members of the Creator team. These images have captions, so you can read more if you're interested. If you click on the Community link for example, you'll see (at the bottom) a team picture of most of the team. (The team is actually larger than that; you can find all the names in the Easter Egg...).

In the Code tab you'll see Joe and I discussing some component metadata. We really needed to talk that day so we didn't have to fake discussion in front of the photographer. The feature we discussed was how to let components specify metadata that allows inline text editing for components that have multiple text related properties. I implemented that portion in the designer the next day, so with the next drop of Creator you'll see improved handling for components like Alert, where you can click and edit either the Detailed message or the Summary. Ditto for Labelled components etc.

I know they have more photos of team members they want to use, so the site will continue to be updated...

Wednesday Nov 09, 2005

Cool new Creator demo

Check out this cool new Creator demo. It's a pretty quick yet informative introduction to what Creator is all about.

Friday Nov 04, 2005

Free Creator Licenses

Check the NetBeans web page right now - over on the right side. There's a link to a site where you get free access to Creator. No, not the already free Early Access version of Creator 2, but a license to the stable release - Creator 1. My impression is that this license will also be good when Creator 2 is released.

Thursday Nov 03, 2005

CSS Style Sleuthing

"How did that text end up with a blue color?"
"Why doesn't my style rule to add underlines on links work? Is some other rule overriding it?"
"What style class do I need to override to change the font size of my Table headers?"

These are some questions you may ask yourself when you're designing your web applications using CSS. Whenever you're dealing with CSS, the Mozilla DOM Inspector is your best friend. It lets you examine the CSS rules and computed styles for each of the elements in your document. While it is extremely helpful in answering these questions:
"What CSS style rules apply to this element?" and "What computed styles apply to this element?"
it is not as helpful with the (in my opinion more important) earlier questions. For example, to find out how a particular element ended up with a blue color, you need to start at that element, then look at all the style rules applying to the element, look through its style declarations, see if any have anything to do with color, and if not, go up to its parent element and repeat the search.

Fortunately, there's a trick you can use: Creator's hidden DOM inspector. This is a tool which is not a supported part of the product; in fact it's a facility I added to aid debugging the webform layout engine itself. But it turns out many of the questions I have to ask are the same ones a page designer will ask: "How did that box end up that wide", "What HTML did that component render", and so on. (I have blogged about this before, but there are new facilities in there for CSS debugging which now sets it apart from the Mozilla DOM inspector.)

Here's how it works. Control-alt click on a component. The nearest CSS box computed around the mouse click is selected with a red highlight, and the property sheet selects a lot of the Box properties corresponding to the HTML element rendered for the component. (Most components render multiple elements; the DOM inspector works at the HTML level so you get to see how rules apply to individual HTML elements.)

A couple of months ago I also added a little window display showing the box hierarchy, so you can easily walk up and down in the box tree, like Mozilla's DOM inspector lets you walk through the HTML Element tree. One important feature here is that ask you click in the displayed page, it expands nodes and selects the corresponding box. That's a feature I've always missed in Mozilla's DOM inspector. Anyway, this part may have been added right after EA2 went out so may not be available in your version yet. But you can walk the hiearchy by pressing Escape to select the parent box. Without the box tree window there's no way to descend; you'll have to click on a box to select the closest leaf and then work your way back up.

Here are the windows:

In the Layout Info window (on the left), the HTML tag is shown in angle brackets <>, and then the JSF component (if any) id is shown in italic.

The property display displays a number of interesting properties. I may get back to some other ones later. But for CSS debugging, there are two that really matter.

First, Computed Style:. If you open the customizer, you'll see something like this:

This tells you a number of things. First, an asterisk (\*) on the left tells you that the value shown is different from the default value of the property (e.g. has been overridden by somebody). You then see the property, and the actual computed value. The CSS2 properties are listed alphabetically.

Then, and this is the important part, it will try to tell you where that particular value is coming from! This is shown as the stylesheet name with a line number. This helps you answer the initial questions. You can find the rule which is overriding your intended rule.

(Note: Sometimes the line numbers are wrong - off by a couple. Sometimes the line numbers are completely wrong. This happens because I deliberately implemented the code which tracks style usage to be extremely low overhead (since it's for debugging only), and in particular, the CSS code tries to share Value objects when possible. In cases where a single value object is used in multiple places I cannot attribute different usage references, so only the last one is recorded. Luckily, this doesn't happen with attributes you are most likely to be interested in: font size, color, width, height, etc.)

A second related facility is the "Rules" property. This property lets you view which CSS rules apply to a particular element. It is similar to the facility in the Mozilla DOM inspector.

(I added this property when checking my performance optimization for CSS rule checking, so it may not yet be in the version you're running.)

Here's a slightly different example. Take a look at the google page for example. If I click on the word "New" (which is in red) because I wonder where the Red is coming from, I see this in the Computed Style property editor:

As you can see, the color property is getting its value from an HTML attribute. Indeed, the JSP contains this:

<font color="red">New!</font>
The color is coming from the color attribute. It's not always a direct mapping; for example, a bgcolor attribute maps to the CSS background-color property, etc.

Note that since this is a debugging tool, I have packed in a lot of information, and this information is not cached in any way, so the display is pretty slow. Also, the window is not tried to be kept up to date etc. so sometimes you need to close the Layout Info window, and reselect boxes on the designer surface to see their updated properties etc.

By the way, on the Mac, you need to use Alt-Click instead of Control-Alt click, because Ctrl-Alt click is "reserved" on the mac.

Happy sleuthing!

Wednesday Oct 19, 2005

Security: Block worms from your abusing your web apps

I came across this fascinating piece about a worm that spread quickly through the MySpace web site. What's remarkable is that the web site had pretty good security. The person who did it used some pretty clever techniques to make it work. I highly recommend reading the write-up, and especially his detailed explanation for how he worked around each security measure.

Briefly, since the site lets you enter HTML in your profile, he wrote very clever HTML that would get executed in other people's browsers whenever they viewed his profile. The executed HTML would automatically do various background posts (using ajax techniques) to automatically execute a requests and confirmation responses on their behalf. It would have the author added as a "friend" to the account, and then it would add the same html code to the new user's profile such that anyone viewing this profile would become "infected" in the same way. The worm spread to a million users in a matter of hours!

Myspace already had various security measures in place, such as blocking out dangerous tags, and removing strings such as "javascript" and "onreadystate" completely. He got around that by taking advantage of browser bugs. For example, even though myspace removed references to javascript, it would not remove java\\nscript, and it turns out IE will still recognize this as a javascript URL, even with embedded newlines in the name! As another example, even though onreadystate is blocked out, he could use his ability to execute JavaScript to reconstruct it with string concatenation:

 eval('xmlhttp.onread' + 'ystatechange = callback');

Fascinating. This got me thinking. What if you wanted to have a Comments feature on your web app written with Creator. You want to allow the user to enter some HTML, such that they can add emphasis, use paragraphs etc. But how do you prevent HTML that compromises your web site?

It seems like a really safe way would be to prevent any HTML attributes from being entered! As long as you don't allow attributes, and you don't allow the style or script tags, you should be safe. This may be overly restrictive, especially for a site like MySpace which tries to let users customize their pages visually. But at least for a comments feature it should be viable.

I took a quick stab at this with Creator. What we'll do is this: Use a TextArea component for the comment. We'll add a Validation event on the text area, and the validation will check the string for suspicious text. If it sees a problem, it will raise a validation error, and the messsage will be displayed in the Message component associated with the text area. I drop the components, then right click on the text area and choose Add Event Handler | validate, as shown below (click for full size):

Now we'll just need to write the code. Once you add the event handler, you're placed in the source editor and get to edit your code. By default you get a simple comment telling you roughly how to write a validate event handler:

    public void textField2_validate(FacesContext context, UIComponent component, Object value) {
        // TODO: Check the value parameter here, and if not valid, do something like this:
        // throw new ValidatorException(new FacesMessage("Not a valid value!"));


Here's a simple implementation - pretty naive. It doesn't try to properly parse the HTML, it just looks for occurrences of <, and when found makes sure that it's properly matched with nothing other than an approved tag and an optional / at the front or end. Am I forgetting to handle some other tricks worm developers can take advantage of?

Here's the event handler - shown as an image since many news readers completely butcher formatted text in attempts to make blog entries comply to their site style; click link for text version.

Here's how this looks at runtime:

(No, the error text didn't magically move from the top of the text area to the bottom; I moved it between taking the first screenshot and taking the deployment screenshot.)

P.S. Don't forget to hook up the Message component to the text area, such that it displays errors raised in the text area's validator. Do that by dropping it, then follow the advise listed in the default message area on screen text: Ctrl-Shift Drag from the message area to the text area (or vice versa). If you use a Message Group component, you don't have to "bind" it to any components; it will display error messages from any and all components on the page. It's a good habit to always have one during development.

Thursday Sep 29, 2005

Mixing JSF and HTML

A subject that comes up regularly is how to mix HTML with JSF. There are several gotchas and limitations you need to be aware of.

  1. The "content inter-weaving problem". The issue here is that if you mix and match JSF components and normal "plaintext", these are processed separately, and it's possible for the text to appear out-of-sync with the component. See this article for more information. However, the good news is that this issue is fixed in JSF 1.2! (Creator however is still using JSF 1.1; JSF 1.2 is not out yet.) You need to be aware of this issue, and obviously test your application thoroughly. The problem does not show up at designtime in Creator because we don't process the page using the normal JSP engine.
    • You can use a <f:verbatim> tag around your markup to make it "JSF friendly". This will force the embedded text to be processed by JSF rather than the JSP handler, so the right thing will happen.
    • In Creator 2 you can also use the <ui:markup> component. It's easier to use than <f:verbatim> for some use cases. It's in the Advanced palette.

  2. Components that render their own children frequently don't handle HTML child content. (Examples of these are the Data Table, and the Panel Grid components.) These are the UIComponents that return true from getRendersChildren. These components specifically state that they want to handle rendering of their children themselves, and unless they are really careful, they won't pick up the HTML markup children nodes (whereas the standard child iteration used for most components does get this right.) Thus, for these components you need to resort to the <f:verbatim> technique again.

  3. By now you may wonder why you wouldn't ALWAYS just put <f:verbatim> around your HTML tags - and all your problems would be solved. The problem is that what verbatim does what its name suggests - it renders its child content verbatim. That means you don't get to put other JSF components inside of it! You'll see your JSF tags emitted as text. In other words, you can't freely insert <div> tags around your JSF content to do normal HTML page layouts.

  4. Your HTML needs to be well formed XHTML. This isn't necessarily a JSF requirement, although it should be noted JSF emits XHTML, not HTML. However, Creator requires this. Specifically this means that you need to remember to close your tags - I've often seen people write <br> which is invalid XHTML. It needs to be <br/>. As another example, remember that your tags need to be lowercase - don't insert <STYLE>color:blue</STYLE>.

  5. The way you actually add HTML to your web pages is to switch to the JSP view and edit away. However, note that you don't get to write plain HTML there, because you're actually editing an XML-formatted JSP file. Tags work the same way as in HTML - you can for example add <hr> to add a horizontal ruler. But entities are different. They need to be "XML escaped". If you want to write the HTML entity for the Spanish n for example, ñ, you cannot simply write &ntilde;. You have to replace the & with &amp;. Thus, if you want the page to render in the browser as Piña Colada, in HTML you would have had to type, Pi&ntilde;na Colada, but in the JSP file you need to escape the & such that you end up with Pi&amp;ntilde;a Colada.

With all those potential problems, you may wonder why you should bother with HTML at all? It would be ideal if you didn't have to. However, if you restrict yourself to standard JSF components there is simply too much markup you cannot get to. For example, you cannot add a horizontal ruler since there's no component for that. In Creator 2 we have a new component library which adds a wide array of new components.

However, there are two remaining areas where you might find yourself resorting to HTML.

  • Flexible layouts. If you want to achieve a really advanced layout that offers good resize behavior etc. you may need to resort to old-school HTML tables with rowspans and colspans. However, I urge you to consider using CSS for your layouts instead. It may be a bit harder at first, but it will pay off. True, CSS is not supported well in older browsers, but many of these older browsers aren't supported for similar reasons in the existing markup rendered for many components already.

  • Pre-existing content. You may have existing HTML that you want to reuse directly - perhaps it was crafted by a web designer and you want the same look in your JSF app with no rewrite effort. You can import these into Creator using File | Add Existing Item. The screenshot on the right for example shows the java.net page imported into Creator. The import mechanism will not catch all the gotchas above however so you need to Test, Test, Test.

As should be evident from the gotchas list however, you need to consider this carefully.

Tuesday Sep 20, 2005

Page Fragments, Entities and Characters

Switch to your JSP, and inside the body tag, type

One Piña Colada, Please!
If you run, you should see the expected text in the browser.

Now try the same thing, but edit the text inside a page fragment. If you deploy, you'll see this in the browser:

One Piña Colada, Please!

Uh oh! What happened?

Turns out the app server doesn't realize that the page fragment file, the jspf file, should be interpreted as an XML-formatted JSP, just like the main document. As a result, the source fragment file (which is just a static JSP include behind the scenes) gets, well, mistreated. You can see a very similar thing with entities. If you go and insert JSPX entities in your fragment, these will not be correctly expanded and instead of spaces you'll see things like "&nbsp;".

Here's how you can fix this. You basically need to tell the deployment container that it needs to treat .jspf files as XML formatted JSPs. Unfortunately, you can only do that using JSP 2.0. That means this won't work on deployment containers that don't support JSP 2.0. The bundled one, Sun Application Server 8.1, does (as does 8.0 which we shipped with Creator 1.0, so this solution works for Creator 1.0 as well.)

Switch to the Files view (it's in the same window container as the project navigator), drill into your project, then open web/WEB-INF/web.xml. Switch to the XML view. Replace the root <webapp> element with the following:

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
And then inside the body, insert the following:

This is how this should look:

Now when you deploy, the page fragment text should be treated the way it's supposed to - and your Piña Colada will be on the way.

So why don't we just add this configuration info to the default web.xml we ship with Creator? Well, then you would no longer be able to use Creator with any older app servers. We're trying to hard to be compatible. However, we might be able to do something better here. I'll talk to Mr. Deployment to see what we can do.

New Creator Blogger

Say hi to Winston Prakash - another Creator developer who now has a blog. Winston wrote the new CSS editor in Creator 2 that I described a while back. I sometimes call the CSS Editor the Winston Editor...

Saturday Sep 17, 2005

JSF Refactoring Support

Creator 2 EA2 now supports JSF refactoring. Take a look at this screenshot of the Refactoring window:

You might think supporting Refactoring is a slamdunk since we're built on top of NetBeans 4.1 which supports refactoring. However, notice that we're doing a lot of JSF specific stuff here.

  • We update value binding expression references
  • We update navigation rules
  • We update managed beans definitions
  • We update web.xml if the start page has been renamed

Eric had to do a lot of work to get our Creator source modeller to play nice with the NetBeans one. Yes, we're working to resolve this architectural redundancy - that was partly the agenda for the August trip to Prague. Here are some of the suspects at our favorite breakfast bistro in Prague: Robert Brewin, Tom Ball, and Eric Arseneau. Yes, the Eric who did the Creator refactoring work. This particular cafe serves the largest lattés I've ever seen; not quite "Big Gulp" size but certainly a healthy morning dose to combat jet lag!

Wednesday Sep 14, 2005

New Bits Available! New Features!

An update to the early access version of Creator 2 is now available.

The high level changes in the update are described here.

Here's my own list of stuff to look for in the update - heavily skewed towards the changes in the designer and related areas!

  • It now runs on (and in fact, ships with) JDK 5.0.
  • Various memory leaks have been fixed so it doesn't deteriorate over extended use. However, performance work is still ongoing.
  • We now have inline editing of buttons, textfields and textareas as well. Note that when you drop a button you immediately edit its name. This is to strongly encourage you to provide a specific label rather than relying on defaults (which vary from browser to browser, and can interfere with your layout.) To enter inline editing mode (which is done by default for buttons, but not for text fields), click twice, or hit F2, or use the Edit <Property> context menu item.

    (Tip: When you're editing text in a multi-line text field, enter inserts a newline. To commit the text edits, hit Shift+Enter, or as with any other inline editing operation, click outside the inline editing component. Press Escape to cancel editing.)
  • Some new designtime behavior has been added for components. Check out the Tab Set for example. They now come pre-configured with an associated grid panel for each tab. The components placed in this grid panel will show up only when the associated tab is selected. Finally, easy tab panels without needing to create multiple pages! And in the designer you can click on the Tabs at designtime to automatically switch the rendered view so you can easily design each tab.
  • The property sheet shows values that are different from the defaults in bold! See screenshot; style and text properties have been changed, whereas the columns property, 20, is just an inherited default:
  • Page fragments work better now. I'll probably blog on that separately.
  • Component metadata can now specify the default text for event handlers. These are now more helpful, hopefully giving you some specific hints as to what you need to do. For example, if you add a validate event handler for a text field, the default method inserted in your page bean is this:

    Note also that the parameter names in the event handlers are much better (they used to be composed by simply taking the capital letters from the type name; e.g. a FacesContext parameter would be named fc.) As you can see, it's now named context, just like in the interface definition for Validator.
  • Creator now supports JSF refactoring. I'll wait a couple of days and see if Eric blogs on it (he did the work); if not I'll talk more about it.

Please take it for a spin and give us feedback.

Friday Sep 02, 2005

In Alignment

I just fixed the part of the designer layout engine which aligns inline boxes. Specifically, I'm now computing the baseline of form components like buttons and textfields, such that rather than aligning the bottom of these with the text baseline, the baseline within the components are baseline aligned.

This looks a lot better - especially for things like radiobuttons. Take a look at the before and after shots. And unlike most weight-loss advertisements, I promise I'm using the same lighting and lens when taking these two snapshots:



There's a lot to point out here. First, notice how the radio and check boxes now seem centered next to the text. Second, and more importantly, notice how the labels in front of the text field and dropdowns are properly aligned with the text inside these components. This points right to something else you should know about: the Label property of many of these components. If you set the label directly on the component, it's rendered along with the component and gets proper baseline alignment as shown here. If you drop a separate Static Text or Label yourself, it's not "one" with the component and won't move as a single unit, render into a single <span> rendered by the browser, etc.

Tip: Notice also that by setting the Required property on the dropdown and text fields, the label automatically got rendered with a little red asterisk indicating to the user that it's a required value. This even works when you use a separate Label component; as soon as you bind it to another component (by ctrl-click and dragging from one component to the other to link them) the required property will propagate to the label.

As another example of where the alignment bug shows up, take a look at the bottom row of the new table component once pagination has been added in its customizer. Notice how the Page text field is really misaligned from its "Page:" label. This was the bug that inspired me to fix this.

Here's how the bottom looks now - pretty darn close to what browsers will show:

I just put this fix in, so it will not be in the EA 2 bits. EA2 has left development engineering and is getting some TLC from the QA organization right now. Stay tuned.

Friday Aug 26, 2005

Say Hi To Marco

Say hello to Marco "Deployment" Walther - another developer on the Creator team. He has just started blogging.

In addition to being in charge of all the deployment machinery in Creator, he's also the guy to go to if you have any Linux questions. Which should be obvious from his second post!

Fly your own airplanes!

I was just going through my buglist for the webform designer in Creator, and came across this request:

Synopsis: way to turn off GIF animation in designer
Description: Maybe this is simply an IDE option for Visual Editor. I'm inclined to think the default should be off. They can be pretty distracting...

In case you didn't realize it, if you insert animated gifs in your web page, the designer will preview the animation at designtime too. Here a user is asking for the ability to turn this off, since animated gifs are distracting.

My first thought was: You are about to inflict annoying animation on your users, so shouldn't you have to put up with this yourself? It's a bit like the reverse dog food test. Or, more recently at Sun we like to say we "fly our own airplanes" - e.g. use our own products. I'm not sure where the saying comes from, but clearly as a customer you have more confidence flying in a plane knowing that the people who built the plane also fly it. The reverse situation is that if you don't want to fly your own airplanes, you shouldn't force your customers to either. And that's what asking for distracting images to be hidden at designtime sounds like to me.

By that line of reasoning I guess I should implement designtime support for the <blink> tag as well! And it raises the question of what I would do if users requested a new JSF component which creates a pop up ad in user browsers, one smart enough to defeat most popup blockers.

Making it easy for people to create annoying web apps feels a bit like making weapons... on the other hand I'm probably getting way out of hand here. Simple banner ads are used to pay for web sites that are free for use, many of which I use. And of course, even Creator has been advertized using banner ads.


Tor Norbye


« July 2016