You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by "Renick, Garrel" <ga...@more.net> on 2001/05/15 22:12:15 UTC
CTLX Ultradev Extension Comments
I saw several messages about the Ultradev CTLX custom taglib extension last
week. In one of my responses I promised I would provide some feedback, so
here's a summary of my impressions of the extension.
* Dan Mandell has provided a detailed document about installation and use of
the extension. The installation is a breeze.
* The extension includes a detailed tutorial that takes up about half of the
11 pages of documentation. I believe the tutorial is unnecessarily detailed
for those that are not familiar with Struts. A more generic example with
some of the other taglibs may be more useful. For example, build a form that
submits some text to the JSP, and then use the request taglib to get the
request parameters and the session taglib to set some session attributes and
display them.
* The documentation includes about two pages of "Things to Watch" that
details how the extension works within Ultradev in regard to tag selection,
insertion, and removal. Although the documentation tries to explain the
behavior of Ultradev, the explanations don't remedy the unpredictable
insertion of custom tags. I'm guessing that most of the behavior is due to
Ultradev's JSP translator; as Dan mentions in the docs, the current version
of Ultradev supports JSP 1.0 .
For example, open a new page and then use the extension's palette to
instruct it to use a custom taglib. It responds by placing the taglib
directive at the top of the page. Open a few new lines immediately after the
taglib directive to add some logic above any HTML that becomes part of the
response to the client. For example, try to add this logic to the top of the
page using the extension palettes:
<request:existsparameter name="Submit">
<page:setattribute name="Submitexists">True</page:setattribute>
</request:existsaparameter>
Despite having the cursor placed above the <HTML> tag, Ultradev sticks the
first custom tag in the body like the following:
<%@ taglib uri="/WEB-INF/request.tld" prefix="request" %>
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<page:setattribute name="Submitexists"></page:setattribute>
</body>
</html>
I could not get the tool to add custom tags outside of the <HTML> tags,
regardless of where I placed the cursor in the design window. For complex
pages that need a lot of logic at the top of the page before any HTML is
generated, this approach is possibly dangerous if the cache dumps before the
logic completes.
* Working under its assumptions for where the tags should be inserted,
continue to use the tool. Select the
<page:setattribute...></page:setattribute> code and then insert the
<request:existsparameter...> tag. If you remembered to add some tag body
content to the <page:setattribute...> tag within the design window, the
<request:existsparameter...> tag appropriately wraps around the entire
selection. However, if you forgot to add the tag body content, the following
invalid code is added to the page:
<request:existsparameter name="Submit"><page:setattribute
name="Submitexists"></request:existsparameter></page:setattribute>
* Sometimes the extension seems to become confused about what taglib you're
working with. For example, I tried to add the code above in a reverse
manner; first adding the <request:existsparameter...> tag followed by the
<page:setattribute...> tag. When I attempted to add the
<page:setattribute...> tag, it produced the following code even though the
"page" custom taglib was selected in the "Use Custom Tag Library" for--for
some reason it maintained the "request" prefix.
<request:existsparameter name="Submit"><request:setattribute
name="Submitexists"></request:setattribute></request:existsparameter>
* When you attempt to remove tags, tag body content remains on the page.
This is a sticky situation--sometimes you need to keep the body content and
other times you need it deleted. If you don't carefully watch how it removes
tags, erroneous tag body content remains in your pages.
Also note that I received the following error message while trying to remove
a tag that contained body content:
"While executing onClick in tagEdit.html, the following JavaScript error(s)
occurred: nodeToOffsets: Argument number 1 is invalid." Perhaps this is the
harmless JavaScript error that Dan mentions in the final bullet item of the
"Selection" documentation.
* The Edit Tag palette sometimes doesn't repopulate or empty its contents.
Dan mentions this behavior in the "Selection" section of the documentation,
but it is confusing when you see it retain an old value.
* The tool requires that you add tag body content within the design window,
versus a pop-up like the one that displays for attribute names when you
insert a tag. This is a good thing for tag bodies where you perform
complicated logic. However, some times you just need to insert something
simple like a value in the tag body and a pop-up could be helpful here.
* The nesting of beginning and ending custom tags on a single line is hard
to read and makes it difficult to keep track of tag logic. I would prefer an
indented, structured approach for nesting tags. However, how would the tool
deal with tag body content that shouldn't have spaces in it? Hmm. This seems
to be a catch-22 for the tool/extension developer.
* The extension requires an explicit taglib directive in the page. I've
found that sometimes it's easier to maintain prefix and URI consistency by
putting the directives in a file that is compile-time included in each of my
JSPs in an application. Maybe this is a bad practice, but I've found it
helpful.
* The docs may need to mention that Tomcat with an enabled Java
SecurityManager requires a grant to read property permissions for the
TLDParser web app. If it isn't enabled, you get a large stack trace in the
Ultradev palette that displays the list of available taglibs. It is almost
impossible to read the stack trace on monitors with lower resolutions since
the first line of the trace if very long.
* It would be really nice if the extension provided some mechanism for
command line completion of custom tags. I guess that doesn't help the
point-and-click users, but I think it is a cool feature (that's done well in
Netbeans, BTW).
In conclusion, I think this extension is an interesting exploration into
custom taglib support in Ultradev. It needs more work and Macromedia needs
to work on the JSP parser in the product. I can't use this tool for
production work because of the unpredictable nature of inserting and
removing tags and the hard-to-read code--it's hard to concentrate on logic
when you're concerned about how the tool is affecting the existing code.
Perhaps releasing this tool will inspire others to join Dan in the effort to
make it more useful, and possibly inspire vendors to think about how they
add custom taglib support to their products. Thanks for creating and sharing
this extension, Dan.
Garrel Renick
garrel@more.net