Navigation: I do think that it makes sense to consider a new model for navigation. I can volunteer a little time this month to do a 'sprint' implementation of this if one or two others are interested in participating and we can agree on the main design principles in the meantime. I'll send a follow-up e-mail on this point.
YUI: Is there likely to be some integration between the two YUI libraries? If there was a standard dependency, but some divergence on widget API, we could accommodate two contrib trees on top of a core weblocks infrastructure. I think it's OK for the platform to make preferential commitment to a single library such that it is possible, but not as easy, to use another one. I don't really need this anytime soon, so won't worry about trying to integrate it. Source control: Not to revisit the exciting discussions of the summer, but in general, I've found darcs much easier to think about. I maintain several large projects in darcs, albeit with only a few developers each, and only occasionally have problems due to darcs itself. However, here we are. I think the mercurial/bitbucket problems would go away if the lead developers essentially documented and enforced a simple, standard process for mainline and concurrent development models that was a clean, easy to think about, subset of what hg can do. I would appreciate that and would be likely to contribute some more work if that were the case. Frankly, I think regular hg users can reason about usage models that turns off those of us who do not necessarily want to get our head around all the details; this because weblocks is the only project we use hg on.. Perhaps those wizards who got us into this should volunteer to do all the integrations! :) Ian On Dec 7, 2008, at 11:28 AM, Jan Rychter wrote: > > Ian Eslick <[EMAIL PROTECTED]> writes: >> I'm back for a few days after a long absence. From my light sampling >> of the discussions, much of the work has been cleaning up the generic >> object presentations and fields as well as integration of YUI-based >> widgets and general cleanup/stability. > > I had a similar leave of absence. And I thought I'd mention that I > have > YUI work that is completely independent of what Leslie has done, and > likely different. > >> What other major changes have happened to weblocks in the last few >> months? I saw a reference to 'modern-navigation' a few e-mails ago. >> What changes does the new container interface and modern-navigation >> bring to the system. > > I'm trying to find out myself, as well as trying to get to the new > navigation system patches. As it is unclear how long this will take, I > tried to list things which are immediate problems for me in the > current > navigation scheme: > > 1. There is no way to hide menu items. > > 2. There should be a way to render the menu separately from the > navigated > content (e.g. in another part of the rendered HTML). > > 3. There should be an easy way to specify URL prefixes leading to > particular widgets (easier than functions operating on URL tokens and > returning multiple values). > > 4. The navigation widget code is arcane and should be simplified (I > don't see why all functions have to deal with either strings, symbols, > or pane-info structures, let's just unify all that and convert > everything into pane-info structures in make-navigation). > > #1 is a showstopper for me, #2 follows closely. #3 and #4 are less > important. I could likely fix all those in a day or so, but I am > afraid > of investing effort into something that will go away -- and I don't > know > if it will or not, and when. > > As a side note, I noticed that we seem to have several large > branches in > various repositories right now. These are becoming more and more > divergent and difficult to integrate as they grow, they are hard to > understand for newcomers (like me) and functionality cannot be easily > split out. In addition to that, I find that merge commits clutter up > histories. In my opinion hg and bitbucket are partly responsible for > this. It is much easier to create, maintain and synchronize remotely > small "topic" branches in git. As I wrote in another e-mail, I don't > develop on one huge branch, I maintain about 10 branches, so at any > moment in time I can separate one of them for submission. > > --J. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
