Re: DO NOT REPLY [Bug 5785] - XML request time attribute not generated correctly

[Khun Yee Fung <ky...@csi.ca>]

*moan* Now I have to convert HTML tags we have that use request-time attributes into custom tags so that we can give them request time attributes. *sigh* Is it going to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the equivalent of request-time attributes. I guess I thought JSP would be the same. It just makes sense, doesn't it? :)

Well, maybe I can kill two birds with one stone: sooner or later I need to get real HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the HTML custom tags to output proper HTML syntax tags. The performance is going to be bad though...

Thanks.

Khun Yee

>>> bugzilla@apache.org 03/11/02 01:42PM >>>
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785 

XML request time attribute not generated correctly

kin-man.chung@sun.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From kin-man.chung@sun.com  2002-03-11 18:42 -------
The runtime expression (of the form "%=...%") in only evaluated when it appears
in the attributes of a<jsp:expression>, some standard action, or a custom tag
action element, and is not in an unterpreted tag.  Check the spec.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: DO NOT REPLY [Bug 5785] - XML request time attribute notgenerated correctly

[Andreas Junghans <An...@fh-karlsruhe.de>]

Hi,

> *moan* Now I have to convert HTML tags we have that use request-time
attributes
> into custom tags so that we can give them request time attributes. *sigh*
Is it going
> to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the
equivalent
> of request-time attributes. I guess I thought JSP would be the same. It
just makes
> sense, doesn't it? :)

We ran into exactly the same problem. IMO it's a really ugly spec bug :-(  I
already sent a comment about that to jsp-spec-comments@eng.sun.com, but got
no response. We (kind of) solved the problem by wrapping our pages in custom
tags that buffer their body content and parse it by hand. Of course, this
doesn't work for arbitrary expressions without putting a lot of effort into
it. In our case, we just look up pageContext attributes so that

<img src="%= someSrc %"/>

is translated into

<img src="someImg"/>

with "someImg" being the value of pageContext.getAttribute("someSrc").

Since this is not satisfactory, we're currently working at a solution that
takes an XML document that looks like a JSP and translates it into a
non-XML-JSP (via XSLT). During translation, all %= = attribute values are
replaced by the appropriate code. This way, you're still working with
something that looks like an XML-JSP but with RT attribute expressions in
_all_ tags. If you're interested, I can send you more information. Note:
This work is done within a diploma thesis, so it's absolutely free to use,
copy, change, ...

> Well, maybe I can kill two birds with one stone: sooner or later I need to
get real
> HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the
HTML
> custom tags to output proper HTML syntax tags. The performance is going to
be
> bad though...

I really wouldn't do that, it's too work for what you get at the end. BTW, I
don't think you can sell <img../> (or other html tags) to Jasper as custom
tags without a namespace prefix: <xyz:img.../>. And this looks _really_
ugly!

Best regards

  Andreas Junghans

PS Sorry for being so lengthy, it's a bad habit of mine ...



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>