Hi Garrel,
Thanks for the comments! I appreciate the your taking the time to
thoroughly investigate the extension. Indeed, as the documentation states,
your last comment is right on target: the extension is not ready to be used
for production work, but is intended to expose the current and potential
state of interaction and serve as a basis for more exploration.
While some of the issues mentioned in your email and in the documentation
can be addressed in the current code, many are a result of inconsistencies
in the API or design choices. I'll sort those out below if you're
interested. But the bottom line is to gauge developer interest in the
topic. Let's say the extension performed flawlessly. Would that level of
functionality be valuable to you? If so, it would be in Macromedia's
interest to support JSP > 1.0. It would be helpful for them to know that
developers who use their products desire it. I would encourage everyone
else to try out the extension to see how tool support changes the authoring
experience, and judge how valuable it is.
Along these lines I should point out that a couple of the stronger issues
you raised are due to ambiguity in the docs, or user error (explained
below). As far as I can tell, the extension functions as it claims.
Here's a breakdown of the issues you mentioned, not to pump the extension's
production value, but to stress that it works as it should to encourage
other developers to try it, evaluate it, and provide feedback on the
utility of tool support. I'll preface my descriptions with either *BUG*
(fixable in codebase), *CHOICE* (a design choice that can be revisited),
*API* (a problem due to the UltraDev API), or *NOT A BUG*, something that
seems due to user error or ambiguity in the docs.
>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.
*API*
UltraDev does not allow an extension to insert content before the <HTML>
tags. Even inserting content outside the <BODY> tags is tricky, the only
known way to do it is described in the documentation.
>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>
*NOT A BUG*
What probably happened here is that you selected
<request:existsparameter name="Submit"></request:existsparameter> in the
HTML source window. The way to select an unlocked tag (like request) is to
place the cursor in the design window and select <request> from the tag
ancestor list in the lower left corner of the document window. The
extension will then insert properly around the selection, or inside the
selection if you insert a tag without body content. This technique is
described under "Selection" in the documentation.
>* 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>
*NOT A BUG*
I'm pretty sure what happened here is that you did not hit the "Use Tag
Library" button after selecting the "page" tag library from the "Select a
Custom Tag Library" drop-down menu. The "Select Tag to Insert" drop-down
menu was still populated with the "request" tags, but since both tag
libraries have a "setattribute" tag, you were able to insert
<page:setattribute> thinking it was <request:setattribute>.
>* 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.
*CHOICE*
The remove tag feature is intended to be literal, in that it removes the
tag but not the bodycontent. In this way it mimics the UltraDev Remove Tag
behavior. Since the body content could be nested custom tags or other
desirable content, the default behavior cannot be to remove the body
content.
It would be easy to ask the user at deletion time if they wanted to delete
body content, though it would require an extra step for the user each
time...
>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.
*BUG*
Yes harmless, but unsightly :)
>* 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.
*API*/*BUG*
The floaters won't update if you select outside the <BODY> tag or don't
follow the methods for certain cases described in the doc. I have seen
other cases when the API does not fire the "selection changed" event which
updates the floater.
>* 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.
>
Good point!
___________________________
My current thinking is that its not feasible to create a "production ready"
taglib extension as long as UltraDev only supports JSP 1.0. For example,
UltraDev does not know when custom tags begin and end, since it does not
recognize them. The extension figures it out by doing some expensive
analysis on the DOM, but much of its functionality relies on API calls
within UltraDev that operate without knowledge of custom tags on the page.
There are other restrictions, such as the inability to insert content
outside the <HTML> tags that you noticed, that are particularly hindering
to custom tag development.
I'm going to be in contact with Macromedia to let pass on feedback from you
and all the developers that try the extension. The more feedback we get,
the better.
Thanks again!
Dan
