Monday, July 14, 2008

textformat NOT AWOL in OpenLaszlo 4.1

UPDATE (14 July 2008): I am updating this blog entry (striking out certain text and adding other text) to be more accurate in light of Henry's reminder (see comments) about an important part of the migration to OpenLaszlo 4.1. As part of this update, I also added "NOT" to the blog entry's title.

As I was adding tool tips to the OpenLaszlo RSS Reader that I blogged about earlier, I noticed that the hyperlinks to blog entries no longer worked. I turned on the Laszlo debugger and the reason for the absence of hyperlinks in my RSS Reader was made evident as shown in the following screen snapshot (click on image to see larger version).



The debugger shows by the comment "call to undefined function textformat" that something had happened to the textformat object I was previously using. All of the other debugger output is directly due to this not being found.
I confirmed that there is no textformat file in my OpenLaszlo 4.1 installation directory despite it still being listed in the OpenLaszlo 4.1 LZX Reference Manual and being discussed in Chapter 22 of the OpenLaszlo 4.1 Application Developers Guide.


The piece of code that had been using textformat and which was now not serving up HTML links anymore is shown next (as shown in the earlier blog - see that entry for remaining code and context):


<handler name="ontext">
htmlLink = new textformat(); // LzTextFormat is deprecated
htmlLink.setAttribute("url", this.getText());
htmlLink.setAttribute("target", "blank");
this.setHTML(htmlLink);
this.setTextFormat(htmlLink);
</handler>


The code that was now leading to the debugger output error messages is highlighted above.

As Henry points out in the comments to my original version of this blog entry, and as documented in the OpenLaszlo 4.1 Release Notes (see section "Upgrading to OpenLaszlo 4.1"), "user classes are no longer defined as part of the global namespace" and are now instead specified with lz. in front of the user-defined class. Apparently, textformat (or lz.textformat now) fits this description.


The next code listing shows the simple addition of lz. in front of textformat. This was enough to fix the debugger warnings and make the hyperlinks work again.



<handler name="ontext">
htmlLink = new lz.textformat(); // LzTextFormat is deprecated
htmlLink.setAttribute("url", this.getText());
htmlLink.setAttribute("target", "blank");
this.setHTML(htmlLink);
this.setTextFormat(htmlLink);
</handler>


I was also able to get this to work again with the new handler shown next that doesn't use textformat (or lz.textformat) at all:


<handler name="ontext">
<![CDATA[
newUrl = "<a href='" + this.getText() + "' target='_blank'>"
+ this.getText() + "</a>";
this.setText(newUrl);
this.setHTML(true);
]]>
</handler>


In the new handler that doesn't use any form of textformat, because I was building up an HTML anchor tag myself in the JavaScript, I needed to use a CDATA block to tell the OpenLaszlo XML parser to not try to parse this JavaScript. The functionality now works exactly the same in the OpenLaszlo 4.1 environment either using lz.textformat or manually generating HTML.

Related to this, it is exciting to see in the blog entry OpenLaszlo 4.1.1 is Coming and More... that we can expect to see 4.1.1 out soon (probably within a week) to address some issues identified by the OpenLaszlo community. That blog entry also mentions the possible release of OpenLaszlo 4.2 with SWF9 alpha support by the end of July. Finally, the brief text entry Use JavaScript 2 Today with OpenLaszlo mentions the upcoming OpenLaszlo 4.2 release and its support for compilation into various flavors of ActionScript (not surprising in light of support of SWF9).

2 comments:

Henry said...

Did you try "lz.textformat"?

When you define a class with the <class name="foo"> LZX class element, the class name gets bound in the "lz" object as "lz.foo" now.

Dustin said...

Henry, your suggestion does address the issue. I had read this in the 4.1 Release Notes ("Upgrading to OpenLaszlo 4.1") several days ago, but it did not "click" in my mind that this was the particular issue in this case. I will be updating the blog entry your comment is in response to so that it accurately reflects this.

Thanks for the feedback.

Dustin