--- Log opened Mon Sep 10 00:00:55 2012
10:26 < conseo> mcallan: i don't really understand the problem with celllist. you are right that celllist is the view and listdataprovider is the model
10:31 < conseo> if i try to map your polltrack design onto the talktrack, i have a simple list of diffmessages. do you think they are events?
10:32 < conseo> i do as you suggest. atm. it is a dirty prototype with dummy data, i can switch away from celllist, i just lack the understanding of both the problem and a better design
12:44 < conseo> mcallan: index only scans and range types are now available. json also can be streamed directly out of the db: https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2#Index-only_scans
13:23 < conseo> mcallan: i can continue to try float the elements out of the block on the left side and then set overflow hidden. but is it reasonable to have a list of a few thousand messages we operate upon to show the proper context?
13:23 < conseo> maybe we should discuss this context browsing and how the talk track reacts in detail?
17:42 < mcallan> conseo: still there?
17:48 < mcallan> (back in 30 min)
20:38 < conseo> mcallan: re
20:45 < mcallan> hey c, can u skype?
20:46 < conseo> it is a bit late already, i might wake somebody and i am tired. when will u be around tomorrow?
20:47 < conseo> can i prepare something? answer a design question or so?
20:49 < mcallan> to me it seems very easy to code basic model and view.  what is the biggest difficulty you see?
20:51 < mcallan> i will be online for another 8 hours or so, so will probably miss you tomorrow again
20:52 < conseo> mcallan: i don't know how the feed is supposed to behave when different options are selected in the stage. if spaces are supposed to be empty or fixed, then a list view won't be enough, then i need a table view with empty and stacked spaces like you did
20:53 < conseo> if i can just show a list of ordered posts, a floating number of elemets filling up the space seems more reasonable to me
20:54 < mcallan> it looks like this: [         DDDDDD], or if that's too hard: [DDDDDDD       ]
20:54 < mcallan> here [ is edge of track, and D is message
20:54 < conseo> mcallan: rightest = newest?
20:54 < mcallan> yes, in first one
20:55 < mcallan> (left in second)
20:55 < conseo> do you prefer [         DDDDDD] ?
20:56 < mcallan> yes, if you agree, it's more natural
20:56 < conseo> this one is easy with float: right and overflow:hidden even for celllist (not necessarily pointing to its impl. only the css view)
20:56 < conseo> ok, whatever natural means :-)
20:56 < mcallan> natural = time series, written on piece of paper
20:57 < mcallan> newest is on right
20:57 < conseo> yes i agree that it is in that sense intuitive
20:57 < conseo> ok
20:57 < mcallan> cell list is garbage for this, imho.  much easier to code from scratch
20:58 < conseo> but it is the same thing as the feed, i have difficulties seeing differences, besides the hard-coded choive of div-elements for cells
20:58 < conseo> i can throw it away, but for what reason?
20:59 < conseo> is this view to much?
20:59 < conseo> too
20:59 < mcallan> what view?  too much?
21:00 < conseo> the celllist view which uses div-elements with display:inline and float: right?
21:00 < mcallan> the model is all wrong.  the view is clumsy and hard to understand.  it's bloated garbage, imho
21:00 < conseo> i have understood you that you think it is not good to take the model first without understanding that we write html controls and not some full ui toolkit
21:01 < mcallan> you are overcomplicating... when you see how simple it is,,,
21:01 < mcallan> you will hit yourself on head
21:02 < mcallan> the view is just <span><span><span>...  that is all!
21:02 < mcallan> the model is just D,D,D,...
21:02 < conseo> or <span><img/><img/>...</span>.
21:03 < mcallan> just sync the two, that's the whole basic track
21:03 < conseo> but div inline or span is pretty similar or not?
21:03 < mcallan> layout is same, yes
21:04 < mcallan> you really like cell list? :-)
21:04 < conseo> can i easily handle onclick events to talk to the stage properly for this lonely row of img tags?
21:05 < mcallan> like when user clicks on one?
21:05 < conseo> yes
21:06 < mcallan> yes: <span><span><span class='clicked'><span>...
21:06 < mcallan> you will learn how to do it properly, without cell list nonsense in your way
21:07 < conseo> yeah ok, but this is what cell-list needs as well. it encloses all cells by a <div> element
21:07 < conseo> ok
21:07 < conseo> hmm
21:08 < conseo> so you say that all this modelling on top of celllist for paging and stuff is overcomplicated not the rendered view?
21:09 < mcallan> yes, it's mostly the modelling that is borked, i think
21:09 < conseo> ok, good
21:09 < conseo> so e.g. all the paging and handler stuff is too much for a simple feed like ours?
21:10 < mcallan> yes.  both list data provider, and the cell list paging nonsense are difficult to understand.
21:10 < mcallan> paging/scrolling is not urgent, and might never be needed
21:10 < conseo> that is true. more important is the interaction with the stage and the page embedded
21:11 < conseo> also seleciton on the timeline is pretty clumsy, you wouldn't search all these little symbols for the one post half a year ago you are searching
21:11 < conseo> the view is too small for that
21:12 < conseo> in general paging will be confusing with so many small elements
21:12 < mcallan> yes, and paging/scrolling controls would clutter the ui
21:13 < conseo> better is to scope the stage context in general and allow something like the feed to do serious browsing
21:13 < conseo> yes
21:13 < conseo> (serious browsing of messages and communication)
21:13 < mcallan> yes, feed proper can be brought in as a curtain later
21:14 < mcallan> *if* it is, then i admit it would be nice if they share model
21:14 < conseo> so i will have a list fetched from the server (something like a hundred posts of the current context loaded on page load for now) and pump that into the view with overflowing
21:15 < conseo> ok, but then we will know a lot more about our model as well and porting shouldn't be a problem unless we over-complicate our model
21:15 < mcallan> the only drawback is if we bring the old feed back in (e.g. as curtain)
21:15 < conseo> i still need to do this filling through a callback
21:16 < mcallan> filling of the model
21:16 < mcallan> ?
21:16 < conseo> yes, but atm. i see little more information in its view worth the space. the summary is nicely shown by the stage, no need to show them all
21:16 < conseo> the view, sry
21:16 < mcallan> (i agree, leave the feed problem till later)
21:17 < mcallan> view reads from model, and fills itself (adding, removing elements as needed)
21:17 < mcallan> you asking not about how, but about when?
21:18 < conseo> no just about how to prototype the next view roughly. the callback is pretty clear
21:19 < conseo> i think i can do that now and then ask you specific questions
21:19 < mcallan> callback, just explain that plz
21:19 < conseo> the javascript callback from the servlet
21:19 < mcallan> view does not talk to servlet
21:19 < conseo> the bites will be loaded asynchronously
21:19 < mcallan> into the *model*
21:20 < mcallan> then from model, into view*s*
21:20 < conseo> by the controller? i am still not always sure who really acts. the model is the list basically and is filled by the controller. the controller also notifies the view when the list changes so it "redraws" itself
21:20 < conseo> (?)
21:21 < mcallan> very simple: 123...
21:21 < mcallan> 1 model fills itself
21:21 < mcallan> 2 model fires change event
21:21 < mcallan> 3 views receive change event
21:22 < mcallan> 4 views read model, and sync
21:22 < mcallan> that's it
21:22 < conseo> this goes over the gwt event bus?
21:22 < mcallan> change events, yes
21:22 < conseo> ok, thanks for taking the time to clarify
21:22 < conseo> there is no controller here (?)
21:23 < conseo> it would be something like the pager?
21:23 < mcallan> yes. selectors, too.  but they are details you can add later, as you please
21:24 < mcallan> in a couple weeks (prob) i will be coding much the same thing for polltrack
21:24 < conseo> ok, so the controller in mvc is really optional. i have been confused about its role a bit in the past
21:24 < conseo> ok, maybe i have something alpha-ready by then (to get some first user-feedback(
21:24 < conseo> )
21:25 < mcallan> yes, controller (and control) is optional
21:25 < conseo> ok, cool
21:25 < mcallan> sure, we can compare notes later.  and there are many, many examples of mvc in our current gwt code
21:26 < conseo> yes, i have a had a look at the votetrack, but its table layout was not really comparable
21:27 < conseo> i think i can get along for now, thx! i will be around anyway :-)
21:27 < mcallan> ur welcome
--- Log closed Tue Sep 11 00:00:12 2012