Grouped Output
I need to generate a report that looks something like this: NameDates Visited --- - Anderau, Eoma 2002-03-07 Andersson, Lisa 2002-02-04 2002-02-25 2002-02-26 2002-03-08 2002-03-13 2002-03-14 2002-01-31 2002-03-15 Aylott, Bridget 2002-01-31 2002-02-18 Is it possible to generate a grouped report using taglibs without resorting to using scriptlet logic to determine when the column Name has changed in the record set? TIA.
RE: JSTL tag prefix naming conventions?
Aren't prefixes defined by the developer of the application using the the JSTL tags? The prefixes in the documentation are merely suggestions, you don't HAVE to follow that. How were the names for the JSTL tag library prefixes chosen? I think that the naming could be more consistent and/or meaningful. For example, instead of the current ones, how about these alternatives: c -- core x -- xml fmt -- format sql -- sql But, even this isn't clear that the libraries are related. So, perhaps instead they should be: jstlc or jstlcore jstlx or jstlxml jstlf or jstlformat jstls or jstlsql Given that c or x by themselves are not very unique and fail to convey anything about what they do (except to those who already know), it seems that these prefixes should be more meaningful. If there's an sql prefix, then why isn't there an xml prefix (instead of x? It seems odd that there is no consistency in naming. If they were x,c,f, and s, they would at least be consistent. And, xml,core,format, and sql would be more consistent and clearer as to their purpose. But, these alternatives don't show that they're related in any way. So, would jstlcore,jstlxml,jstlformat, and jstsql be the best? If this is going to be a widely adopted tag library, I think we need better prefix names. And, if the possibility exists that additional tag libraries are added, then perhaps a more consistent naming convention should be picked now. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Grouped Output
If you use c:set var= to set a variable to the name and then have it
check against it before printing out the name should work. ie,
c:set var=thenamefirst time it's zero length/c:set
c:if test=${oldname != newname}
c:set var=thenamethe name value/c:set
c:out value=${thename}/
/c:if
peter
Zvolensky, Thomas J {PDBI~Nutley} wrote:
I need to generate a report that looks something like this:
NameDates Visited
--- -
Anderau, Eoma 2002-03-07
Andersson, Lisa 2002-02-04
2002-02-25
2002-02-26
2002-03-08
2002-03-13
2002-03-14
2002-01-31
2002-03-15
Aylott, Bridget 2002-01-31
2002-02-18
Is it possible to generate a grouped report using taglibs without
resorting to using scriptlet logic to determine when the column Name has
changed in the record set?
TIA.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL tag prefix naming conventions?
If I redefined the prefixes, then when my customers or I buy Shawn's book (or any others), they'd have to reinterprete every description and example to map the new prefix names to the default ones. And, likewise, it would complicate any newgroup or mailing list discussions. So, a solution to this issue is pretty much now or never. Instead, the current prefixes come across to me as having been thrown together, and not well thought out. Steve -Original Message- From: Agrawal, Anuj (Anuj)** CTR ** [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 11:53 AM To: 'Tag Libraries Users List' Subject: RE: JSTL tag prefix naming conventions? Aren't prefixes defined by the developer of the application using the the JSTL tags? The prefixes in the documentation are merely suggestions, you don't HAVE to follow that. How were the names for the JSTL tag library prefixes chosen? I think that the naming could be more consistent and/or meaningful. For example, instead of the current ones, how about these alternatives: c -- core x -- xml fmt -- format sql -- sql But, even this isn't clear that the libraries are related. So, perhaps instead they should be: jstlc or jstlcore jstlx or jstlxml jstlf or jstlformat jstls or jstlsql Given that c or x by themselves are not very unique and fail to convey anything about what they do (except to those who already know), it seems that these prefixes should be more meaningful. If there's an sql prefix, then why isn't there an xml prefix (instead of x? It seems odd that there is no consistency in naming. If they were x,c,f, and s, they would at least be consistent. And, xml,core,format, and sql would be more consistent and clearer as to their purpose. But, these alternatives don't show that they're related in any way. So, would jstlcore,jstlxml,jstlformat, and jstsql be the best? If this is going to be a widely adopted tag library, I think we need better prefix names. And, if the possibility exists that additional tag libraries are added, then perhaps a more consistent naming convention should be picked now. -- 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]
RE: JSTL tag prefix naming conventions?
However, they will become a de-facto standard. So it's the usual abbreviation cuz it's easy to type versus full word because it's meaningful argument. Java philosophy supports the latter, so I will too. How about is JSTL peeps? Can we have more meaningful default namespaces? On Thu, 21 Mar 2002, Agrawal, Anuj (Anuj)** CTR ** wrote: Aren't prefixes defined by the developer of the application using the the JSTL tags? The prefixes in the documentation are merely suggestions, you don't HAVE to follow that. How were the names for the JSTL tag library prefixes chosen? I think that the naming could be more consistent and/or meaningful. For example, instead of the current ones, how about these alternatives: c -- core x -- xml fmt -- format sql -- sql But, even this isn't clear that the libraries are related. So, perhaps instead they should be: jstlc or jstlcore jstlx or jstlxml jstlf or jstlformat jstls or jstlsql Given that c or x by themselves are not very unique and fail to convey anything about what they do (except to those who already know), it seems that these prefixes should be more meaningful. If there's an sql prefix, then why isn't there an xml prefix (instead of x? It seems odd that there is no consistency in naming. If they were x,c,f, and s, they would at least be consistent. And, xml,core,format, and sql would be more consistent and clearer as to their purpose. But, these alternatives don't show that they're related in any way. So, would jstlcore,jstlxml,jstlformat, and jstsql be the best? If this is going to be a widely adopted tag library, I think we need better prefix names. And, if the possibility exists that additional tag libraries are added, then perhaps a more consistent naming convention should be picked now. -- 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]
RE: JSTL tag prefix naming conventions?
While Java also supports meaningful naming, in this case the goal is to create tag libraries for non-programmers. So, names like x and fmt are not terribly clear. The HTML tags are not cryptic, and whenever possible, neither should JSP tags. I undestand that the HTML tags don't need a prefix, but we should keep in mind the intended audience and minimize confusion. If the standard JSP tags were j:useBean, j:setProperty, etc., it would be confusing -- would the j represent Java or JSP? And, if HTML tags had to have a prefix, would you find h a good prefix? I doubt it -- I'd much prefer html as a prefix. To avoid collisions and other confusion, I'm leaning toward having jstl at the beginning of the prefixes. Shawn, hasn't this issue been discussed among the expert group? Or, was this something no one ever thought about discussing? Steve -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 12:01 PM To: Tag Libraries Users List Subject: RE: JSTL tag prefix naming conventions? However, they will become a de-facto standard. So it's the usual abbreviation cuz it's easy to type versus full word because it's meaningful argument. Java philosophy supports the latter, so I will too. How about is JSTL peeps? Can we have more meaningful default namespaces? On Thu, 21 Mar 2002, Agrawal, Anuj (Anuj)** CTR ** wrote: Aren't prefixes defined by the developer of the application using the the JSTL tags? The prefixes in the documentation are merely suggestions, you don't HAVE to follow that. How were the names for the JSTL tag library prefixes chosen? I think that the naming could be more consistent and/or meaningful. For example, instead of the current ones, how about these alternatives: c -- core x -- xml fmt -- format sql -- sql But, even this isn't clear that the libraries are related. So, perhaps instead they should be: jstlc or jstlcore jstlx or jstlxml jstlf or jstlformat jstls or jstlsql Given that c or x by themselves are not very unique and fail to convey anything about what they do (except to those who already know), it seems that these prefixes should be more meaningful. If there's an sql prefix, then why isn't there an xml prefix (instead of x? It seems odd that there is no consistency in naming. If they were x,c,f, and s, they would at least be consistent. And, xml,core,format, and sql would be more consistent and clearer as to their purpose. But, these alternatives don't show that they're related in any way. So, would jstlcore,jstlxml,jstlformat, and jstsql be the best? If this is going to be a widely adopted tag library, I think we need better prefix names. And, if the possibility exists that additional tag libraries are added, then perhaps a more consistent naming convention should be picked now. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Multi-threaded io:soap requests?
Hi, In a JSP, I have the need to do multiple SOAP requests. !-- soap request 1 -- io:soap io:body ... /io:body /io:soap !-- soap request 2 -- !-- soap request 3-- What I'd like to do is to have these requests run at the same time (like in a thread).. Is there any way (using the existing tag library) that I can do this? Thanks, Kevin T. Smith [EMAIL PROTECTED]
Re: Grouped Output
On Thu, 21 Mar 2002, Zvolensky, Thomas J {PDBI~Nutley} wrote:
Is it possible to generate a grouped report using taglibs without
resorting to using scriptlet logic to determine when the column Name
has changed in the record set?
Why not do it in the SQL itself using a group by clause? I used to
resist database logic too and attempted to do everything in my own
programs, but it's often easier to get the database to manage your data
for you.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL tag prefix naming conventions?
So, sorry I didn't respond earlier; for some reason, the mailing list didn't send me these messages until hours later. Thanks for all your comments; I can't speak authoritatively for the entire expert group, but here are my own personal opinions. On Thu, 21 Mar 2002, Steve Bang wrote: While Java also supports meaningful naming, in this case the goal is to create tag libraries for non-programmers. So, names like x and fmt are not terribly clear. The HTML tags are not cryptic, and whenever possible, neither should JSP tags. Overall, I'd certainly never argue for tags that are cryptic, but HTML tags certainly use abbreviations, just for the sake of brevity. There's an a tag instead of anchor; p instead of paragraph; and img instead of image. In fact, nearly all HTML tags are cryptic if you don't like abbreviations. :-) Concerning analogies with Java, I'm not sure I agree. The J2SE libraries certainly use reasonably long names for classes, but namespace prefixes are more like packages, and the standard libraries all use abbreviations: java.io, java.util, java.lang. Like the J2SE libraries, we don't abbreviate the tag (class) names: forEach, forTokens (instead of 'f' or 'ft'). At any rate, it looks (to me) like we're in good company. I undestand that the HTML tags don't need a prefix, but we should keep in mind the intended audience and minimize confusion. If the standard JSP tags were j:useBean, j:setProperty, etc., it would be confusing -- would the j represent Java or JSP? And, if HTML tags had to have a prefix, would you find h a good prefix? I doubt it -- I'd much prefer html as a prefix. To avoid collisions and other confusion, I'm leaning toward having jstl at the beginning of the prefixes. Shawn, hasn't this issue been discussed among the expert group? Or, was this something no one ever thought about discussing? This definitely came up; it was debated at length in the context of whether to provide a single JSTL tag library or multiple tag libraries. The rationale for the perceived inconsistency in the naming is what Henri said: simplicity to type. After all, 'core' or 'jstlcore' are just as opaque as 'c' without ANY context; given that JSTL is the standard and is expected to be used widely, we figured that c:forEach would be much easier to read and identify than jstlcore:forEach FMT could be called 'f', but it does take a slight back-seat to the core library in this regard. I'd expect many pages just to use 'c'. The XML tag library might have ideally been prefixed 'xml', but the XML standard itself rules that out :-), and we figured we'd promote the library by giving it its own, one-letter abbreviation. Whatever we choose would be somewhat arbitrary, so we ultimately opted to ease the page author's burden of typing! -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL tag prefix naming conventions?
On Thu, 21 Mar 2002, Shawn Bayern wrote: So, sorry I didn't respond earlier; for some reason, the mailing list didn't send me these messages until hours later. Thanks for all your comments; I can't speak authoritatively for the entire expert group, but here are my own personal opinions. removed to increase anticipation One thing that reading your email does make me realise. c:blah is a much better sell to html designers. Much as I'd love html to have para and anchor it seems that the majority of web designers prefer the shorthand. Lazy buggers :) Anyway, if the aim of custom taglibs is to get us, the coders, into spiffy jobs making custom taglibs, and them, the great unwashed designers, into doing a developers job by using spiffy taglibs, then adhering to their particular 'standards' does seem a good plan. [vaguely tongue in cheek, but the point is serious]. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL tag prefix naming conventions?
OK, I guess I slipped on the intuitiveness of HTML tags -- I don't know where my mind was at that moment. Regardless, I prefer consistency and clarity whenever possible. I know you do too. Your clarified the issues and I am somewhat comfortable with the outcome. And, now I understand why sql was used, but not xml. I still think that it would be nice if all of the libraries started with jstl so that they appeared related. Oh, well. Steve -Original Message- From: Shawn Bayern [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 4:10 PM To: Tag Libraries Users List Subject: RE: JSTL tag prefix naming conventions? So, sorry I didn't respond earlier; for some reason, the mailing list didn't send me these messages until hours later. Thanks for all your comments; I can't speak authoritatively for the entire expert group, but here are my own personal opinions. On Thu, 21 Mar 2002, Steve Bang wrote: While Java also supports meaningful naming, in this case the goal is to create tag libraries for non-programmers. So, names like x and fmt are not terribly clear. The HTML tags are not cryptic, and whenever possible, neither should JSP tags. Overall, I'd certainly never argue for tags that are cryptic, but HTML tags certainly use abbreviations, just for the sake of brevity. There's an a tag instead of anchor; p instead of paragraph; and img instead of image. In fact, nearly all HTML tags are cryptic if you don't like abbreviations. :-) Concerning analogies with Java, I'm not sure I agree. The J2SE libraries certainly use reasonably long names for classes, but namespace prefixes are more like packages, and the standard libraries all use abbreviations: java.io, java.util, java.lang. Like the J2SE libraries, we don't abbreviate the tag (class) names: forEach, forTokens (instead of 'f' or 'ft'). At any rate, it looks (to me) like we're in good company. I undestand that the HTML tags don't need a prefix, but we should keep in mind the intended audience and minimize confusion. If the standard JSP tags were j:useBean, j:setProperty, etc., it would be confusing -- would the j represent Java or JSP? And, if HTML tags had to have a prefix, would you find h a good prefix? I doubt it -- I'd much prefer html as a prefix. To avoid collisions and other confusion, I'm leaning toward having jstl at the beginning of the prefixes. Shawn, hasn't this issue been discussed among the expert group? Or, was this something no one ever thought about discussing? This definitely came up; it was debated at length in the context of whether to provide a single JSTL tag library or multiple tag libraries. The rationale for the perceived inconsistency in the naming is what Henri said: simplicity to type. After all, 'core' or 'jstlcore' are just as opaque as 'c' without ANY context; given that JSTL is the standard and is expected to be used widely, we figured that c:forEach would be much easier to read and identify than jstlcore:forEach FMT could be called 'f', but it does take a slight back-seat to the core library in this regard. I'd expect many pages just to use 'c'. The XML tag library might have ideally been prefixed 'xml', but the XML standard itself rules that out :-), and we figured we'd promote the library by giving it its own, one-letter abbreviation. Whatever we choose would be somewhat arbitrary, so we ultimately opted to ease the page author's burden of typing! -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- 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]
RE: JSTL tag prefix naming conventions?
On Thu, 21 Mar 2002, Steve Bang wrote: OK, I guess I slipped on the intuitiveness of HTML tags -- I don't know where my mind was at that moment. Regardless, I prefer consistency and clarity whenever possible. I know you do too. Your clarified the issues and I am somewhat comfortable with the outcome. And, now I understand why sql was used, but not xml. Another advantage of the parallel between 'c' and 'x' is that it highlights the analogy between the two tag libraries. That is, you use 'c:out' to print data using the master expression language, and 'x:out' to print XML data using XPath. The same goes for 'if', 'set', 'when', and even 'forEach'. The parallelism might not be as clear if we called the tags 'xpath:out'. There's also an advantage in giving prominence to your XML support, these days. :-) I still think that it would be nice if all of the libraries started with jstl so that they appeared related. Oh, well. It's funny; I agreed with this in spirit as well for a long time. I initially had advocated using a 'j' prefix to distinguish JSTL tags, so that we'd end up with 'jc', 'jx', 'jf', and 'js' (so far). But this was (rightfully, I think) seen as MORE cryptic than the current system. Ultimately, I think that users will know they're looking at JSTL tags by virtue of general familiarity. But I agree -- any solution is somewhat arbitrary and imperfect. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Can you test for a cookie's value using c:if tag?
Is it possible to do the following with JSTL?
c:if test=${cookie.username == 'learner'}
learner
/c:if
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Can you test for a cookie's value using c:if tag?
On Thu, 21 Mar 2002, Matt Raible wrote:
Is it possible to do the following with JSTL?
c:if test=${cookie.username == 'learner'}
learner
/c:if
Ah, I was hoping someone would ask. The answer is no, not exactly like
that, but you can still use JSTL to access cookies.
While web developers often have the urge to access a cookie by name, it's
an urge that's best to resist; cookies aren't identified by name alone,
but by name, domain, path, and security status. Thus, the best way to
access a cookie is to loop over the list of available cookies, matching
the one that you're interested in.
Now, if you're just interested in name, that's fine; but JSTL doesn't go
out of its way to support that special case. Instead, you can just write
c:forEach items=${pageContext.request.cookies} var=cookie
c:if test=${cookie.name == 'learner'}
c:set var=cookieValue value=${cookie.value} /
/c:if
/c:forEach
I explain this in more detail in my book; interestingly enough, I just
wrote the section describing techniques like this.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
