two question about fasttable
Hi - Could we rename FastTable into Table? - Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers. Stef -- Using Opera's mail client: http://www.opera.com/mail/
- Then I miss an important design point. Why datasource returns Morph? Do you mean from #cellColumn:row: ? - I do not get why a data source should return UI element. To me it violates layers. The datasource is a wrapper/binding between the real object and the view (table/list) and provides the necessary stuff for display and interaction between them. Returning custom UI elements (cells and rows) from the datasource is part of what makes it possible to reuse the same table/container morph for lists/tables/trees. Best regards. Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Monday, November 28, 2016 9:32 PM To: pharo-dev@lists.pharo.org Subject: [Pharo-dev] two question about fasttable Hi - Could we rename FastTable into Table? - Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers. Stef -- Using Opera's mail client: http://www.opera.com/mail/
On 28 Nov 2016, at 22:25, Henrik Nergaard <henrik.nergaard@uia.no> wrote:
The datasource is a wrapper/binding between the real object and the view (table/list) and provides the necessary stuff for display and interaction between them. Returning custom UI elements (cells and rows) from the datasource is part of what makes it possible to reuse the same table/container morph for lists/tables/trees.
this ^ :) Esteban
Ok so I never understand it that way. What a bad name. Stef
On 28 Nov 2016, at 22:25, Henrik Nergaard <henrik.nergaard@uia.no> wrote:
The datasource is a wrapper/binding between the real object and the view (table/list) and provides the necessary stuff for >>display and interaction between them. Returning custom UI elements (cells and rows) from the datasource is part of what >>makes it possible to reuse the same table/container morph for lists/tables/trees.
this ^ :)
Esteban
-- Using Opera's mail client: http://www.opera.com/mail/
Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells. I got inspired for Cocoa NSTableView design (and NSTableViewDataSource), and thatâs what it does. See for example here: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/T... <https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/T...> This function: - (NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row is the equivalent of our FTDataSource>>cellColumn:row: Esteban
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph?
I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ? cheers -ben
On 29 Nov 2016, at 00:00, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ?
Iâm not against changing its name, in general the family of names are âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because there are too generic⦠sometimes is that what you have :P) But is not just a âcell providerâ, it does something more, is a general model of the TableMorph: it provides cells, headers and interaction capabilities (like drag&drop)⦠so it is more like a "table data providerâ, TableDataSource, TableStore, TableProvider are then better names, IMO⦠this changes will impact Pharo 7⦠is very good that we can have a discussion like this now, that we have the time to reach a consensus :) Esteban
cheers -ben
Hi,
Le 29 nov. 2016 à 08:45, Esteban Lorenzano <estebanlm@gmail.com> a écrit :
On 29 Nov 2016, at 00:00, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ?
Iâm not against changing its name, in general the family of names are âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because there are too generic⦠sometimes is that what you have :P) But is not just a âcell providerâ, it does something more, is a general model of the TableMorph: it provides cells, headers and interaction capabilities (like drag&drop)⦠so it is more like a "table data providerâ, TableDataSource, TableStore, TableProvider are then better names, IMOâ¦
this changes will impact Pharo 7⦠is very good that we can have a discussion like this now, that we have the time to reach a consensus :)
To me, the name datasource is misleading in this case. I would expect to find an abstraction that takes data from a database, or a file or in-memory object, etc. yes, something like TableCellSource or TableCellProvider is more intention revealing. Christophe
On 29 Nov 2016, at 09:11, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Hi,
Le 29 nov. 2016 à 08:45, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> a écrit :
On 29 Nov 2016, at 00:00, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ?
Iâm not against changing its name, in general the family of names are âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because there are too generic⦠sometimes is that what you have :P) But is not just a âcell providerâ, it does something more, is a general model of the TableMorph: it provides cells, headers and interaction capabilities (like drag&drop)⦠so it is more like a "table data providerâ, TableDataSource, TableStore, TableProvider are then better names, IMOâ¦
this changes will impact Pharo 7⦠is very good that we can have a discussion like this now, that we have the time to reach a consensus :)
To me, the name datasource is misleading in this case. I would expect to find an abstraction that takes data from a database, or a file or in-memory object, etc.
yeah, but is a common use too⦠just youâre too DB shaped ;)
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes. I kind of like âTableStoreâ. Also we have other stores in image: FileSystem stores⦠which conceptually do more or less the same⦠so better to unify concepts/names⦠what do you think? Esteban
Christophe
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
"DataSource" is responsible for providing visual elements that represent items in a data set. I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself. An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows: f: Object -> Morph . You see, it is a *mapping, not a souse or store.* Cheers, Alex On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
Sorry not souse, but a source :D On 29 November 2016 at 09:58, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
"DataSource" is responsible for providing visual elements that represent items in a data set.
I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself. An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows: f: Object -> Morph . You see, it is a *mapping, not a souse or store.*
Cheers, Alex
On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
On 29 Nov 2016, at 09:58, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
"DataSource" is responsible for providing visual elements that represent items in a data set.
I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself. An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows: f: Object -> Morph . You see, it is a mapping, not a souse or store.
Store != Storage. A store is a place where you go to get stuff (same as FileSystem stores: they give you access to different filesystems, as a FTDataSource gives you access to different data structures) :) In Gtk3, you have GtkListView, and GtkListStore, for example. And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstableviewdatasource <https://developer.apple.com/reference/appkit/nstableviewdatasource> So⦠I still rest my argument. Anyway⦠we will NEVER reach a 100% agreement. We just need to go with what fits better current design/general idea. Esteban
Cheers, Alex
On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
2016-11-29 10:14 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 29 Nov 2016, at 09:58, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
"DataSource" is responsible for providing visual elements that represent items in a data set.
I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself. An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows: f: Object -> Morph . You see, it is a *mapping, not a souse or store.*
Store != Storage. A store is a place where you go to get stuff (same as FileSystem stores: they give you access to different filesystems, as a FTDataSource gives you access to different data structures) :) In Gtk3, you have GtkListView, and GtkListStore, for example. And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstableviewdatasource
So⦠I still rest my argument.
Anyway⦠we will NEVER reach a 100% agreement. We just need to go with what fits better current design/general idea.
If you can't find the perfect meaning... just make sure there is no misunderstanding (i.e. DataSource is kind of confusing). Memorable can compensate for 'not exactly the right name'. I like the FastTable moniker because it convey some of the design intent. As I like the core principle. I don't like the overall design; it has a lot of the PluggableTreeMorph caracteristics, such as being a single widget trying to do everything with an API that's dozens of pages long... And we know what will be the community opinion on such widgets 10 years down the line. It's fitting that it has a lot to relate with GTK / Cocoa designs. Places where people design huge objects because they live in a 'each function is 20 to fifty lines long' world and don't understand what fine grained objects / a live environment can be. Thierry
Esteban
Cheers, Alex
On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
On 29 Nov 2016, at 10:36, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-11-29 10:14 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
On 29 Nov 2016, at 09:58, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote:
"DataSource" is responsible for providing visual elements that represent items in a data set.
I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself. An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows: f: Object -> Morph . You see, it is a mapping, not a souse or store.
Store != Storage. A store is a place where you go to get stuff (same as FileSystem stores: they give you access to different filesystems, as a FTDataSource gives you access to different data structures) :) In Gtk3, you have GtkListView, and GtkListStore, for example. And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstableviewdatasource <https://developer.apple.com/reference/appkit/nstableviewdatasource>
So⦠I still rest my argument.
Anyway⦠we will NEVER reach a 100% agreement. We just need to go with what fits better current design/general idea.
If you can't find the perfect meaning... just make sure there is no misunderstanding (i.e. DataSource is kind of confusing). Memorable can compensate for 'not exactly the right name'.
I like the FastTable moniker because it convey some of the design intent. As I like the core principle.
I don't like the overall design; it has a lot of the PluggableTreeMorph caracteristics, such as being a single widget trying to do everything with an API that's dozens of pages long... And we know what will be the community opinion on such widgets 10 years down the line.
It's fitting that it has a lot to relate with GTK / Cocoa designs. Places where people design huge objects because they live in a 'each function is 20 to fifty lines long' world and don't understand what fine grained objects / a live environment can be.
widgets are huge objects by definition (specially a table⦠or a text editor). but well, you can propose a refactor⦠Pharo 7 will be the good moment for it :) Esteban
Thierry
Esteban
Cheers, Alex
On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
2016-11-29 11:07 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 29 Nov 2016, at 10:36, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-11-29 10:14 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 29 Nov 2016, at 09:58, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
"DataSource" is responsible for providing visual elements that represent items in a data set.
I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself. An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows: f: Object -> Morph . You see, it is a *mapping, not a souse or store.*
Store != Storage. A store is a place where you go to get stuff (same as FileSystem stores: they give you access to different filesystems, as a FTDataSource gives you access to different data structures) :) In Gtk3, you have GtkListView, and GtkListStore, for example. And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstable viewdatasource
So⦠I still rest my argument.
Anyway⦠we will NEVER reach a 100% agreement. We just need to go with what fits better current design/general idea.
If you can't find the perfect meaning... just make sure there is no misunderstanding (i.e. DataSource is kind of confusing). Memorable can compensate for 'not exactly the right name'.
I like the FastTable moniker because it convey some of the design intent. As I like the core principle.
I don't like the overall design; it has a lot of the PluggableTreeMorph caracteristics, such as being a single widget trying to do everything with an API that's dozens of pages long... And we know what will be the community opinion on such widgets 10 years down the line.
It's fitting that it has a lot to relate with GTK / Cocoa designs. Places where people design huge objects because they live in a 'each function is 20 to fifty lines long' world and don't understand what fine grained objects / a live environment can be.
widgets are huge objects by definition (specially a table⦠or a text editor).
It would be really great to make them a bit more composable / modular...
but well, you can propose a refactor⦠Pharo 7 will be the good moment for it :)
Ah, if only I had the time... Thierry
Esteban
Thierry
Esteban
Cheers, Alex
On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
On 29 November 2016 at 10:14, Esteban Lorenzano <estebanlm@gmail.com> wrote:
And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstableviewdatasource
I know :) However, implementation of FastTable does not correspond to Cocoa design. A table view does not store its own data; it retrieves *data values* as
needed *from a data source* to which it has a weak reference
https://developer.apple.com/reference/appkit/nstableview This is where misconception begins. In Cocoa data source acts as real data source, it returns Object, not Morph! At the same time DataSource in FastTable returns Morphs. Naming in Cocoa is correct and I am not arguing about it :) DataSource in FastTable != DataSource in Cocoa. Cheers, Alex
On 29 Nov 2016, at 10:37, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
On 29 November 2016 at 10:14, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstableviewdatasource <https://developer.apple.com/reference/appkit/nstableviewdatasource>
I know :) However, implementation of FastTable does not correspond to Cocoa design.
A table view does not store its own data; it retrieves data values as needed from a data source to which it has a weak reference https://developer.apple.com/reference/appkit/nstableview <https://developer.apple.com/reference/appkit/nstableview> This is where misconception begins. In Cocoa data source acts as real data source, it returns Object, not Morph! At the same time DataSource in FastTable returns Morphs.
not true. it returns an NSView. Esteban
Naming in Cocoa is correct and I am not arguing about it :) DataSource in FastTable != DataSource in Cocoa.
Cheers, Alex
On 29 November 2016 at 10:39, Esteban Lorenzano <estebanlm@gmail.com> wrote:
not true. it returns an NSView.
Could you name a method (send a link to a documentation) that is implemented by DataSource and returns an NSView? According to documentation NSView for an item at row/column index is created and returned by NSTableView: https://developer.apple.com/reference/appkit/nstableview/1528831-view I didn't find any NSView related method in DataSource. Am I looking in a wrong place? Cheers, Alex
Called by the table view to return the data object associated with the specified row and column.
https://developer.apple.com/reference/appkit/nstableviewdatasource/1533674-t... Cheers, Alex On 29 November 2016 at 10:44, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
On 29 November 2016 at 10:39, Esteban Lorenzano <estebanlm@gmail.com> wrote:
not true. it returns an NSView.
Could you name a method (send a link to a documentation) that is implemented by DataSource and returns an NSView?
According to documentation NSView for an item at row/column index is created and returned by NSTableView: https://developer.apple.com/reference/appkit/nstableview/1528831-view
I didn't find any NSView related method in DataSource. Am I looking in a wrong place?
Cheers, Alex
On Tue, 29 Nov 2016 10:46:09 +0100, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Called by the table view to return the data object associated with the specified row and column. https://developer.apple.com/reference/appkit/nstableviewdatasource/1533674-t...
If dataSource does not return view then you are right for the name. Now in Pharo the name is wrong and may be the design too :)
Cheers, Alex
On 29 November 2016 at 10:44, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
On 29 November 2016 at 10:39, Esteban Lorenzano <estebanlm@gmail.com> wrote: not true.it returns an NSView.
Could you name a method (send a link to a documentation) that is implemented by DataSource and returns an NSView?
According to documentation NSView for an item at row/column index is created and returned by NSTableView: https://developer.apple.com/reference/appkit/nstableview/1528831-view
I didn't find any NSView related method in DataSource. Am I looking in a wrong place?
Cheers, Alex
-- Using Opera's mail client: http://www.opera.com/mail/
On Tue, 29 Nov 2016 09:58:41 +0100, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
"DataSource" is responsible for providing visual elements that represent items in a data set.
who said that. I could say exactly: DataSource is responsible to cut data so that they are delivered by row or columns.
I don't see how word "Store" fits here, because DataSource does not store anything.
Store in the sense of serving something.
DataSource is also not the best name since it is not a data source itself.
Clearly not
An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as >follows: f: Object -> Morph . You see, it is a mapping, not a souse or store.
Cheers, Alex
On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
yes, something like TableCellSource or TableCellProvider is more intention revealing.
No, because is not *just* a cell provider.TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.
And if we have TableMorph then this guy should be TableMorphStore IMO.
-- Using Opera's mail client: http://www.opera.com/mail/
No, because is not *just* a cell provider.TableDataSource, TableStore, TableProvider, yes.
I kind of like âTableStoreâ.Also we have other stores in image: FileSystem stores⦠which conceptually do more or less the same⦠so better to unify concepts/>names⦠what do you think?
TableMorphStore? Because I was really shocked to see that it returned Morph.
Esteban
Christophe
-- Using Opera's mail client: http://www.opera.com/mail/
Even if not really matching 100%, Java has the TableModel. https://docs.oracle.com/javase/7/docs/api/javax/swing/table/TableModel.html https://docs.oracle.com/javase/7/docs/api/javax/swing/table/DefaultTableMode... In the MVVM buzzword land, ViewModel seems all the rage. Some inspiration from Swift: https://github.com/tbergmen/TableViewModel Phil On Tue, Nov 29, 2016 at 8:45 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Nov 2016, at 00:00, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph?
I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ?
Iâm not against changing its name, in general the family of names are âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because there are too generic⦠sometimes is that what you have :P) But is not just a âcell providerâ, it does something more, is a general model of the TableMorph: it provides cells, headers and interaction capabilities (like drag&drop)⦠so it is more like a "table data providerâ, TableDataSource, TableStore, TableProvider are then better names, IMOâ¦
this changes will impact Pharo 7⦠is very good that we can have a discussion like this now, that we have the time to reach a consensus :)
Esteban
cheers -ben
On Tue, Nov 29, 2016 at 3:45 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Nov 2016, at 00:00, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph?
I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ?
Iâm not against changing its name, in general the family of names are âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because there are too generic⦠sometimes is that what you have :P) But is not just a âcell providerâ, it does something more, is a general model of the TableMorph: it provides cells, headers and interaction capabilities (like drag&drop)⦠so it is more like a "table data providerâ,
cool. I was only reflecting back your first description (and so I learnt something more about it)
TableDataSource, TableStore, TableProvider are then better names, IMOâ¦
/refers to thesaurus TableWidgetSource, TableComponentSource, TableElementSource, TablePartProvider, TableAspectProvider, TableFacetProvider cheers -ben
this changes will impact Pharo 7⦠is very good that we can have a discussion like this now, that we have the time to reach a consensus :)
Esteban
cheers -ben
- Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of >>>morphs).a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ?
Iâm not against changing its name, in general the family of names are âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I
tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because there are too generic⦠sometimes is that what you have :P) But is not just a âcell providerâ, it does something more, is a general model of the TableMorph: it provides cells, headers and interaction capabilities (like drag&drop)⦠so it is more like a "table data providerâ, TableDataSource, TableStore, TableProvider are then better names, IMOâ¦
Please please please. So I was always confused.
this changes will impact Pharo 7⦠is very good that we can have a discussion like this now, that we have the time to reach a consensus >:)
Esteban
cheers -ben
-- Using Opera's mail client: http://www.opera.com/mail/
On Mon, 28 Nov 2016 22:29:08 +0100, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs).a TableDataSource is not a spec, is the provider of cells.
What a ugly name then... Why this is not a CellMorphFactory or something like that.
I got inspired for Cocoa NSTableView design (and NSTableViewDataSource), and thatâs what it does.See for example here: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingView->TablesProgrammatically/PopulatingView-TablesProgrammatically.html This function: >- (NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row
is the equivalent of our FTDataSource>>cellColumn:row:
Esteban
Stef
--Using Opera's mail client: http://www.opera.com/mail/
-- Using Opera's mail client: http://www.opera.com/mail/
participants (9)
-
Aliaksei Syrel -
Ben Coman -
Christophe Demarey -
Denis Kudriashov -
Esteban Lorenzano -
Henrik Nergaard -
phil＠highoctane.be -
stepharo -
Thierry Goubier