RE: display tag library
I don't know which tag library you're referring to, but I believe you should be able to call pageContext.getRequest() from any method in a class that extends TagSupport. -Ben From: Honza Spurný [EMAIL PROTECTED] Reply-To: Honza Spurný [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: display tag library Date: Tue, 2 Dec 2003 15:51:59 +0100 Hi there, does anybody have any experience with taglibary display? If yes, please advise me, how can I get the request object in the finishRow() method or in the tableDecorator method. Please, help me, thanks a lot Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ From the hottest toys to tips on keeping fit this winter, youll find a range of helpful holiday info here. http://special.msn.com/network/happyholidays.armx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: display tag library
Ben Anderson wrote: I don't know which tag library you're referring to, but I believe you should be able to call pageContext.getRequest() from any method in a class that extends TagSupport. -Ben I'm not sure if I understood it well, but java compiler cannot find pageContext variable, please could you specify, where can be this variable found? Thanks Sporak From: Honza Spurn [EMAIL PROTECTED] Reply-To: Honza Spurn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: display tag library Date: Tue, 2 Dec 2003 15:51:59 +0100 Hi there, does anybody have any experience with taglibary display? If yes, please advise me, how can I get the request object in the finishRow() method or in the tableDecorator method. Please, help me, thanks a lot Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ From the hottest toys to tips on keeping fit this winter, youll find a range of helpful holiday info here. http://special.msn.com/network/happyholidays.armx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: display tag library
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/jsp/tagext/TagSupport.html From: Honza Spurný [EMAIL PROTECTED] Reply-To: Honza Spurný [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: display tag library Date: Tue, 2 Dec 2003 16:39:22 +0100 Ben Anderson wrote: I don't know which tag library you're referring to, but I believe you should be able to call pageContext.getRequest() from any method in a class that extends TagSupport. -Ben I'm not sure if I understood it well, but java compiler cannot find pageContext variable, please could you specify, where can be this variable found? Thanks Sporak From: Honza Spurný [EMAIL PROTECTED] Reply-To: Honza Spurný [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: display tag library Date: Tue, 2 Dec 2003 15:51:59 +0100 Hi there, does anybody have any experience with taglibary display? If yes, please advise me, how can I get the request object in the finishRow() method or in the tableDecorator method. Please, help me, thanks a lot Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ From the hottest toys to tips on keeping fit this winter, youll find a range of helpful holiday info here. http://special.msn.com/network/happyholidays.armx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Groove on the latest from the hot new rock groups! Get downloads, videos, and more here. http://special.msn.com/entertainment/wiredformusic.armx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: display tag library
If you're taking about TableDecorator.finishRow, you should notice that TableDecorator also has a getPageContext method (inherited from Decorator). You should be able to figure out where to go from there... Quoting Honza Spurný [EMAIL PROTECTED]: Ben Anderson wrote: I don't know which tag library you're referring to, but I believe you should be able to call pageContext.getRequest() from any method in a class that extends TagSupport. -Ben I'm not sure if I understood it well, but java compiler cannot find pageContext variable, please could you specify, where can be this variable found? Thanks Sporak From: Honza Spurný [EMAIL PROTECTED] Reply-To: Honza Spurný [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: display tag library Date: Tue, 2 Dec 2003 15:51:59 +0100 Hi there, does anybody have any experience with taglibary display? If yes, please advise me, how can I get the request object in the finishRow() method or in the tableDecorator method. Please, help me, thanks a lot Sporak -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Display Tag Library Project setup at SF
All, I've setup a project at SourceForge for the Display Tag Library. Please e-mail me if you'd like to have committer rights to the project. Also, if anyone has Admin experience at SF, please let me know (I've only been a committer). The first thing is probably to get someone's enhancements in there and get a release out (v 0.9?). Thanks, Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:34 AM To: [EMAIL PROTECTED] Subject: SourceForge.net Project Approved Your project registration for SourceForge.net has been approved. Project Descriptive Name: Display Tag Library Project Unix Name: displaytag CVS Server: cvs.displaytag.sourceforge.net Shell/Web Server: displaytag.sourceforge.net Your DNS will take up to a day to become active on our site. While waiting for your DNS to resolve, you may try shelling into shell.sourceforge.net and pointing CVS to cvs.sourceforge.net. If after 6 hours your shell/CVS accounts still do not work, please open a support ticket so that we may take a look at the problem. Please note that all shell/CVS accounts are closed to telnet and only work with SSH1. Your web site is accessible through your shell account. Please read site documentation (see link below) about intended usage, available services, and directory layout of the account. Please take some time to read the site documentation about project administration (http://sourceforge.net/docs/site/). If you visit your own project page in SourceForge.net while logged in, you will find additional menu functions to your left labeled 'Project Admin'. We highly suggest that you now visit SourceForge.net and create a public description for your project. This can be done by visiting your project page while logged in, and selecting 'Project Admin' from the menus on the left (or by visiting https://sourceforge.net/project/admin/?group_id=73068 after login). Your project will also not appear in the Trove Software Map (primary list of projects hosted on SourceForge.net which offers great flexibility in browsing and search) until you categorize it in the project administration screens. So that people can find your project, you should do this now. Visit your project while logged in, and select 'Project Admin' from the menus on the left. Enjoy the system, and please tell others about SourceForge.net. Let us know if there is anything we can do to help you. -- the SourceForge.net crew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Display Tag Library Project setup at SF
I would like to be a part of this project. An Account of some of the changes I have made can be found at www.tablelib.com/changes.jsp - Original Message - From: Matt Raible [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Ed Hill [EMAIL PROTECTED] Sent: Monday, February 03, 2003 1:16 PM Subject: [OT] Display Tag Library Project setup at SF All, I've setup a project at SourceForge for the Display Tag Library. Please e-mail me if you'd like to have committer rights to the project. Also, if anyone has Admin experience at SF, please let me know (I've only been a committer). The first thing is probably to get someone's enhancements in there and get a release out (v 0.9?). Thanks, Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:34 AM To: [EMAIL PROTECTED] Subject: SourceForge.net Project Approved Your project registration for SourceForge.net has been approved. Project Descriptive Name: Display Tag Library Project Unix Name: displaytag CVS Server: cvs.displaytag.sourceforge.net Shell/Web Server: displaytag.sourceforge.net Your DNS will take up to a day to become active on our site. While waiting for your DNS to resolve, you may try shelling into shell.sourceforge.net and pointing CVS to cvs.sourceforge.net. If after 6 hours your shell/CVS accounts still do not work, please open a support ticket so that we may take a look at the problem. Please note that all shell/CVS accounts are closed to telnet and only work with SSH1. Your web site is accessible through your shell account. Please read site documentation (see link below) about intended usage, available services, and directory layout of the account. Please take some time to read the site documentation about project administration (http://sourceforge.net/docs/site/). If you visit your own project page in SourceForge.net while logged in, you will find additional menu functions to your left labeled 'Project Admin'. We highly suggest that you now visit SourceForge.net and create a public description for your project. This can be done by visiting your project page while logged in, and selecting 'Project Admin' from the menus on the left (or by visiting https://sourceforge.net/project/admin/?group_id=73068 after login). Your project will also not appear in the Trove Software Map (primary list of projects hosted on SourceForge.net which offers great flexibility in browsing and search) until you categorize it in the project administration screens. So that people can find your project, you should do this now. Visit your project while logged in, and select 'Project Admin' from the menus on the left. Enjoy the system, and please tell others about SourceForge.net. Let us know if there is anything we can do to help you. -- the SourceForge.net crew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Display Tag Library Project setup at SF
I've setup mailing lists for this project, please subscribe to displaytag-devel to continue discussions on this matter. http://sourceforge.net/mail/?group_id=73068 Matt -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:16 AM To: '[EMAIL PROTECTED]' Cc: Ed Hill ([EMAIL PROTECTED]) Subject: [OT] Display Tag Library Project setup at SF All, I've setup a project at SourceForge for the Display Tag Library. Please e-mail me if you'd like to have committer rights to the project. Also, if anyone has Admin experience at SF, please let me know (I've only been a committer). The first thing is probably to get someone's enhancements in there and get a release out (v 0.9?). Thanks, Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:34 AM To: [EMAIL PROTECTED] Subject: SourceForge.net Project Approved Your project registration for SourceForge.net has been approved. Project Descriptive Name: Display Tag Library Project Unix Name: displaytag CVS Server: cvs.displaytag.sourceforge.net Shell/Web Server: displaytag.sourceforge.net Your DNS will take up to a day to become active on our site. While waiting for your DNS to resolve, you may try shelling into shell.sourceforge.net and pointing CVS to cvs.sourceforge.net. If after 6 hours your shell/CVS accounts still do not work, please open a support ticket so that we may take a look at the problem. Please note that all shell/CVS accounts are closed to telnet and only work with SSH1. Your web site is accessible through your shell account. Please read site documentation (see link below) about intended usage, available services, and directory layout of the account. Please take some time to read the site documentation about project administration (http://sourceforge.net/docs/site/). If you visit your own project page in SourceForge.net while logged in, you will find additional menu functions to your left labeled 'Project Admin'. We highly suggest that you now visit SourceForge.net and create a public description for your project. This can be done by visiting your project page while logged in, and selecting 'Project Admin' from the menus on the left (or by visiting https://sourceforge.net/project/admin/?group_id=73068 after login). Your project will also not appear in the Trove Software Map (primary list of projects hosted on SourceForge.net which offers great flexibility in browsing and search) until you categorize it in the project administration screens. So that people can find your project, you should do this now. Visit your project while logged in, and select 'Project Admin' from the menus on the left. Enjoy the system, and please tell others about SourceForge.net. Let us know if there is anything we can do to help you. -- the SourceForge.net crew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Display Tag Library Project setup at SF
Do you have a user account at SF.net so I can make you a developer on the project? Thanks, Matt -Original Message- From: Benjamin Simpson To: Struts Users Mailing List Sent: 2/3/2003 11:48 AM Subject: Re: [OT] Display Tag Library Project setup at SF I would like to be a part of this project. An Account of some of the changes I have made can be found at www.tablelib.com/changes.jsp - Original Message - From: Matt Raible [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Ed Hill [EMAIL PROTECTED] Sent: Monday, February 03, 2003 1:16 PM Subject: [OT] Display Tag Library Project setup at SF All, I've setup a project at SourceForge for the Display Tag Library. Please e-mail me if you'd like to have committer rights to the project. Also, if anyone has Admin experience at SF, please let me know (I've only been a committer). The first thing is probably to get someone's enhancements in there and get a release out (v 0.9?). Thanks, Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:34 AM To: [EMAIL PROTECTED] Subject: SourceForge.net Project Approved Your project registration for SourceForge.net has been approved. Project Descriptive Name: Display Tag Library Project Unix Name: displaytag CVS Server: cvs.displaytag.sourceforge.net Shell/Web Server: displaytag.sourceforge.net Your DNS will take up to a day to become active on our site. While waiting for your DNS to resolve, you may try shelling into shell.sourceforge.net and pointing CVS to cvs.sourceforge.net. If after 6 hours your shell/CVS accounts still do not work, please open a support ticket so that we may take a look at the problem. Please note that all shell/CVS accounts are closed to telnet and only work with SSH1. Your web site is accessible through your shell account. Please read site documentation (see link below) about intended usage, available services, and directory layout of the account. Please take some time to read the site documentation about project administration (http://sourceforge.net/docs/site/). If you visit your own project page in SourceForge.net while logged in, you will find additional menu functions to your left labeled 'Project Admin'. We highly suggest that you now visit SourceForge.net and create a public description for your project. This can be done by visiting your project page while logged in, and selecting 'Project Admin' from the menus on the left (or by visiting https://sourceforge.net/project/admin/?group_id=73068 after login). Your project will also not appear in the Trove Software Map (primary list of projects hosted on SourceForge.net which offers great flexibility in browsing and search) until you categorize it in the project administration screens. So that people can find your project, you should do this now. Visit your project while logged in, and select 'Project Admin' from the menus on the left. Enjoy the system, and please tell others about SourceForge.net. Let us know if there is anything we can do to help you. -- the SourceForge.net crew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Display Tag Library Project setup at SF
I would also like to be part of this project. I've rewritten most of this tag using the MVC design pattern. Its structure will be much easier to use and the code is for the most part very clean. Hopefully we can re-use some of what I've written and/or at least use it for comparison. My code is available here: http://www.johnyork.com/table-src.tar.gz Currently, it is dependent on log4j, struts, and the 2.3 JSDK The only struts reference is to RequestUtils, which would be easy to pull out and make it useable without struts. We had several design goals for reimplementing this tag, some of which were: 0. Paging ( Ed Hill's version already did this ) 1. Sorting over multiple pages. 2. Providing a way to optionally display columns 3. Export to CSV( comma seperated value ) format 4. Caching for data that is expensive to retrieve 5. Complete customization of column names and values 6. Default sorting of a specified column 7. Extendable MVC architecture We've met all of these goals to some degree and I believe the results will be useful to everyone else on this list. John On Mon, 3 Feb 2003, Matt Raible wrote: All, I've setup a project at SourceForge for the Display Tag Library. Please e-mail me if you'd like to have committer rights to the project. Also, if anyone has Admin experience at SF, please let me know (I've only been a committer). The first thing is probably to get someone's enhancements in there and get a release out (v 0.9?). Thanks, Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:34 AM To: [EMAIL PROTECTED] Subject: SourceForge.net Project Approved Your project registration for SourceForge.net has been approved. Project Descriptive Name: Display Tag Library Project Unix Name: displaytag CVS Server: cvs.displaytag.sourceforge.net Shell/Web Server: displaytag.sourceforge.net Your DNS will take up to a day to become active on our site. While waiting for your DNS to resolve, you may try shelling into shell.sourceforge.net and pointing CVS to cvs.sourceforge.net. If after 6 hours your shell/CVS accounts still do not work, please open a support ticket so that we may take a look at the problem. Please note that all shell/CVS accounts are closed to telnet and only work with SSH1. Your web site is accessible through your shell account. Please read site documentation (see link below) about intended usage, available services, and directory layout of the account. Please take some time to read the site documentation about project administration (http://sourceforge.net/docs/site/). If you visit your own project page in SourceForge.net while logged in, you will find additional menu functions to your left labeled 'Project Admin'. We highly suggest that you now visit SourceForge.net and create a public description for your project. This can be done by visiting your project page while logged in, and selecting 'Project Admin' from the menus on the left (or by visiting https://sourceforge.net/project/admin/?group_id=73068 after login). Your project will also not appear in the Trove Software Map (primary list of projects hosted on SourceForge.net which offers great flexibility in browsing and search) until you categorize it in the project administration screens. So that people can find your project, you should do this now. Visit your project while logged in, and select 'Project Admin' from the menus on the left. Enjoy the system, and please tell others about SourceForge.net. Let us know if there is anything we can do to help you. -- the SourceForge.net crew -- John York Software Engineer CareerSite Corporation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Display Tag Library and grouping
I have a table with 6 columns. I am grouping on the first 4 columns using
group=$columnNo. I'm wondering if it's possible to have the # of items in
the displaying 1 of 20 items reflect one of my grouped columns. For
instance, column 3 has 10 items, even though there are 20 items in the list.
I'd like to have it say, displaying 1 of 10 ${column 3 field}. I realize I
can change the name of items to whatever I want - but changing the count
is what I want - without modifying any code.
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Display Tag Library and grouping
Another grouping issue - if nothing else, this is helping me get ready to
put these into a bug tracking system ;-)
When I sort on any of the columns (except for column 3), the grouping in
column 3 is lost. I suppose it's probably lost in the other columns as
well, it's just not as visible as column 3. I can attach screenshots if
it'll help. Don't know that this mailing list will allow them tho.
Thanks,
Matt
-Original Message-
From: Raible, Matt
Sent: Friday, January 31, 2003 10:58 AM
To: '[EMAIL PROTECTED]'
Subject: [OT] Display Tag Library and grouping
I have a table with 6 columns. I am grouping on the first 4
columns using group=$columnNo. I'm wondering if it's
possible to have the # of items in the displaying 1 of 20
items reflect one of my grouped columns. For instance,
column 3 has 10 items, even though there are 20 items in the
list. I'd like to have it say, displaying 1 of 10 ${column 3
field}. I realize I can change the name of items to
whatever I want - but changing the count is what I want -
without modifying any code.
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Display Tag Library - Sorting Dates
Since there seems to be a lot of display:* users on this list, I thought
I'd ask this question here - hope you don't mind.
I have a string in my form that is a date. In order to get the display tag
library to sort this column (date) correctly, I have added the following
method in a Decorator:
public Date getDate() {
MyForm form = (MyForm) this.getObject();
Date d = null;
try {
d = DateUtil.convertStringToDate(DateUtil.getUIDatePattern(),
form.getDate);
} catch (ParseException pe) {
pe.printStackTrace();
log.error(Error converting String date to real Date: + pe);
}
return d;
}
The problem is that the display tag just calls toString() on the date, so I
end up with the following in my column:
Thu Feb 06 00:00:00 MST 2003
When I want, something like Feb 6, 2003. However, to do this, I need to
return a String, and then it doesn't sort correctly. I can hack the code in
the display tag library to try to parse all columns, and if it succeeds then
it assumes it is a date, and uses a format. But I'm hoping that someone has
a more elegant solution.
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Display Tag Library - Sorting Dates
Couldn't you subclass Date and override toString?
-Original Message-
From: Raible, Matt [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 30, 2003 11:41 AM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: [OT] Display Tag Library - Sorting Dates
Since there seems to be a lot of display:* users on this list, I thought
I'd ask this question here - hope you don't mind.
I have a string in my form that is a date. In order to get the
display tag
library to sort this column (date) correctly, I have added the following
method in a Decorator:
public Date getDate() {
MyForm form = (MyForm) this.getObject();
Date d = null;
try {
d = DateUtil.convertStringToDate(DateUtil.getUIDatePattern(),
form.getDate);
} catch (ParseException pe) {
pe.printStackTrace();
log.error(Error converting String date to real Date: + pe);
}
return d;
}
The problem is that the display tag just calls toString() on the
date, so I
end up with the following in my column:
Thu Feb 06 00:00:00 MST 2003
When I want, something like Feb 6, 2003. However, to do this, I need to
return a String, and then it doesn't sort correctly. I can hack
the code in
the display tag library to try to parse all columns, and if it
succeeds then
it assumes it is a date, and uses a format. But I'm hoping that
someone has
a more elegant solution.
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Display Tag Library - Sorting Dates
Good idea - that worked - thanks!
Matt
-Original Message-
From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 30, 2003 10:00 AM
To: Struts Users Mailing List
Subject: RE: [OT] Display Tag Library - Sorting Dates
Couldn't you subclass Date and override toString?
-Original Message-
From: Raible, Matt [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 30, 2003 11:41 AM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: [OT] Display Tag Library - Sorting Dates
Since there seems to be a lot of display:* users on this
list, I thought
I'd ask this question here - hope you don't mind.
I have a string in my form that is a date. In order to get the
display tag
library to sort this column (date) correctly, I have added
the following
method in a Decorator:
public Date getDate() {
MyForm form = (MyForm) this.getObject();
Date d = null;
try {
d =
DateUtil.convertStringToDate(DateUtil.getUIDatePattern(),
form.getDate);
} catch (ParseException pe) {
pe.printStackTrace();
log.error(Error converting String date to real
Date: + pe);
}
return d;
}
The problem is that the display tag just calls toString() on the
date, so I
end up with the following in my column:
Thu Feb 06 00:00:00 MST 2003
When I want, something like Feb 6, 2003. However, to do
this, I need to
return a String, and then it doesn't sort correctly. I can hack
the code in
the display tag library to try to parse all columns, and if it
succeeds then
it assumes it is a date, and uses a format. But I'm hoping that
someone has
a more elegant solution.
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: The display:* tag library
Ed, I received lots of interested parties from my mailing to the struts-user list. You can view the responses by following the thread at: http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg55520.ht ml Please let me know what we should do next to start a project at SourceForge. Thanks, Matt -Original Message- From: Ed Hill [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 10:17 PM To: Matt Raible Subject: Re: The display:* tag library I would gladly support any efforts to continue (restart) development on my taglib. I've reserved some sourceforge space myself, but have not moved things over yet. Alas, it currently does what I need it to do and other priorities have well taken priority. If someone steps up to volunteer to be the pumpkin keeper (sorry, Perl cultural reference), I will do what I can to help (redirect my web site on my personal machine to the new home, etc...) I don't subscribe to the struts-user list, so if you would please forward this on to encourage any discussion, I would appreciate it. Thank you! -Ed Hill ([EMAIL PROTECTED]) Software Developer - Information Technology Services - University of Iowa On Wed, 22 Jan 2003, Matt Raible wrote: Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The display:* tag library
I disagree on the sorting feature -- I'd vote to keep it, as we use it heavily Dave -- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] http://www.messagecast.net -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:07 AM To: Struts Users Mailing List Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: The display:* tag library +1 I've added support for Struts messages in column titles, glad to contribute it. Since I really depend on this library for a product I've developed, and need to fix some problems, make some additions, I'd be pleased to work with others on improving this great piece of code, perhaps be the pumpkin keeper if no one else will do it (although I'm reluctant to volunteer, as I haven't performed that role before, except as a gardner ;-) chaz -- Charles E Brault [EMAIL PROTECTED] Where are we going, and why am I in this handbasket? -- 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]
Re: The display:* tag library
Please keep the sorting feature! It is used lots and helps performance as there isn't a need to hit the database everytime Ka-Wai Dave Hodson wrote: I disagree on the sorting feature -- I'd vote to keep it, as we use it heavily Dave -- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] http://www.messagecast.net -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:07 AM To: Struts Users Mailing List Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: The display:* tag library +1 I've added support for Struts messages in column titles, glad to contribute it. Since I really depend on this library for a product I've developed, and need to fix some problems, make some additions, I'd be pleased to work with others on improving this great piece of code, perhaps be the pumpkin keeper if no one else will do it (although I'm reluctant to volunteer, as I haven't performed that role before, except as a gardner ;-) chaz -- Charles E Brault [EMAIL PROTECTED] Where are we going, and why am I in this handbasket? -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: The display:* tag library
To be clear I was just outlining what I thought would be an improved display-like taglib. I wish I actually had the time to implement it, but I don't. The behavior of the current taglib's sorting feature is non-intuitive when there are multiple pages. Also, there is no need to go to the database every time if you implement the first alternative I listed. That is, the user links the sortable column(s) to an Action which sorts the Collection stored in the session. I did consider the sorting plus paging problem and thought that maybe if there were multiple pages and the user clicked a sortable column while on page 5 they would just be taken back to page 1 after the Collection was sorted. However once you add the sorting capability then I'd bet there'd be an expectation that you should be able to provide a Comparator class name to the display2:column tag. I don't like having Java classnames in JSP attributes (another reason to get rid of the Decorator). And it is fairly simple to let the Action do the sorting of the Collection and it can use whatever Comparator it wants. -Jerome -Original Message- From: Ka-Wai Chan [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 3:14 PM To: Struts Users Mailing List Subject: Re: The display:* tag library Please keep the sorting feature! It is used lots and helps performance as there isn't a need to hit the database everytime Ka-Wai Dave Hodson wrote: I disagree on the sorting feature -- I'd vote to keep it, as we use it heavily Dave -- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] http://www.messagecast.net -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:07 AM To: Struts Users Mailing List Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: The display:* tag library +1 I've added support for Struts messages in column titles, glad to contribute it. Since I really depend on this library for a product I've developed, and need to fix some problems, make some additions, I'd be pleased to work with others on improving this great piece of code, perhaps
RE: The display:* tag library
Your database should *always* sort a result faster than any code you write. So there is usually no reason to sort it yourself unless your db connection is terribly slow. David From: Jerome Jacobsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: The display:* tag library Date: Fri, 24 Jan 2003 15:50:01 -0500 To be clear I was just outlining what I thought would be an improved display-like taglib. I wish I actually had the time to implement it, but I don't. The behavior of the current taglib's sorting feature is non-intuitive when there are multiple pages. Also, there is no need to go to the database every time if you implement the first alternative I listed. That is, the user links the sortable column(s) to an Action which sorts the Collection stored in the session. I did consider the sorting plus paging problem and thought that maybe if there were multiple pages and the user clicked a sortable column while on page 5 they would just be taken back to page 1 after the Collection was sorted. However once you add the sorting capability then I'd bet there'd be an expectation that you should be able to provide a Comparator class name to the display2:column tag. I don't like having Java classnames in JSP attributes (another reason to get rid of the Decorator). And it is fairly simple to let the Action do the sorting of the Collection and it can use whatever Comparator it wants. -Jerome -Original Message- From: Ka-Wai Chan [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 3:14 PM To: Struts Users Mailing List Subject: Re: The display:* tag library Please keep the sorting feature! It is used lots and helps performance as there isn't a need to hit the database everytime Ka-Wai Dave Hodson wrote: I disagree on the sorting feature -- I'd vote to keep it, as we use it heavily Dave -- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] http://www.messagecast.net -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:07 AM To: Struts Users Mailing List Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM
RE: The display:* tag library
That depends on the complexity of the query (number of joins, etc.) and the size of the result set. I'll bet the JVM can sort a ten item List faster than a database call. It also depends on how your application is tiered. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 3:56 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: The display:* tag library Your database should *always* sort a result faster than any code you write. So there is usually no reason to sort it yourself unless your db connection is terribly slow. David From: Jerome Jacobsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: The display:* tag library Date: Fri, 24 Jan 2003 15:50:01 -0500 To be clear I was just outlining what I thought would be an improved display-like taglib. I wish I actually had the time to implement it, but I don't. The behavior of the current taglib's sorting feature is non-intuitive when there are multiple pages. Also, there is no need to go to the database every time if you implement the first alternative I listed. That is, the user links the sortable column(s) to an Action which sorts the Collection stored in the session. I did consider the sorting plus paging problem and thought that maybe if there were multiple pages and the user clicked a sortable column while on page 5 they would just be taken back to page 1 after the Collection was sorted. However once you add the sorting capability then I'd bet there'd be an expectation that you should be able to provide a Comparator class name to the display2:column tag. I don't like having Java classnames in JSP attributes (another reason to get rid of the Decorator). And it is fairly simple to let the Action do the sorting of the Collection and it can use whatever Comparator it wants. -Jerome -Original Message- From: Ka-Wai Chan [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 3:14 PM To: Struts Users Mailing List Subject: Re: The display:* tag library Please keep the sorting feature! It is used lots and helps performance as there isn't a need to hit the database everytime Ka-Wai Dave Hodson wrote: I disagree on the sorting feature -- I'd vote to keep it, as we use it heavily Dave -- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] http://www.messagecast.net -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:07 AM To: Struts Users Mailing List Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column
RE: The display:* tag library
Of course all of those factors affect the speed. Database's main job in life is storing and manipulating data so they are far better at sorting than application code. David From: Jerome Jacobsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: The display:* tag library Date: Fri, 24 Jan 2003 16:09:34 -0500 That depends on the complexity of the query (number of joins, etc.) and the size of the result set. I'll bet the JVM can sort a ten item List faster than a database call. It also depends on how your application is tiered. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 3:56 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: The display:* tag library Your database should *always* sort a result faster than any code you write. So there is usually no reason to sort it yourself unless your db connection is terribly slow. David From: Jerome Jacobsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: The display:* tag library Date: Fri, 24 Jan 2003 15:50:01 -0500 To be clear I was just outlining what I thought would be an improved display-like taglib. I wish I actually had the time to implement it, but I don't. The behavior of the current taglib's sorting feature is non-intuitive when there are multiple pages. Also, there is no need to go to the database every time if you implement the first alternative I listed. That is, the user links the sortable column(s) to an Action which sorts the Collection stored in the session. I did consider the sorting plus paging problem and thought that maybe if there were multiple pages and the user clicked a sortable column while on page 5 they would just be taken back to page 1 after the Collection was sorted. However once you add the sorting capability then I'd bet there'd be an expectation that you should be able to provide a Comparator class name to the display2:column tag. I don't like having Java classnames in JSP attributes (another reason to get rid of the Decorator). And it is fairly simple to let the Action do the sorting of the Collection and it can use whatever Comparator it wants. -Jerome -Original Message- From: Ka-Wai Chan [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 3:14 PM To: Struts Users Mailing List Subject: Re: The display:* tag library Please keep the sorting feature! It is used lots and helps performance as there isn't a need to hit the database everytime Ka-Wai Dave Hodson wrote: I disagree on the sorting feature -- I'd vote to keep it, as we use it heavily Dave -- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] http://www.messagecast.net -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:07 AM To: Struts Users Mailing List Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl
RE: The display:* tag library
+1 -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 23. Januar 2003 06:05 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: The display:* tag library Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- 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: The display:* tag library
Ed, Thanks for getting back to me. I actually sent the same message you see below (mine not yours) to the struts-user list last night. I'll let you know what they say and if I can find a pumpkin keeper. In the meantime, if you want to get the ball rolling for setting up a project at SF, that'd be awesome. Thanks, Matt -Original Message- From: Ed Hill [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 10:17 PM To: Matt Raible Subject: Re: The display:* tag library I would gladly support any efforts to continue (restart) development on my taglib. I've reserved some sourceforge space myself, but have not moved things over yet. Alas, it currently does what I need it to do and other priorities have well taken priority. If someone steps up to volunteer to be the pumpkin keeper (sorry, Perl cultural reference), I will do what I can to help (redirect my web site on my personal machine to the new home, etc...) I don't subscribe to the struts-user list, so if you would please forward this on to encourage any discussion, I would appreciate it. Thank you! -Ed Hill ([EMAIL PROTECTED]) Software Developer - Information Technology Services - University of Iowa On Wed, 22 Jan 2003, Matt Raible wrote: Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: The display:* tag library
Sounds like a great idea to me. You may want to touch base with Rick Ruemann and Tim Golden as well. It sounds like they've made some addition's to Ed's original library: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg53513.html http://timgolden.com/taglib/ JOHN -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 5:55 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: The display:* tag library Ed, Thanks for getting back to me. I actually sent the same message you see below (mine not yours) to the struts-user list last night. I'll let you know what they say and if I can find a pumpkin keeper. In the meantime, if you want to get the ball rolling for setting up a project at SF, that'd be awesome. Thanks, Matt -Original Message- From: Ed Hill [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 10:17 PM To: Matt Raible Subject: Re: The display:* tag library I would gladly support any efforts to continue (restart) development on my taglib. I've reserved some sourceforge space myself, but have not moved things over yet. Alas, it currently does what I need it to do and other priorities have well taken priority. If someone steps up to volunteer to be the pumpkin keeper (sorry, Perl cultural reference), I will do what I can to help (redirect my web site on my personal machine to the new home, etc...) I don't subscribe to the struts-user list, so if you would please forward this on to encourage any discussion, I would appreciate it. Thank you! -Ed Hill ([EMAIL PROTECTED]) Software Developer - Information Technology Services - University of Iowa On Wed, 22 Jan 2003, Matt Raible wrote: Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- 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: The display:* tag library
Matt, I'ld like to see Ed's paging API broken into more layers; separate paging functionality from HTML generation. I've already tweaked the code a little to provide the ability to publish the current page and page size to any hyperlinked column so that after viewing the details, you can jump back to the same page of results with the same number of items per page being displayed. robert -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 12:05 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: The display:* tag library Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- 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: The display:* tag library
+1 I've added support for Struts messages in column titles, glad to contribute it. Since I really depend on this library for a product I've developed, and need to fix some problems, make some additions, I'd be pleased to work with others on improving this great piece of code, perhaps be the pumpkin keeper if no one else will do it (although I'm reluctant to volunteer, as I haven't performed that role before, except as a gardner ;-) chaz -- Charles E Brault [EMAIL PROTECTED] Where are we going, and why am I in this handbasket? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re[2]: The display:* tag library
On Thursday, January 23, 2003, 8:33:20 AM, Robert wrote: RT Matt, RT I'ld like to see Ed's paging API broken into more layers; RT separate paging functionality from HTML generation. RT I've already tweaked the code a little to provide the ability RT to publish the current page and page size to any hyperlinked RT column so that after viewing the details, you can jump back RT to the same page of results with the same number of items RT per page being displayed. You guys also might want to get with Tim who's done a lot of work with this tag also. This link shows the changes he's made: http://timgolden.com/taglib/ All of this functionality and the latest changes you guys made should be combined. I think possibly one of you guys should maybe take over this project and set up a yahoo group or something. A lot has been brought up as of late and a lot of changes have been made to it over time. I think I started way back with the ability to define a columns parameter and then I noticed Tim made tons more changes. Now with the changes you made Robert it's come along even further. Ed seems to have dropped out of existence so I don't think he would mind his work continuing forward. RT robert -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 12:05 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: The display:* tag library Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] RT -- RT To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] RT For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Rick mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The display:* tag library
+1 This lib is very useful, I'd be glad to help Ka-Wai Rick Reumann wrote: On Thursday, January 23, 2003, 8:33:20 AM, Robert wrote: RT Matt, RT I'ld like to see Ed's paging API broken into more layers; RT separate paging functionality from HTML generation. RT I've already tweaked the code a little to provide the ability RT to publish the current page and page size to any hyperlinked RT column so that after viewing the details, you can jump back RT to the same page of results with the same number of items RT per page being displayed. You guys also might want to get with Tim who's done a lot of work with this tag also. This link shows the changes he's made: http://timgolden.com/taglib/ All of this functionality and the latest changes you guys made should be combined. I think possibly one of you guys should maybe take over this project and set up a yahoo group or something. A lot has been brought up as of late and a lot of changes have been made to it over time. I think I started way back with the ability to define a columns parameter and then I noticed Tim made tons more changes. Now with the changes you made Robert it's come along even further. Ed seems to have dropped out of existence so I don't think he would mind his work continuing forward. RT robert -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 12:05 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: The display:* tag library Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] RT -- RT To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] RT For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: The display:* tag library
I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: The display:* tag library +1 I've added support for Struts messages in column titles, glad to contribute it. Since I really depend on this library for a product I've developed, and need to fix some problems, make some additions, I'd be pleased to work with others on improving this great piece of code, perhaps be the pumpkin keeper if no one else will do it (although I'm reluctant to volunteer, as I haven't performed that role before, except as a gardner ;-) chaz -- Charles E Brault [EMAIL PROTECTED] Where are we going, and why am I in this handbasket? -- 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: The display:* tag library
I have started the rewrite/refactor. My src is available and is still in progress. The intent is to introduce an independent Table interface to be portable to other frameworks including a swing based JTable. Help yourself if it is helpful. If you would like my involvement I am interested. http://www.tablelib.com Ben Simpson [EMAIL PROTECTED] - Original Message - From: Jerome Jacobsen [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 11:07 AM Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: The display:* tag library +1 I've added support for Struts messages in column titles, glad to contribute it. Since I really depend on this library for a product I've developed, and need to fix some problems, make some additions, I'd be pleased to work with others on improving this great piece of code, perhaps be the pumpkin keeper if no one else will do it (although I'm reluctant to volunteer, as I haven't performed that role before, except as a gardner ;-) chaz -- Charles E Brault [EMAIL PROTECTED] Where are we going, and why am I in this handbasket? -- 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]
RE: The display:* tag library
See comments in line: -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 11:07 AM To: Struts Users Mailing List Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. +1 - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. +1 - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. +1 - The display2:column should allow optional body content. If present its output is used in the table cell. +1 Any thoughts on this? What do you think of two tag libs: pager:* table:* The pager:* uses the base paging API where the table:* builds on the paging API to incorporate HTML generation to provide the widget. I think this would provide a more flexible library for those developers that want to use the paging functionality but whose design constraints are not met by the HTML generation functionality. robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: The display:* tag library
Good idea. Makes sense to me. -Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 11:50 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: The display:* tag library What do you think of two tag libs: pager:* table:* The pager:* uses the base paging API where the table:* builds on the paging API to incorporate HTML generation to provide the widget. I think this would provide a more flexible library for those developers that want to use the paging functionality but whose design constraints are not met by the HTML generation functionality. robert -- 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: The display:* tag library
I checked http://javawebifier.com/index.htm for examples of the taglib rewrite but it states there aren't any examples yet. Is there somewhere you can point to examples of the rewritten tags open to the public? Have you added features to incorporate titles from Struts MessageResources? I'm using this library and this is the one piece of functionality I was planning on adding but if it's already been done why reinvent the wheel. Thanks, -Original Message- From: Benjamin Simpson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:26 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: The display:* tag library I have started the rewrite/refactor. My src is available and is still in progress. The intent is to introduce an independent Table interface to be portable to other frameworks including a swing based JTable. Help yourself if it is helpful. If you would like my involvement I am interested. http://www.tablelib.com Ben Simpson [EMAIL PROTECTED] - Original Message - From: Jerome Jacobsen [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 11:07 AM Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: The display:* tag library +1 I've added support for Struts messages in column titles, glad to contribute it. Since I really depend on this library for a product I've developed, and need to fix some problems, make some additions, I'd be pleased to work with others on improving this great piece of code, perhaps be the pumpkin keeper if no one else will do it (although I'm reluctant to volunteer, as I haven't performed that role before, except as a gardner ;-) chaz -- Charles E Brault [EMAIL PROTECTED] Where are we going, and why am I in this handbasket? -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED
Re: The display:* tag library
Yes, I will have the examples up this evening (Ann Arbor Time). The linux server serving the website is a TwinHead SlimnoteEX266 with 32 mgs of ram. I ordered more ram from crucial to run the example pages. After installing the ram, I will put up the example pages generated by the javawebifier. I would really enjoy a collaboration with other interested parties. As far as integration with struts goes, the design I had in mind is to create a base implementation of a TableTag that uses a general implementation of the Table interface (TableImpl). The tablelib:library would be extendable to other specific frameworks ie Struts by implementing a StrutsTableImpl behind the tags getTable() method. Examples up tonight, happy to work with anyone interested in not over-complicating an html table. Ben Simpson - Original Message - From: Damm, Gary [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Benjamin Simpson [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 12:09 PM Subject: RE: The display:* tag library I checked http://javawebifier.com/index.htm for examples of the taglib rewrite but it states there aren't any examples yet. Is there somewhere you can point to examples of the rewritten tags open to the public? Have you added features to incorporate titles from Struts MessageResources? I'm using this library and this is the one piece of functionality I was planning on adding but if it's already been done why reinvent the wheel. Thanks, -Original Message- From: Benjamin Simpson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 8:26 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: The display:* tag library I have started the rewrite/refactor. My src is available and is still in progress. The intent is to introduce an independent Table interface to be portable to other frameworks including a swing based JTable. Help yourself if it is helpful. If you would like my involvement I am interested. http://www.tablelib.com Ben Simpson [EMAIL PROTECTED] - Original Message - From: Jerome Jacobsen [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 11:07 AM Subject: RE: The display:* tag library I think a complete rewrite is needed AND a new API (same tags but different tag attributes). Thus I would say an entirely new tag library. I'll call the new version display2 and the current one display1 for clarity below. - Follow JSTL conventions for attribute names and support JSTL-EL. (Actually make use of the JSTL Tag support classes). This means JSP 1.2 is baseline. Assuming JSTL-EL capable attributes allows us to make a simpler tag API. Less attributes are needed. For example we don't need the Struts-like bean-name and bean-property attributes. - Drop the sorting feature. The user can provide this functionality by making their column names links to actions which resort their list. Or their query form can have order by criteria. The display1 taglib only provides resort of contents in current page which I think is confusing to users if there are multiple pages. - The display2:table tag should work as an IterationTag. The display1 doesn't therefore you cannot access a scripting variable for the current row of the iteration. You are forced to use Decorators. This is non-standard as per Struts or JSTL. I vote for removing the Decorator functionality. - The display2:column should allow optional body content. If present its output is used in the table cell. A first stab at the API might look like this. Table - display2:table [var=varName] items=collection [varStatus=varStatusName] [begin=begin] [end=end] [step=step] [pageSize=pageSize] [pageUrl=pageUrl] [cssClassPrefix=cssClassPrefix] body content /display2:table Where var, items, varStatus, begin, end, and step have the same meaning as JSTL's c:forEach tag. And pageSize and pageUrl have same meaning as in display1 taglib. The display1 taglib generates HTML tags using CSS class names. You can't define what these names will be so in display2 the cssClassPrefix can be used to prefix the auto generated CSS names. A div tag around the entire table works too so maybe this attribute isn't necessary? Column -- display2:column title=title [value=value] body content /display2:column Title has the same meaning as in display1, except that it is mandatory. Value is optional, but must be present if there is no body content. The evaluation of value goes in the contents of the cell. The optional body content is used in the cell if there is no value attribute or if the value attribute results in null. That's a first stab and it probably is missing stuff. Maybe an escapeXml attribute should be added to both tags? Any thoughts on this? -Original Message- From: Charles Brault [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 10:09 AM
The display:* tag library
Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The display:* tag library
+1 It's a nice library. Vic Matt Raible wrote: Below is a proposal I posted on my website tonight (http://tinyurl.com/4s3j): If you need a slick JSP Tag Library for sorting and paging data, the display tag library is a great library to use. However, it's got issues - just like any piece of software. I've fixed a couple on my own, but it definitely needs some work - and integration with Struts (i.e. for getting messages, or referencing forwards) would be awesome. The problem is that Ed Hill doesn't seem to be working on it anymore - and there hasn't been a release since May 2002! Since I do have the source it wouldn't be hard to create a project at SourceForge for it. It would be great to get some input from Ed though. Last year, I think he even did a presentation on JSP Taglibs at Java One! I know there's lots of Struts developers that use the display tag - are any of you interested in continuing development on this project? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Problem with Struts and display tag library
Hello I'm using the library from http://edhill.its.uiowa.edu/display-0.8/ in a Struts application. I would like to use the sorting features of this library instead of doing it myself in the data access portion of my app. When I use the sort=true on a column, the URL that comes back is the JSP page itself instead of the whatever.do that I used to request the page. I've got all of my JSP's in the WEB-INF directory and put data in the request scope in the actions, so that definitely won't work. I've tried putting the requestURI attribute on the tag, but request.getRequestURI returns the path of the jsp, not the url I used to access the page. Any ideas? dave -- Dave Weis I believe there are more instances of the abridgment [EMAIL PROTECTED] of the freedom of the people by gradual and silent encroachments of those in power than by violent and sudden usurpations.- James Madison -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Display tag library/font size in tables?
-Original Message- From: Dave Hodson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 8:36 PM To: Struts Users Mailing List Subject: Display tag library/font size in tables? I'm using the display tag library (cool thing) and would like to change the font size of the output. As far as I can tell, the taglib doesn't support anything like the font tag and wrapping font around the display:column tag does nothing (it is ignored). Example display:table width=85% name=logsList scope=session pagesize=15 requestURI=http://localhost:8080/something.jsp; display:column property=createDate title=Date/Time width=15%/ /display:table What are my options? I'd like to produce output like the snippet below: td width=15%font face=Verdana, helvetica color=#003366 size=1strongDate/Time/strong/font/td Maybe I'm missing the point, but isn't this something that should be handled by your CSS? Dave --- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] www.messagecast.net /mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Display Tag Library
I'm doing the same exact thing right now. It took some doing to figure out how to make it work. But anyway, I have an EntryHolder class in the session that stores a few ArrayLists of entries. It also stores a String[] of the entry numbers to delete. The following code gets the selected index numbers and stores them in that deletion array. When the form is submitted, the user is taken to a confirmation page. When the user clicks the confirmation link, the action calls a method on the EntryHolder class that simply tells it to delete the selected entries, which is simple to do. The code in my JSP includes the following: html:form action=/EditEntry.do?action=confirmtype=md table border=0 tbody align=left logic:iterate id=md name=entries property=mdEntries type=com.moog.us.eos.beans.MDentry indexId=index tr td html:checkbox name=entries property=selections value=%=index.toString()%/ /td td bean:write name=md property=label/ /td /tr /logic:iterate /tbody /table html:submit value=Delete Selected Entries/ /html:form My solution may be somewhat unconventional, but I think it works great. I'm not sure how applicable this design is to what you're doing, but it sounds like you're trying to do the same thing. However, if you're using the Display Tag Lib and displaying info column by column, you'll just have to make some changes in the JSP. Should be pretty simple though. I hope this helps. ~ Keith http://www.buffalo.edu/~kkamholz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 4:39 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Display Tag Library You mentioned that you had a bunch of features You dont happen to have one that works with the multicheckbox control? I want to add a delete checkbox to each row... -Original Message- From: lists [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 04, 2002 12:29 AM To: struts-user Subject: RE: Wow - Continued... -Original Message- From: [EMAIL PROTECTED] --- The Display Tag library ( http://edhill.its.uiowa.edu/display/ ) This was the best one I could find for it, although the documentation is somewhat lacking and required some source diving to learn that I could do grouping and such. It supports Dynabeans and does all kinds of nice looking things... I could go into it all now, but if you go to the web site its all already described. Ed had a BOF at JavaOne this year to sort of show how he came up with that tag lib and how it works. It's very straightforward, easy to use, and easy to modify. I've already added a bunch of features that I'm going to submit back to him, and they all were extremely easy to implement. If anybody has a table tag they are in love with that seems like it's better than this, I'd love to hear about it! Joe -- 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]
Re: Display Tag Library
Subject: Re: Display Tag Library
From: Matt Raible [EMAIL PROTECTED]
===
You can do this with a decorator. I created my own ListWrapper.java
decorator class:
snip
public class ListWrapper extends TableDecorator {
/**
* Creates a new Wrapper decorator who's job is to reformat some of the
* data located in our forms.
*/
public ListWrapper() {
super();
}
/**
* Returns an xhtml-compliant checkbox used to select multiple rows
*/
public String getAssetBox() {
AssetForm form = (AssetForm) this.getObject();
String assetId = form.getAssetId();
return input type=\checkbox\ name=\rowId\ value=\
+ assetId
+ \ /;
}
}
/snip
In my assetList.jsp:
bean:struts id=searchURL forward=searchAsset/
html:form action=/assetEdit styleId=assetForm
display:table name=assetResults scope=request
requestURI=%=request.getContextPath() + searchURL.getPath()%
pagesize='%=(String)session.getAttribute(pageSize)%'
decorator=com.raibledesigns.webapp.taglib.ListWrapper
display:column property=assetBox width=3%
title=input type=\checkbox\ name=\allbox\
onclick=\checkAll(document.forms[0])\/
... continue rest of columns
And the checkAll javascript function:
function checkAll(theForm) { // check all the checkboxes in the list
for (var i=0;itheForm.elements.length;i++) {
var e = theForm.elements[i];
var eName = e.name;
if (eName != 'allbox'
(e.type.indexOf(checkbox) == 0)) {
e.checked = theForm.allbox.checked;
}
}
}
HTH,
Matt
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
You mentioned that you had a bunch of features You dont happen to
have one that works with the multicheckbox control? I want to add a
delete checkbox to each row...
-Original Message-
From: lists [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 04, 2002 12:29 AM
To: struts-user
Subject: RE: Wow - Continued...
-Original Message-
From: [EMAIL PROTECTED]
---
The Display Tag library ( http://edhill.its.uiowa.edu/display/ )
This was the best one I could find for it, although the documentation
is
somewhat lacking and required some source diving to learn that I could
do grouping and such. It supports Dynabeans and does all kinds of
nice
looking things... I could go into it all now, but if you go to the
web
site its all already described.
Ed had a BOF at JavaOne this year to sort of show how he came up with
that
tag lib and how it works. It's very straightforward, easy to use, and
easy
to modify. I've already added a bunch of features that I'm going to
submit
back to him, and they all were extremely easy to implement. If anybody
has a
table tag they are in love with that seems like it's better than this,
I'd
love to hear about it!
Joe
--
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]
