> - Your data model, where columns can be marked disabled. Oops. The disabled marking would really be in your adaptor class, not in your raw data model. Stream of conciousness typing error.
On 1/17/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > Well, I'd base it on the Swing Table model rather than inventing this > all from scratch. > > You actually need two models: > - Your data model, where columns can be marked disabled. > - Your column view model, which only contains the columns in the > rendering order. > > So your data model has 1,2,3,4,5 and your column view model (which is > the backing model for t:columns) might contain 3,1,5. You'll > probably also want some view-to-model adaptor class that can get from > a column view model index to a data model index, and vice-versa. That > way you keep your data model pure from view abstractions, and the JSF > backing model is still in the format expected by dataTable. > > If you get all of this working, it'd be a great contribution to MyFaces. > > On 1/17/06, Andreas Zeller - zit-systems <[EMAIL PROTECTED]> wrote: > > My idea was as follows: > > > > Add a remove button like "-", arrows for moving columns from left to right > > all inside a panelgroup in the table header. > > > > Columns have IDs, that's how I identify them. For each ID there's a > > position. I store these values inside a Map<String,Integer>. > > > > When building the actual table Model, I store the values inside a List at > > specific positions... First of all, I have to fill the model with > > dummy-values so I can set specific positions, because a List doesn't like > > any value being set at index X, when it is empty. So I need to fill it up > > with some crap and remove the crap after building it. > > > > A more elegant way would of course be getting rid of the dummy values, but > > I don't see any elegant way to do this, because any "packing" method I was > > thinking about would screw up my model. For example: If I have 5 columns and > > I disable column #3. It should draw column 1, 2, 4, 5. Wouldn't be too bad > > if column #3 was appended when I put it back in, but I need to update the > > entire model including the stored data, instead of just having it "disabled" > > and leave the data inside the bean, where it belongs... > > > > See my problem? > > > > Andreas > > > > > > > > Mike Kienenberger wrote: > > On 1/17/06, Andreas Zeller - zit-systems <[EMAIL PROTECTED]> > > wrote: > > > > > > Thanks for the quick reply. I already tried that, unfortunately I just get > > empty columns, with not text at all, it doesn't actually remove the column. > > > > Yeah, you're right. That'd leave empty columns > > > > > > > > I'd be really glad if there were some kind of a straight forward example. > > > > Someone must have done something like this by now, hasn't anyone? > > > > I don't think so. It was considered pretty innovative to have the > > ability to have the number of columns be dynamic. I haven't heard of > > anyone trying to add or remove columns afterward yet. > > > > Changing the backing model for t:columns sounds like the way to go. > > You're going to have to work through whatever bugs that might entail > > though. At what point in the jsf lifecycle are you trying to change > > the column model? I'd say you can only change it in invoke > > application. Changing it before updateModel or after renderResponse > > is probably going to fail because other code depends on those column > > numbers remaining constant. > > > > > > > > > > >
