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 <[EMAIL PROTECTED]> 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 <[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]
