Thanks for the message. It is wonderful to know that we are not the only ones that got
stuck. In my opinion, JSP 1.2 XML has two bugs. This and the fact that we can't
specify that the output is really HTML in XHTML form. In other words, we need
something like the output method in XSLT and James Clark's implementation of that
element in his XT XSLT processor: that you can plug in an output module to handle the
actual tag outputs. For instance, if you specify that the output is really HTML, the
HTML output module will take over and makes sure the tags it outputs are proper HTML
tags. We used that approach with XT to output some bizzarre HTML-like markup languages
like HDML, WML variants that insist of having the literal & character (literal &
characters, can you imagine that?) in their attributes (it caused so much pain...). As
long as it sends the JSP tags to the JSP output writer, the JSP semantics will still
be maintained.
I might just have to implement something like that. Obviously, that will not violate
the JSP 1.2 spec. A post-processor, if you like. I will simply use the mime type that
you can specify in JSP pages to indicate the output engine to use...
Let me think about the solution you have. I am not sure how we can incorporate it into
our system. In our system, we start from XML files that specify HTML Form elements on
pages, without presentation. We then use XSLT to convert that into JSP pages that
combine look-and-feel elements from other files. In this way, we can generate a Web
site with a particular look-and-feel in about 2 minutes, and still basically serve JSP
pages. Half a year ago, we used JSP 1.1 with CDATA sections and <xsl:text
disable-output-escaping='yes'> all over the place in our XSLT scripts. It was painful,
not to mention very error-prone, as we cannot expect XML to match tags and attribute
quotes for us any more. So I was ecstatic when JSP 1.2 XML came out. Now, if I had to
follow the spec, I had two choices: tons of CDATA sections and xsl:text and generally
ugliness in my XSLT scripts, or tons of CDATA sections and generally ugliness in the
JSP pages we generate. What a choice! :)
About the need for namespace prefix. I can use xmlns='...' to declare the default
namespace to be my namespace name. That will get rid of the prefix.
Don't apologise for long messages. They are good for clearing up complex situations.
Khun Yee
>>> [EMAIL PROTECTED] 03/12/02 03:46AM >>>
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 [EMAIL PROTECTED], 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
