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 Boyd Waters <bw...@cv3.cv.nrao.edu> on 2000/12/23 04:22:35 UTC
Using PageContext to pass Object params
Mike Cannon-Brookes wrote:
> the current include methods do not allow you to pass parameters
> which are not strings.
CORRECT! But I don't see how your idea of JSPT gets away from passing
the things around as strings. Could you help me understand that?
I think you can pass Objects as "parameters" to tags by stuffing the
Object into a named slot in the pageContext, and then telling the tag
where to get it. In your page you say
<% pageContext.setAttribute
( "New Zealand English",
new java.util.Locale( "en", "NZ" );
%>
.
. (more HTML page here, perhaps...)
.
<dt:timestamp locale="New Zealand English" usePageContext="locale" />
Instead of passing a characterization of an object (which must be parsed
and then used to call a constructor or whatever), I think I like the
idea of passing a String that tells the tag how to look the Object up.
If you're worried about namespace collision, you could adorn your
pageContext attribute names with the name of the tag or some other
convention:
<% pageContext.setAttribute
( "datetime.calendar:locale",
new java.util.Locale( "es", "ES" );
%>
...and then by default my calendar tag finds any attributes by searching
the pageContext attribute space for any that happen to be defined. But I
don't think namespace pollution is much of an issue here.
So to summarize:
--
1) Reasonable default behavior (no params set):
<dt:timestamp />
--
2) Use a String parameter to figure out how to do something:
<dt:timestamp locale="fr CA" />
The String param is passed to the tag and it has to parse it to figure
out how to do the right thing. In this example, the locale param String
is tokenized into two Strings which are in turn passed to the
constructor new java.util.Locale("fr", "CA") to get the French-Canadian
locale.
--
3) Use the pageContext to set "global" attribs, which may be Object
values.
<dt:timestamp
value="Last Edited Date"
locale="French-Canadian"
format="MMMM dd, yyyy
usePageContext="value,locale" />
The tag in this example sees the "usePageContext" attrib, and therefore
knows to try to look up the "value" and "locale" values:
dateValue = (Date) pageContext.findAttrib( "Last Edited Date" );
lc = (Locale) pageContext.findAttrib( "French-Canadian" );
Note that the tag in this example sets its "format" attrib based on the
String that's passed as the parameter. So you can mix and match.
--
4) Use some sort of namespace convention to magically glean attribute
values from the pageContext.
<% pageContext.setAttribute
( "datetime.timestamp:format",
"dd/MM/yyyy HH:mm" );
%>
<dt:timestamp
locale="French-Canadian" usePageContext="locale" />
In this example, the value of the timestamp will be the default, since
it is not set anywhere else. The other values are set like this:
lc = (Locale) pageContext.findAttrib( "French-Canadian" );
format = (String) pageContext.findAttrib( "datetime.timestamp:format"
);
Note that the locale is looked up exactly as in the previous example.
I don't like this last idea very much. I think that example 3) is
sufficient.
-- boyd
==============
PS:
I worked through Mike's example of an HTML box and couldn't find a place
where strings were not sufficient, where you had to pass a Java Object.
Given that HTML is strings, you characterize the colors as strings
anyhow...
Um, in the worst case, I'd draw a box using a CSS-styled DIV tag for
recent browsers, and a table for everyone else:
<% if( useragent.version > 4.0 ) { %>
<div style="color: #ffffff; background: #333333; border: 2px solid
black;">
<% } else { %>
<table border="2" background="#333333"><tr><td>
<% } %>
my content
<% if( useragent.version > 4.0 ) { %>
</div>
<% } else { %>
</tr></td></table>
<% } %>
(I'm hand-waving about the details of determining which content form.
That would be part of the implementation, maybe a hash table of
useragents and their capabilities. An old idea, not what I want to focus
on at the moment...)
Say that you want to use this idiom over and over again. So you want a
"box" tag that's part of an HTML taglib:
<html:box foreground="#ffffff" background="#333333" border="2">
my content
</html:box>
One could suppose, you'd pass a CSS-style structure (object?) that would
be used to produce the proper HTML. Hmm... that would be interesting,
because the semantics of Style would be passed along in the Style
Object, and could be used to emit HTML of various sorts...
--
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
RE: Using PageContext to pass Object params
Posted by Scott Stirling <ss...@mediaone.net>.
Joseph,
This is the second time in a couple recent emails you've referred to problem
domains. The first time was in your comments on the non-competition between
JSP and some other technologies for generating dynamic Web content:
Thurs. 12/21/00:
"I don't see a real competition
between WebMacro, Cocoon, et al. I think JSP has its own domain, and
because it lives in its own 'We're not page hackers' domain,"
You seem to have working ideas of the problem domains of JSP and some other
technologies. It would be interesting to hear them. For instance, why do
you believe JSP is not in the domain of page hackers? My belief is that
JSP, Webmacro, Cocoon, CFML, and some others are concerned with the problem
domain I would call "dynamic Web content generation." I think JSP is and
should continue to be more than just the preferred Web-view component of
J2EE apps. That is, it has a life of its own, particularly for those many
Web sites that don't need the full power of J2EE (EJB, transactions, and all
that).
I'm willing to argue that any boundaries demarking the problem domain of JSP
as isolated from some of the other technologies we've mentioned are illusory
or imagined. For businesses looking for dynamic Web content, these are all
competing technologies, I think.
Lastly, I was thinking Mike's JSPT idea had broader applications, although
he may not have expressed it as such.
Scott Stirling
> -----Original Message-----
> From: Joseph B. Ottinger [mailto:joeo@epesh.com]
>
> I like the idea of JSPT, but honestly, I think the problem domain it's
> trying to fix is too small to be generally useful. Most of the tags I'd
> liek to see don't generate much HTML, and the HTML they generate is pretty
> simple.
Re: Using PageContext to pass Object params
Posted by "Joseph B. Ottinger" <jo...@epesh.com>.
I like the idea of JSPT, but honestly, I think the problem domain it's
trying to fix is too small to be generally useful. Most of the tags I'd
liek to see don't generate much HTML, and the HTML they generate is pretty
simple.
On Fri, 22 Dec 2000, Boyd Waters wrote:
> Mike Cannon-Brookes wrote:
>
> > There's no reason you only pass strings. For instance (sticking with the
> > html:box idea), I might have a Story object which I want to box, and display
> > the headline, teaser etc in a particular way in HTML.
> >
> > <html:box story="<%= mystory %>" />
> >
> > The JSPT page could then use methods like <%= mystory.getTitle() %> to
> > display parts of the object.
>
> I've been doing things like this with XML and XSLT.
>
> The XSLT taglib is my favorite tag; I use it to create JSP pages (HTML
> templates) that are filled in by XML. The other engines don't let me do
> this; with Taglibs and JSP, I can create the bulk of HTML very easily --
> the JSP document -- and relegate the dynamic content bits to my
> XML/XSLT.
>
> > I don't think the debate is whether you can always solve your problems by
> > passing strings (in my opinion you can't). I've been building servlet / jsp
> > based web apps for 2 years now, and this is one of the areas that's just
> > instinctive. You always want to pass around your beans / ejbs / some object!
>
> One could ask a bean for its XML serialization, and then apply a
> stylesheet to it to get the HTML. But I don't do that. I have the
> database (or whatever) create XML documents for me, and then use the
> XML.
>
> Granted, its insane to instatitate an object in Java, dump it as XML,
> fire up another Java process, have it read the XML, and give you an
> object back. You should be able to do the whole thing in-process without
> the XML serialization step.
>
> > Reiterating my main point: the current tag spec makes it very hard to write
> > tags that produce HTML, and quickly alter that HTML.
>
> Which is why my tags tend to emit teeny, simple XHTML and punt on
> everything that looks like formatting -- either to CSS or XSLT. You're
> right: I try to minimize my exposure to HTML from my tags.
>
>
>
> Great discussion(s)!
>
> I'm quite interested in continuing it, to hearing what Mike and others
> have to say, but I have to leave it here until after Christmas...
>
> Have a merry holiday all!
>
> -- boyd
>
> ---------
> Boyd Waters bwaters@nrao.edu
> National Radio Astronomy Observatory http://www.nrao.edu
> PO Box 0 Socorro, NM 87801 505.835.7346
>
> http://www.zocalo.net/~waters
> waters@zocalo.net
> ---------
>
-----------------------------------------------------------
Joseph B. Ottinger joeo@epesh.com
http://epesh.com/ IT Consultant
Re: Using PageContext to pass Object params
Posted by Boyd Waters <bw...@cv3.cv.nrao.edu>.
Mike Cannon-Brookes wrote:
> There's no reason you only pass strings. For instance (sticking with the
> html:box idea), I might have a Story object which I want to box, and display
> the headline, teaser etc in a particular way in HTML.
>
> <html:box story="<%= mystory %>" />
>
> The JSPT page could then use methods like <%= mystory.getTitle() %> to
> display parts of the object.
I've been doing things like this with XML and XSLT.
The XSLT taglib is my favorite tag; I use it to create JSP pages (HTML
templates) that are filled in by XML. The other engines don't let me do
this; with Taglibs and JSP, I can create the bulk of HTML very easily --
the JSP document -- and relegate the dynamic content bits to my
XML/XSLT.
> I don't think the debate is whether you can always solve your problems by
> passing strings (in my opinion you can't). I've been building servlet / jsp
> based web apps for 2 years now, and this is one of the areas that's just
> instinctive. You always want to pass around your beans / ejbs / some object!
One could ask a bean for its XML serialization, and then apply a
stylesheet to it to get the HTML. But I don't do that. I have the
database (or whatever) create XML documents for me, and then use the
XML.
Granted, its insane to instatitate an object in Java, dump it as XML,
fire up another Java process, have it read the XML, and give you an
object back. You should be able to do the whole thing in-process without
the XML serialization step.
> Reiterating my main point: the current tag spec makes it very hard to write
> tags that produce HTML, and quickly alter that HTML.
Which is why my tags tend to emit teeny, simple XHTML and punt on
everything that looks like formatting -- either to CSS or XSLT. You're
right: I try to minimize my exposure to HTML from my tags.
Great discussion(s)!
I'm quite interested in continuing it, to hearing what Mike and others
have to say, but I have to leave it here until after Christmas...
Have a merry holiday all!
-- boyd
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
RE: Using PageContext to pass Object params
Posted by Mike Cannon-Brookes <mc...@internet.com>.
See comments below.
> From: bwaters@aoc.nrao.edu [mailto:bwaters@aoc.nrao.edu]On Behalf Of
>
> Mike Cannon-Brookes wrote:
>
> > the current include methods do not allow you to pass parameters
> > which are not strings.
>
> CORRECT! But I don't see how your idea of JSPT gets away from passing
> the things around as strings. Could you help me understand that?
There's no reason you only pass strings. For instance (sticking with the
html:box idea), I might have a Story object which I want to box, and display
the headline, teaser etc in a particular way in HTML.
<html:box story="<%= mystory %>" />
This cannot be done with the current include architecture (<%@include or
<jsp:include).
The JSPT page could then use methods like <%= mystory.getTitle() %> to
display parts of the object.
> I think you can pass Objects as "parameters" to tags by stuffing the
> Object into a named slot in the pageContext, and then telling the tag
> where to get it. In your page you say
>
> <% pageContext.setAttribute
> ( "New Zealand English",
> new java.util.Locale( "en", "NZ" );
> %>
> .
> . (more HTML page here, perhaps...)
> .
> <dt:timestamp locale="New Zealand English" usePageContext="locale" />
Could be done, but IMHO this is a VERY ugly solution ;)
>
> PS:
> I worked through Mike's example of an HTML box and couldn't find a place
> where strings were not sufficient, where you had to pass a Java Object.
> Given that HTML is strings, you characterize the colors as strings
> anyhow...
I think you missed my main point. That is the current tag spec makes it very
hard and painful to code HTML into tags (just like servlets were 12 months
ago). Not all tags produce HTML I agree, the current arch works well for
function tags (tags which _do_ something) but it's poor for presentation
tags (tags which _show_ something, presumably using HTML).
<< snipped example >>
> One could suppose, you'd pass a CSS-style structure (object?) that would
> be used to produce the proper HTML. Hmm... that would be interesting,
> because the semantics of Style would be passed along in the Style
> Object, and could be used to emit HTML of various sorts...
Exactly, JSPT would give you much greater _flexibility_ ;). Imagine you had
a particular box object that you used in your swing app (colours, borders
etc), you could create one of those and pass it, with your JSPT reading it
and using it to create the box. Now we're no longer passing strings.
I don't think the debate is whether you can always solve your problems by
passing strings (in my opinion you can't). I've been building servlet / jsp
based web apps for 2 years now, and this is one of the areas that's just
instinctive. You always want to pass around your beans / ejbs / some object!
;)
Reiterating my main point: the current tag spec makes it very hard to write
tags that produce HTML, and quickly alter that HTML.
Thus my solution.
Mike