Paul Johnston wrote: > Hi, > > >> I'll lend you a hand on this one if you'd like. The next thing I want to >> implement for the widget browser (those tabs inside the sphinx docs that >> show the source, template and live widget) is a way to register tiny >> controllers to feed data to demo the ajax enabled widgets. dynforms >> would be a perfect use-case. >> >> >> > Sweet - FilteringGrid is probably the best candidate for starting this. > AjaxLookup is another possibility, but I'm not quite sure about that > widget - I've seen another similar one, (twAjaxTools) that may have the > edge. Ok, I'll try to write a demo for the widgetbrowser for it later today. > I've made a token effort at doc strings so far. If I could see generated > docs, I think I could tweak the doc strings into a much better state > quite quickly. > > >> If you give me the green light I can import dynforms into mercurial >> tomorrow (hopefully) and set up a skeleton tw-enabled sphinx doc root to >> try make a demo of some ajax widget. >> >> >> > Ok, I've created the "paj" user on beta.toscawidgets.org. Happy for you > to swing dynforms onto hg, provided you let me know as soon as you do, > and I can get on ok. Don't want too much downtime between repositories. >
I've imported tw.dynforms into mercurial and beta.tw.org. I also created a blank Trac for it in case you want to use it and a quickstarted sphinx docs dir with some wiring to hook up with the widgetbrowser and some dummy sample docs. You have push access to that repository, TW's and tw.forms and TRAC_ADMIN rights on trac. To push changes there, commit everything in your local hg repo and then run: hg push http://beta.toscawidgets.org/hg/tw.dynforms You'll be prompted for your username and password and that shall be it. To generate the docs for preview you don't need the widget browser installed yet (any widgetbrowser directive will just be ignored and a warning emitted). easy_install Sphinx and run: $ sphinx-build docs some_build_dir Sphinx syntax is rest with some sugar for sphinx goodies, you can check the source of any sphinx docs page for examples. Docs for tw.org use a custom widgetbrowser directive to generate the widget browser tabs, take a look at tw.forms docs source to see how it's being used (though its still experimental and its syntax might change). These docs don't need any special template or css to be used in tw.org since they're styled dynamically with deliverance. >> Currently the widget browser live insdie the site's egg but i plan to >> extract it to a separate egg that can be used to try out widgets locally >> and preview the docs. >> >> >> > Let me know when you do - I'm waiting with baited breath :-) > Sure :) >> Nope, a branch would not propagate unless one uses hgsvn to import it to >> a new mercurial repository. However, I don't think it would be possible >> to merge the two unrelated (to hg's eyes) repositories later. >> >> >> > Don't worry too much about the repositories, it's a fairly small patch > so far, easy enough to manage that way. Good to know I can move them, I'd really like this hg/svn repository duality to last the shortest time possible. I'll close SVN soon then. > I would really like your opinion > on my first cut at it. My plan is to tidy it up a bit, add a clever > object to replace "children" that support indexs lookup and iteration, > with some jiggery pokery. A clever WidgetBunch sounds like a good way to implement it. If it could return a "dynamic-repeated-widget" on index lookup the current API might not break at all. This change and the RequestLocalDescriptor idea you mentioned to store the repetition could and that could probably do it I guess. > How much can we break compatibility? Hmm, I think this particular area has more room for API breakage since I haven't used myself or seen code that queries repeated widgets ids so my guess is that no one would notice :) These are good times for small API breakage since 0.9 will probably be incompatible in some situations anyway because i'm going to remove ruledispatch. > If a > little breakage is allowed, we can make this the default behaviour. It's an improvement over the current kludgy implementation which I wanted to do sometime anyway so sure, lets make it the default. > > Another option is to leave WidgetRepeater as is, and create a sister, > something like UnlimitedWidgetRepeater (dodgy name I know :-) > (...) > Ah, gotcha, I'd started ignoring that thread as it got so long. I'll go > for toscawidgets.org and I hope Chris will too. In fact, I think > tw.tools came from you being unavailable for a while, and he thought he > may need to forcibly take control to avoid stagnation. Just glad you've > reappeared :-) > BTW, tw.org is looking for backup sysadmin volunteers in case I hibernate again... Sharing servers with tg.org will also help :) Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
