[17:09:34] <nbelaevski> to get started http://community.jboss.org/docs/DOC-15982 please take a look
[17:09:37] <@balunasj> alexsmirnov: Good marning
[17:09:42] <nbelaevski> balunasj: sorry again
[17:10:49] <@balunasj> np
[17:11:05] Konstantin1 [~k@86.57.158.226] has joined #richfaces
[17:12:22] balunasj looking...
[17:15:52] <@balunasj> nbelaevski: so where would you like to begin?
[17:18:04] <nbelaevski> first of all, do you have any additions/corrections to the overall list of features?
[17:19:06] <@balunasj> Can you wuickly explain why removing the 2 features?
[17:19:32] <nbelaevski> yup
[17:19:50] <nbelaevski> Tree state advisors should be superceeded by sort of visual model
[17:20:23] <nbelaevski> Caching of tree nodes/models causes lot of problems in component - because user have access to cached nodes 
[17:20:32] <nbelaevski> so, taken into attention that
[17:20:41] <nbelaevski> 1) nobody seems to be using this
[17:20:57] <nbelaevski> 2) it's better to implement this at application side
[17:21:04] <nbelaevski> we decided to remove this feature
[17:21:23] <@balunasj> :-) fair points to be sure
[17:21:35] <@balunasj> So I'm fine with that.
[17:21:36] rh_ghu [~ghu@adsl-99-186-76-145.dsl.ltrkar.sbcglobal.net] has joined #richfaces
[17:21:58] <nbelaevski> good
[17:22:04] <@balunasj> What about the TreeDataModel - what are you plans for that?
[17:22:10] <nbelaevski> so I assume we don't have any corrections
[17:22:20] <nbelaevski> plans for TreeDataModel:
[17:22:38] <nbelaevski> 1) design it based on existing AbstractDataModel
[17:22:40] lfryc [~lfryc@nat/redhat/x-saqsmunsbwguuddm] has quit IRC: Quit: Leaving
[17:23:02] <nbelaevski> 2) allow it to be used as "value" attribute - that's a new feature that was lacking in 3.x
[17:23:15] <@balunasj> nbelaevski: Just looking through as we go - nothing is jumping out at me as wrong
[17:23:56] <@balunasj> nbelaevski: and for the end user - what is the good feature - customizing your own tree data model?
[17:24:04] <nbelaevski> ok, to make a side note: we haven't added details for two features that are sure to not fit in M4
[17:24:12] <nbelaevski> that's adaptors support & DnD
[17:24:21] ishaikovsky [~x3User539@86.57.158.226] has joined #richfaces
[17:24:27] <nbelaevski> so they are outlined with number of TBDs inside
[17:24:28] <ishaikovsky> hi guys
[17:24:33] <nbelaevski> ishaikovsky: hi
[17:24:45] <ishaikovsky> my client shown that I connected and I even saw Nick there :(
[17:24:58] <@balunasj> nbelaevski: yes - I saw the TBD - we'll talk about we get to them.
[17:25:33] <nbelaevski> to be correct
[17:25:50] <nbelaevski> "High Level Overview of the features" is not really a high-level list, but a list of what is planned for M4
[17:26:00] <@balunasj> ok
[17:26:03] nbelaevski updating the doc
[17:26:43] <nbelaevski> now it's better - please update
[17:26:54] <@balunasj> nbelaevski: also - several root nodes.  As part of same tree?  How what that look in xhtml?
[17:27:09] <nbelaevski> yes, as part of the same tree
[17:27:17] <nbelaevski> the same as the one-rooted tree
[17:27:30] <nbelaevski> the difference is in what model will use
[17:27:37] <@balunasj> alexsmirnov: Any comments up to this point?
[17:27:49] <@balunasj> nbelaevski: ok good
[17:27:51] <nbelaevski> e.g. use fake root node or start supporting list of nodes as allowed data type
[17:27:57] <nbelaevski> I'm for the second
[17:28:15] <@balunasj> nbelaevski: that sounds better to me as well
[17:28:20] <alexsmirnov> nbelaevski: may be better not to have several roots in same component, but hava ability to "stack" several components ?
[17:29:25] <nbelaevski> alexsmirnov: we are going to port treeNodesAdaptor/recursiveTreeNodesAdaptor after M4, so this can cover that
[17:29:34] <alexsmirnov> using vertical layout, for example.
[17:29:39] lfryc [~lfryc@nat/redhat/x-ldrhqisndlgeutaj] has joined #richfaces
[17:30:15] <nbelaevski> alexsmirnov: it looks like it's a renderer's responsibility
[17:30:54] <nbelaevski> balunasj: the question about variants of root node is actual because fake TreeNode allows to define arbitrary key for the root node 
[17:31:09] <nbelaevski> balunasj: in the case of list we are limited to sequential numbers
[17:31:30] <@balunasj> nbelaevski: ah, ic where that could be question...
[17:32:09] <nbelaevski> balunasj: yes, almost everybody wants modifiable trees and that's the area where sequential keys don't play well 
[17:33:13] <nbelaevski> in 3.x we used org.rf.model.TreeNode as fake root node always and also supported list of swing TreeNode, but that's really confusing :( 
[17:34:13] <@balunasj> nbelaevski: so how will the change you suggest change.  The root could be its own list?  So have multiple entries?
[17:34:14] <nbelaevski> maps can provide arbitrary keys, but that's not very natural too - maps are usually not ordered anyhow
[17:35:06] <@balunasj> right
[17:35:59] <alexsmirnov> nbelaevski: TreeMap is ordered.
[17:36:18] <nbelaevski> I'm thinking about collection of TreeNode of any type + expression to get persistent key 
[17:36:26] <@balunasj> alexsmirnov: good point - and would likely be less confusing
[17:36:33] <nbelaevski> but not sure that'd play with the model well
[17:37:13] <nbelaevski> also LinkedHashMap, but there are more problems with it - how would users add node C between nodes B & A?
[17:37:40] <nbelaevski> maps contract doesn't make it easy
[17:41:01] <@balunasj> so you are thinking of using collection of tree nodes
[17:41:09] <@balunasj> lets see how that goes.
[17:41:26] <nbelaevski> so I'm going to start with collection/map of node (or single node) as root value and research the problem of keys persistence later then 
[17:41:35] <@balunasj> sounds good
[17:41:46] <nbelaevski> if single node - it's a single root (not fake)
[17:42:30] <@balunasj> Since I have a hard stop at in 20 min.  Lets move on to questionable part - agree?
[17:42:41] balunasj you guys please continue after I leaeve.
[17:42:51] <nbelaevski> are we all fine with the base functionality part? 
[17:43:37] <nbelaevski> if yes - let's get to questionnable part
[17:43:41] <ishaikovsky> nbelaevski, you know I am - yes :)
[17:43:53] <nbelaevski> ishaikovsky: right, by definition :)
[17:43:54] <alexsmirnov> nbelaevski: The only thing is to remove features that hard to implement in component.
[17:44:00] <@balunasj> hehe
[17:44:09] <nbelaevski> alexsmirnov: ok, which one(s)?
[17:44:13] <ishaikovsky> nbelaevski, no because discussed :)
[17:44:31] <@balunasj> the lazy loading, and "loading facet" look good if not too hard
[17:44:39] <alexsmirnov> As I already wrote in articles about tables, the idea of visual model seem not so good for me now.
[17:45:14] <@balunasj> alexsmirnov: that is down in the questionable ones
[17:45:30] <nbelaevski> but tree has to store it's toggle/selection state
[17:45:39] <alexsmirnov> I thought to move node states, selections and so on into model. User can keep them with data or store somethere else - it's up to developer.
[17:45:46] <nbelaevski> we cannot force the user to store this information in model objects
[17:46:16] <nbelaevski> yes, that's what we are going to do
[17:46:35] <nbelaevski> either user can use expanded="#{node.expanded}" attribute
[17:46:51] <nbelaevski> or not use it and then tree will use internal VM
[17:47:05] <nbelaevski> internal but anyway accessible to the user
[17:48:15] <nbelaevski> alexsmirnov: does this approach look fine?
[17:50:12] <nbelaevski> let's take this offline maybe?
[17:50:43] <alexsmirnov> It's additional complexity. 'expanded' 'selected' properties woiud be stored in database or be independent field.
[17:51:34] <alexsmirnov> Let's treat selected and expanded as ordinary inpits.
[17:52:40] <alexsmirnov> It evaporated problem to keep visual and data models in sinc.
[17:53:14] <nbelaevski> I'll need to discuss this more with you
[17:53:37] <alexsmirnov> ok, let's discuss it after meeting.
[17:53:40] <nbelaevski> ok
[17:54:12] <@balunasj> nbelaevski: I'm ok with d-n-d waiting
[17:54:16] <nbelaevski> alexsmirnov: any other complex features?
[17:54:24] <nbelaevski> balunasj: good
[17:54:45] <@balunasj> nbelaevski: I'm thinking the adapters might be missed by users?  ishaikovsky thoughts?
[17:55:27] <nbelaevski> balunasj: definitely yes. they just do not fit into M4
[17:55:38] <@balunasj> nbelaevski: ok
[17:55:41] <ishaikovsky> balunasj, I belive it's not big problem to implement later
[17:55:47] <ishaikovsky> we do not reject at all
[17:55:49] <nbelaevski> balunasj: furthermore they are extension
[17:56:00] <alexsmirnov> nbelaevski: transient state implemented by Leonardo comes to 2.1 spec. Have you seen it ? Can it help to make tree better ?
[17:56:04] <@balunasj> nbelaevski: lets get in what we can, but I understand
[17:56:12] <nbelaevski> alexsmirnov: not checked yet, but need to
[17:56:20] <nbelaevski> balunasj: ok, thanks
[17:56:27] <ishaikovsky> just I agree that Nick needs some time after M4 :)
[17:56:43] <alexsmirnov> So it's important decision - develop tree for 2.1 spec or make it 2.0 compatible.
[17:57:33] rruss [~Adium@redhat/jboss/rruss] has joined #richfaces
[17:58:05] <@balunasj> I'm sorry guys I need to move to my other meeting - please continue I'll review log
[17:58:10] balunasj [~balunasj@redhat/jboss/balunasj] is now known as balunasj_mtg
[17:58:57] <nbelaevski> I think we need to go 2.0 now
[17:59:32] <nbelaevski> and create abstraction class(es) that will isolate these issues
[17:59:39] <@balunasj_mtg> nbelaevski: how much work for it to be convertable?
[18:00:22] <nbelaevski> sorry, but cannot say that right now - need to check the changes
[18:00:37] <alexsmirnov> nbelaevski: at least we should keep 2.1 transient state on radar. Maybe, have two subclasses for different versions.
[18:01:36] <nbelaevski> yes, that's fine
[18:02:19] <ishaikovsky> alexsmirnov, agree.. anyway not much apps nowadays getting ported as far as JSF 2 still not considered "stable enough" At least user activity is not huge enough for RF 4 JSF 2.. So to the days when JSF 2.1 will be there we should support its best features which was not in 2.0
[18:02:52] ppitonak [~ppitonak@nat/redhat/x-eeejmkfpurjodjjk] has quit IRC: Read error: Operation timed out
[18:04:46] <alexsmirnov> ishaikovsky: That was my opinion when JSF 2.0 was released - business will wait for 2.1/2.2 fo migration, while 2.0 is for early adopters and experiments only.
[18:04:57] <ishaikovsky> agree
[18:05:04] <alexsmirnov> I see I was right :-)
[18:05:14] <ishaikovsky> The same was for 1.x
[18:05:15] <ishaikovsky> :)
[18:05:44] <ishaikovsky> so we need to have support for 2.1 2.2 features as far as them getting popular and stable
[18:06:00] <nbelaevski> ishaikovsky: what about now?
[18:06:56] <ishaikovsky> nbelaevski, you mean some features will require much time on redesign later if will be based on 2.0?
[18:07:22] <nbelaevski> no, we were going to choose what we use now
[18:07:26] <nbelaevski> 2.0 or 2.1
[18:08:12] <ishaikovsky> that should be adressed together with Jay I believe.. but good variant would be RF 4.0 - JSF 2.0 and RF 4.1 - JSF 2.1
[18:08:15] <nbelaevski> alexsmirnov: will we be able to compile 2.1 version using 2.0 API?
[18:09:45] <alexsmirnov> nbelaevski: I hope so. probably, 2.1 will allow more components work in tree, or lets trees to work better inside repeaters.
[18:10:33] <nbelaevski> alexsmirnov: ok, I'll need to take a look at the changes
[18:11:07] <nbelaevski> alexsmirnov: ishaikovsky: but if they are not fully back compatible with 2.0 I think we should be basing on 2.0
[18:11:39] <nbelaevski> alexsmirnov: ishaikovsky: and make a fork for 2.1 then
[18:12:00] <ishaikovsky> nbelaevski, as people will not use 2.0 since 2.1 release (and almost nobody seriously working with 2.0 now)
[18:12:09] <ishaikovsky> IMO 4.1 could be not compatible with 2.0
[18:12:09] <alexsmirnov> nbelaevski: as I told, it's subject for decigion.
[18:12:27] <ishaikovsky> and be based on 2.1
[18:12:43] <ishaikovsky> but that a question to Jay too :)
[18:16:13] <nbelaevski> ok, any other issues?
[18:18:26] <alexsmirnov> nothing else from me
[18:19:09] <nbelaevski> ok how about making a call to discuss visual models?