Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#1391 closed defect (invalid)

FilteringTable + SimpleStore "thoughts"

Reported by: jkuhnert Owned by: Tom Trenka
Priority: high Milestone:
Component: Data Version: 0.4
Keywords: Cc:
Blocked By: Blocking:

Description

I'm just going to paste in a commit log I made during some recent interactions.

The default set of event connections on FilteringTable? probably needs to be=

re-thought..OR...gasp...I might

even go as far as saying the SimpleStore? on<SetData/ClearData/AddData?> type=

events need to be renamed

to something more meaningful...Either way the FilteringTable? is completely = tied to the SimpleStore? right now. That's not a bad thing, but the SimpleStore? API needs to reflect that by ha= ving more descriptive names for it's event functions...like fireDataSet()/fireDataCleared()/fireDataAdd= ed(data)...It sounds like swing but it makes sense. In the current implementation it does at least..(though=

I'd say the event connections =

should remain completely seperate..If people want certain things to happen = they should be able to connect the two explicitly...)

Change History (3)

comment:1 Changed 13 years ago by Tom Trenka

Resolution: invalid
Status: newclosed

That is all completely by design and congruent with the way people understand event names using development based on the DOM, which is where most of the interaction is coming from.

FilteringTable? was *designed* to be tied to a SimpleStore?; this was also completely on purpose. The *only* real issue I can see in the future--which may or may not be addressed in the next release of Dojo--would be the ability to point a FilteringTable? at a different SimpleStore? as the foundation for its data, which I'm not going to build into the widget at this point.

The whole point of the widget is to act as the primary visualization mechanism for a SimpleStore?.

How are the event names not meaningful? You set the data of the store, and onSetData fires. You know, [methodName] and on[methodName] pairs work very well. What's hard to understand about that?

Closing this as invalid.

comment:2 Changed 13 years ago by jkuhnert

What isn't clear from looking at SimpleStore?.onSetData or any of the other on<foo> functions is that they most definitely *do* cause something to happen... Usually on<foo> is there to indicate that as being an optional event to listen to, but in the case of SimpleStore? it is directly tied to causing certain things in the FilteringTable? to be triggered...So the "optional" sort of event listening semantics become concrete non optional things that cause definite UI changes to happen in the table...It would be nice to be able to look at the SimpleStore? alone and intuitively figure out what will cause what to happen in the FilteringTable? based on your interactions with it.

Most of this centered around me wanting to be able to preserve the selected state of data items in the store when "refreshing" (ie new JSON objects that may/may not have the same fieldId values as those already in the store) the data by calling setData. The refresh would happen because of changes to one data item in the set of items...Would probably be *easiest* to be able to tell the SimpleStore? that one single row has changed so that the FilteringTable? can update the display of that row without necessarily losing your selected state.

comment:3 Changed 12 years ago by (none)

Milestone: 0.4

Milestone 0.4 deleted

Note: See TracTickets for help on using tickets.