On Apr 11, 2005 1:48 PM, Sean Schofield <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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
> > > [EMAIL PROTECTED]
> >
>
>
>
> --
> -Heath Borders-Wing
> [EMAIL PROTECTED]
--
-Heath Borders-Wing
[EMAIL PROTECTED]
