Re: Color entire table view row
Re: Color entire table view row
- Subject: Re: Color entire table view row
- From: Michael Gersten <email@hidden>
- Date: Thu, 06 Jun 2002 12:53:33 -0700
[This is in response to a two month old posting. The original was talking about coloring a table row in an NSTable based on the data displayed in that row. This reply goes into a different area, about MVC and a limitation of it, so I'm going to put the focused response part first.]
[ The original poster wanted an easier way to put an attribute on a row at a time ]
>
> I said that it's
>
> such a tiny feature that anything more than ten minutes of writing code
>
> isn't worth it. _ANY_ developer in _ANY_ development environment can think
>
> of situations in which they can't justify spending an hour to do something
>
> to implement a feature so small almost nobody will ever see it.
>
>
Nope, neither can Apple...
Now hold on a second.
Alternating colors per row, or per group of three rows, is a COMMON, Long Standing way of doing things.
The idea of saying "Some attributes of this row are a property of the object being displayed in this row" is a basic concept of displaying a database _row_.
>
> Yes, some color information is stored, but this is neither editable by the
>
> user (the color of any particular string, "Error" being red, etc.) nor is it
>
> unecessarily embedded into the 'model.'
>
>
It would still be embedded into the controller. The model shouldn't have
>
table view data source methods.
[This part of the reply is more theory, code-organization type reply]
Just a quick observation, MVC is an incomplete view of things.
Clearly, you have a data model, that only provides answers to queries about the data, and updates the data.
Clearly, you have a view, that indicates where things go.
Clearly, you have an APP-Controller, that deals with app stuff.
And, the missing point is the view controller.
Model <--> App controller <--> View Controller <--> View
+----------------------------------+
Call it MCCV if you need a new acronym.
[Note that Model is really data + data controller, so that's DCCCV :-) ]
[This has gotten into two seperate topics now, so I've divided it into two posts. More on this in the other post.]
The concept of "This is an error" is in the data controller.
The concept of "Error = red, otherwise alternate grey and white" is in the view controller.
Whether the output is an NSTable or an HTML table is in the view.
Now, a revision, and a question: Is the table view data source in the data controller?
The data controller's job is to make data available.
Does key/value belong there? yes. That's a way to fetch one item at a time.
TableView data source is a way to fetch "all" data, one large piece (several items per row) at a time.
Why not make that in the data controller?
[I don't know the answer, this is just a question. The only thing that's clear is that it isn't in the app controller. Equally clearly, not all of TableViewDataSource can be in the model. The concept of "Error" may be ok. The concept of "Red text on black background" is a view-controller level item.]
Another two days, a better idea. View controller is really in two parts. There's an app specific part of the view controller: how a report generation program wants to deal with "error" data may not be the same as how a data entry program wants to deal with it. It may vary between what is used for internal audits/reports and what is used for government audits/reports.
And then there's the output/view side of the controller: How a cocoa-widget differs from how a swing-widget from how an html-widget displays the same concept.
>
> I said that it's
>
> such a tiny feature that anything more than ten minutes of writing code
>
> isn't worth it. _ANY_ developer in _ANY_ development environment can think
>
> of situations in which they can't justify spending an hour to do something
>
> to implement a feature so small almost nobody will ever see it.
>
>
Nope, neither can Apple...
Now hold on a second.
Alternating colors per row, or per group of three rows, is a COMMON, Long Standing way of doing things.
The idea of saying "Some attributes of this row are a property of the object being displayed in this row" is a basic concept of displaying a database _row_.
Almost nobody will ever see it? I'm sorry, I expect this to be a commonly used/wanted feature.
Additionally, the data controller might have something to say about it. It might want to say "These data items are grouped with that data item" so that the view controller can say "Make this header item bold, make this detail item one point smaller", or "Make this header item <B> <Font size=+1>, make the detail items normal." Or, if the app side of the view controller is different, put the header items in one table and only the details of the selected item in a second, editable table.
I haven't used table data sources myself -- generally, I only used them in conjunction with EOInterface or WOF (the HTML version of EOInterface). If I had, I'm sure I would have come across this myself earlier and raised exactly this issue.
>
Anyway, I'm sorry if I came across in a bad way. I really should have had a
>
winking smiley there :).
>
>
>> What kind of method are you expecting? A [yourCell setTextColor:col]? That
>
>> _is_ exactly what the attributed strings are there for.
How about tableView:defaultAttributesForRow:overrideCells:
Delegate method, of course.
That way, cells can have default info (such as fonts, colors (red for negative)), and a per-row item (background color, etc), as well as an override (grey text if uneditable).
Hmm, for completeness, we need more.
How about attributesForTableView:defaultAttributes:(**)overrideAttributes:(**):forRow:
where (**) represents an output argument.
That way, if a data is "Red text, black background, word 'Error'", but the row is "override grey background, default black text", things can work.
[ok, how about generalized priority levels for text attributes? That way you could, if you wanted, have a data item's attributes be so important that they are kept, even if the row thinks it's an override.]
So where does this view controller system really go?
What is a heading/detail is on the data level
How the headers and details are grouped is on the app level.
How a group is displayed is view level
Three different controllers, doing three different jobs.
Michael
--
I am a Mac 10-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.