You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2005/04/11 20:06:26 UTC
Proposed improvement to x:dataTable
We're trying to use x:dataTable in a project for work right now.
There are a few limitations that I would like to address with the
group's approval.
The main problem we're having is that you cannot have an open-ended
list of columns in your data. Specifically, in our application we
have a feature where user's can build their own SQL queries and
generate custom reports. We display the reports in a table now but we
don' t have the sort or page functionality of x:dataTable. We can't
use x:dataTable as is b/c we don't know how many columns there are in
advance (or what name to give the header.)
I'd like to add a few additional attributes to x:dataTable that would
allow you to specify value binding expressions for determining the
names of the column headers along with which facet to use for which
column type. Everything would work as before so this is just extra
functionality. If there aren't any objections I would like to add the
functionality and a simple example for people to look at. If there
are problems with it (or improvements) then we can back out the
changes or make further changes. I think the idea is easier to
explain with actual code.
Please let me know if you have a problem with this approach.
sean
Re: Proposed improvement to x:dataTable
Posted by Sean Schofield <se...@gmail.com>.
I'll try and get an example to you shortly. BTW I thought of an
additional drawback to the approach you suggested. Suppose you have
fifteen columns that you need to render but you need to render them
the same for each column.
This is the opposite of my earlier example where you need to
customize.each/some of the columns appearance. The drawback is that
you have to add fifteen new children to the table where one would have
suffice.
I think the EG had it right when they made it so there is one
component per column so you don't actually need a component instance
for every "cell" in your table. I'm just suggesting that we take this
one step further.
sean
On Apr 11, 2005 2:56 PM, Heath Borders <he...@gmail.com> wrote:
> But I thought that you were proposing changing the component (and I'm
> guessing the Tag as well), and I'm just wondering if you could provide an
> example of your changes in a JSP form.
>
>
>
> On Apr 11, 2005 1:48 PM, Sean Schofield <se...@gmail.com> wrote:
> > I didn't say that that this functionality *had* to reside in the JSP.
> > My point is that if you want to render different types of data
> > differently then your idea breaks down a bit b/c its cumbersome to add
> > commandLinks, outputText, etc. programatically when you could just do
> > it in the JSP.
> >
> > An example would be a field for document number. That is one possible
> > field our users might want to select in their query. We'd like to
> > make that field a hyperlink in the report so that the user can jump
> > right to the document in question. So whenever this field is present
> > then we use different JSP than the default.
> >
> > sean
> >
> >
> > On Apr 11, 2005 2:37 PM, Heath Borders <he...@gmail.com> wrote:
> > > Yes, we basically just did it programmatically inside our bean. I agree
> > > with you that rendering rules should be separate from the application
> logic,
> > > but that doesn't mean it HAS to reside in the JSP.
> > >
> > > Could you maybe give a JSP example?
> > >
> > >
> > >
> > > On Apr 11, 2005 1:28 PM, Sean Schofield <se...@gmail.com>
> wrote:
> > > > How would this work exactly? Would the backing bean add column
> > > > children to the data table as needed? I suppose that could work but
> > > > it seems like a roundabout way of doing it. Plus what if I want to
> > > > render the data differently in the columns depending on their type
> > > > (similar to tree2?) That render information really belongs in JSP not
> > > > in the backing bean.
> > > >
> > > > BTW, this would be different than tree2 b/c there would be *no*
> > > > interface required for the data. You would just provide the names of
> > > > the methods to call on the data to get the information. Presumably
> > > > you would use an interface in the actual application that uses it but
> > > > there would be no such requirement to make the new functionality work.
> > > >
> > > > sean
> > > >
> > > >
> > > > On Apr 11, 2005 2:22 PM, Heath Borders <he...@gmail.com>
> wrote:
> > > > > What is wrong with doing a component-binding and setting this stuff
> up
> > > in
> > > > > your bean?
> > > > >
> > > > > We've had a few cases where the datatable's columns cannot be
> defined
> > > inside
> > > > > the JSP and this has worked just fine for us.
> > > > >
> > > > >
> > > > >
> > > > > On Apr 11, 2005 1:06 PM, Sean Schofield <se...@gmail.com>
> > > wrote:
> > > > > > We're trying to use x:dataTable in a project for work right now.
> > > > > > There are a few limitations that I would like to address with the
> > > > > > group's approval.
> > > > > >
> > > > > > The main problem we're having is that you cannot have an
> open-ended
> > > > > > list of columns in your data. Specifically, in our application we
> > > > > > have a feature where user's can build their own SQL queries and
> > > > > > generate custom reports. We display the reports in a table now
> but we
> > > > > > don' t have the sort or page functionality of x:dataTable. We
> can't
> > > > > > use x:dataTable as is b/c we don't know how many columns there are
> in
> > > > > > advance (or what name to give the header.)
> > > > > >
> > > > > > I'd like to add a few additional attributes to x:dataTable that
> would
> > > > > > allow you to specify value binding expressions for determining the
> > > > > > names of the column headers along with which facet to use for
> which
> > > > > > column type. Everything would work as before so this is just
> extra
> > > > > > functionality. If there aren't any objections I would like to add
> the
> > > > > > functionality and a simple example for people to look at. If
> there
> > > > > > are problems with it (or improvements) then we can back out the
> > > > > > changes or make further changes. I think the idea is easier to
> > > > > > explain with actual code.
> > > > > >
> > > > > > Please let me know if you have a problem with this approach.
> > > > > >
> > > > > > sean
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -Heath Borders-Wing
> > > > > hborders@mail.win.org
> > > >
> > >
> > >
> > >
> > > --
> > > -Heath Borders-Wing
> > > hborders@mail.win.org
> >
>
>
>
> --
>
> -Heath Borders-Wing
> hborders@mail.win.org
Re: Proposed improvement to x:dataTable
Posted by Heath Borders <he...@gmail.com>.
But I thought that you were proposing changing the component (and I'm
guessing the Tag as well), and I'm just wondering if you could provide an
example of your changes in a JSP form.
On Apr 11, 2005 1:48 PM, Sean Schofield <se...@gmail.com> wrote:
>
> I didn't say that that this functionality *had* to reside in the JSP.
> My point is that if you want to render different types of data
> differently then your idea breaks down a bit b/c its cumbersome to add
> commandLinks, outputText, etc. programatically when you could just do
> it in the JSP.
>
> An example would be a field for document number. That is one possible
> field our users might want to select in their query. We'd like to
> make that field a hyperlink in the report so that the user can jump
> right to the document in question. So whenever this field is present
> then we use different JSP than the default.
>
> sean
>
>
> On Apr 11, 2005 2:37 PM, Heath Borders <he...@gmail.com> wrote:
> > Yes, we basically just did it programmatically inside our bean. I agree
> > with you that rendering rules should be separate from the application
> logic,
> > but that doesn't mean it HAS to reside in the JSP.
> >
> > Could you maybe give a JSP example?
> >
> >
> >
> > On Apr 11, 2005 1:28 PM, Sean Schofield <se...@gmail.com>
> wrote:
> > > How would this work exactly? Would the backing bean add column
> > > children to the data table as needed? I suppose that could work but
> > > it seems like a roundabout way of doing it. Plus what if I want to
> > > render the data differently in the columns depending on their type
> > > (similar to tree2?) That render information really belongs in JSP not
> > > in the backing bean.
> > >
> > > BTW, this would be different than tree2 b/c there would be *no*
> > > interface required for the data. You would just provide the names of
> > > the methods to call on the data to get the information. Presumably
> > > you would use an interface in the actual application that uses it but
> > > there would be no such requirement to make the new functionality work.
> > >
> > > sean
> > >
> > >
> > > On Apr 11, 2005 2:22 PM, Heath Borders <he...@gmail.com>
> wrote:
> > > > What is wrong with doing a component-binding and setting this stuff
> up
> > in
> > > > your bean?
> > > >
> > > > We've had a few cases where the datatable's columns cannot be
> defined
> > inside
> > > > the JSP and this has worked just fine for us.
> > > >
> > > >
> > > >
> > > > On Apr 11, 2005 1:06 PM, Sean Schofield <se...@gmail.com>
> > wrote:
> > > > > We're trying to use x:dataTable in a project for work right now.
> > > > > There are a few limitations that I would like to address with the
> > > > > group's approval.
> > > > >
> > > > > The main problem we're having is that you cannot have an
> open-ended
> > > > > list of columns in your data. Specifically, in our application we
> > > > > have a feature where user's can build their own SQL queries and
> > > > > generate custom reports. We display the reports in a table now but
> we
> > > > > don' t have the sort or page functionality of x:dataTable. We
> can't
> > > > > use x:dataTable as is b/c we don't know how many columns there are
> in
> > > > > advance (or what name to give the header.)
> > > > >
> > > > > I'd like to add a few additional attributes to x:dataTable that
> would
> > > > > allow you to specify value binding expressions for determining the
> > > > > names of the column headers along with which facet to use for
> which
> > > > > column type. Everything would work as before so this is just extra
> > > > > functionality. If there aren't any objections I would like to add
> the
> > > > > functionality and a simple example for people to look at. If there
> > > > > are problems with it (or improvements) then we can back out the
> > > > > changes or make further changes. I think the idea is easier to
> > > > > explain with actual code.
> > > > >
> > > > > Please let me know if you have a problem with this approach.
> > > > >
> > > > > sean
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > -Heath Borders-Wing
> > > > hborders@mail.win.org
> > >
> >
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Proposed improvement to x:dataTable
Posted by Sean Schofield <se...@gmail.com>.
I didn't say that that this functionality *had* to reside in the JSP.
My point is that if you want to render different types of data
differently then your idea breaks down a bit b/c its cumbersome to add
commandLinks, outputText, etc. programatically when you could just do
it in the JSP.
An example would be a field for document number. That is one possible
field our users might want to select in their query. We'd like to
make that field a hyperlink in the report so that the user can jump
right to the document in question. So whenever this field is present
then we use different JSP than the default.
sean
On Apr 11, 2005 2:37 PM, Heath Borders <he...@gmail.com> wrote:
> Yes, we basically just did it programmatically inside our bean. I agree
> with you that rendering rules should be separate from the application logic,
> but that doesn't mean it HAS to reside in the JSP.
>
> Could you maybe give a JSP example?
>
>
>
> On Apr 11, 2005 1:28 PM, Sean Schofield <se...@gmail.com> wrote:
> > How would this work exactly? Would the backing bean add column
> > children to the data table as needed? I suppose that could work but
> > it seems like a roundabout way of doing it. Plus what if I want to
> > render the data differently in the columns depending on their type
> > (similar to tree2?) That render information really belongs in JSP not
> > in the backing bean.
> >
> > BTW, this would be different than tree2 b/c there would be *no*
> > interface required for the data. You would just provide the names of
> > the methods to call on the data to get the information. Presumably
> > you would use an interface in the actual application that uses it but
> > there would be no such requirement to make the new functionality work.
> >
> > sean
> >
> >
> > On Apr 11, 2005 2:22 PM, Heath Borders <he...@gmail.com> wrote:
> > > What is wrong with doing a component-binding and setting this stuff up
> in
> > > your bean?
> > >
> > > We've had a few cases where the datatable's columns cannot be defined
> inside
> > > the JSP and this has worked just fine for us.
> > >
> > >
> > >
> > > On Apr 11, 2005 1:06 PM, Sean Schofield <se...@gmail.com>
> wrote:
> > > > We're trying to use x:dataTable in a project for work right now.
> > > > There are a few limitations that I would like to address with the
> > > > group's approval.
> > > >
> > > > The main problem we're having is that you cannot have an open-ended
> > > > list of columns in your data. Specifically, in our application we
> > > > have a feature where user's can build their own SQL queries and
> > > > generate custom reports. We display the reports in a table now but we
> > > > don' t have the sort or page functionality of x:dataTable. We can't
> > > > use x:dataTable as is b/c we don't know how many columns there are in
> > > > advance (or what name to give the header.)
> > > >
> > > > I'd like to add a few additional attributes to x:dataTable that would
> > > > allow you to specify value binding expressions for determining the
> > > > names of the column headers along with which facet to use for which
> > > > column type. Everything would work as before so this is just extra
> > > > functionality. If there aren't any objections I would like to add the
> > > > functionality and a simple example for people to look at. If there
> > > > are problems with it (or improvements) then we can back out the
> > > > changes or make further changes. I think the idea is easier to
> > > > explain with actual code.
> > > >
> > > > Please let me know if you have a problem with this approach.
> > > >
> > > > sean
> > > >
> > >
> > >
> > >
> > > --
> > > -Heath Borders-Wing
> > > hborders@mail.win.org
> >
>
>
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
Re: Proposed improvement to x:dataTable
Posted by Heath Borders <he...@gmail.com>.
Yes, we basically just did it programmatically inside our bean. I agree with
you that rendering rules should be separate from the application logic, but
that doesn't mean it HAS to reside in the JSP.
Could you maybe give a JSP example?
On Apr 11, 2005 1:28 PM, Sean Schofield <se...@gmail.com> wrote:
>
> How would this work exactly? Would the backing bean add column
> children to the data table as needed? I suppose that could work but
> it seems like a roundabout way of doing it. Plus what if I want to
> render the data differently in the columns depending on their type
> (similar to tree2?) That render information really belongs in JSP not
> in the backing bean.
>
> BTW, this would be different than tree2 b/c there would be *no*
> interface required for the data. You would just provide the names of
> the methods to call on the data to get the information. Presumably
> you would use an interface in the actual application that uses it but
> there would be no such requirement to make the new functionality work.
>
> sean
>
>
> On Apr 11, 2005 2:22 PM, Heath Borders <he...@gmail.com> wrote:
> > What is wrong with doing a component-binding and setting this stuff up
> in
> > your bean?
> >
> > We've had a few cases where the datatable's columns cannot be defined
> inside
> > the JSP and this has worked just fine for us.
> >
> >
> >
> > On Apr 11, 2005 1:06 PM, Sean Schofield <se...@gmail.com>
> wrote:
> > > We're trying to use x:dataTable in a project for work right now.
> > > There are a few limitations that I would like to address with the
> > > group's approval.
> > >
> > > The main problem we're having is that you cannot have an open-ended
> > > list of columns in your data. Specifically, in our application we
> > > have a feature where user's can build their own SQL queries and
> > > generate custom reports. We display the reports in a table now but we
> > > don' t have the sort or page functionality of x:dataTable. We can't
> > > use x:dataTable as is b/c we don't know how many columns there are in
> > > advance (or what name to give the header.)
> > >
> > > I'd like to add a few additional attributes to x:dataTable that would
> > > allow you to specify value binding expressions for determining the
> > > names of the column headers along with which facet to use for which
> > > column type. Everything would work as before so this is just extra
> > > functionality. If there aren't any objections I would like to add the
> > > functionality and a simple example for people to look at. If there
> > > are problems with it (or improvements) then we can back out the
> > > changes or make further changes. I think the idea is easier to
> > > explain with actual code.
> > >
> > > Please let me know if you have a problem with this approach.
> > >
> > > sean
> > >
> >
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Proposed improvement to x:dataTable
Posted by Sean Schofield <se...@gmail.com>.
How would this work exactly? Would the backing bean add column
children to the data table as needed? I suppose that could work but
it seems like a roundabout way of doing it. Plus what if I want to
render the data differently in the columns depending on their type
(similar to tree2?) That render information really belongs in JSP not
in the backing bean.
BTW, this would be different than tree2 b/c there would be *no*
interface required for the data. You would just provide the names of
the methods to call on the data to get the information. Presumably
you would use an interface in the actual application that uses it but
there would be no such requirement to make the new functionality work.
sean
On Apr 11, 2005 2:22 PM, Heath Borders <he...@gmail.com> wrote:
> What is wrong with doing a component-binding and setting this stuff up in
> your bean?
>
> We've had a few cases where the datatable's columns cannot be defined inside
> the JSP and this has worked just fine for us.
>
>
>
> On Apr 11, 2005 1:06 PM, Sean Schofield <se...@gmail.com> wrote:
> > We're trying to use x:dataTable in a project for work right now.
> > There are a few limitations that I would like to address with the
> > group's approval.
> >
> > The main problem we're having is that you cannot have an open-ended
> > list of columns in your data. Specifically, in our application we
> > have a feature where user's can build their own SQL queries and
> > generate custom reports. We display the reports in a table now but we
> > don' t have the sort or page functionality of x:dataTable. We can't
> > use x:dataTable as is b/c we don't know how many columns there are in
> > advance (or what name to give the header.)
> >
> > I'd like to add a few additional attributes to x:dataTable that would
> > allow you to specify value binding expressions for determining the
> > names of the column headers along with which facet to use for which
> > column type. Everything would work as before so this is just extra
> > functionality. If there aren't any objections I would like to add the
> > functionality and a simple example for people to look at. If there
> > are problems with it (or improvements) then we can back out the
> > changes or make further changes. I think the idea is easier to
> > explain with actual code.
> >
> > Please let me know if you have a problem with this approach.
> >
> > sean
> >
>
>
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
Re: Proposed improvement to x:dataTable
Posted by Heath Borders <he...@gmail.com>.
What is wrong with doing a component-binding and setting this stuff up in
your bean?
We've had a few cases where the datatable's columns cannot be defined
inside the JSP and this has worked just fine for us.
On Apr 11, 2005 1:06 PM, Sean Schofield <se...@gmail.com> wrote:
>
> We're trying to use x:dataTable in a project for work right now.
> There are a few limitations that I would like to address with the
> group's approval.
>
> The main problem we're having is that you cannot have an open-ended
> list of columns in your data. Specifically, in our application we
> have a feature where user's can build their own SQL queries and
> generate custom reports. We display the reports in a table now but we
> don' t have the sort or page functionality of x:dataTable. We can't
> use x:dataTable as is b/c we don't know how many columns there are in
> advance (or what name to give the header.)
>
> I'd like to add a few additional attributes to x:dataTable that would
> allow you to specify value binding expressions for determining the
> names of the column headers along with which facet to use for which
> column type. Everything would work as before so this is just extra
> functionality. If there aren't any objections I would like to add the
> functionality and a simple example for people to look at. If there
> are problems with it (or improvements) then we can back out the
> changes or make further changes. I think the idea is easier to
> explain with actual code.
>
> Please let me know if you have a problem with this approach.
>
> sean
>
--
-Heath Borders-Wing
hborders@mail.win.org