beta.toscawidgets.org update
Alberto Valverde
These last few days I've been working on the toscawidgets.org
infrastructure to host widget docs, Hg repositories and Tracs.
User registration is working (needed to edit the tracs and push changes to
the repositories), site-wide authentication is working too and Sphinx is
being used to generate docs with a custom extension to show "living"
widgets. Check it out here [1]
I'm planning to remove the ".beta" prefix sometime this week and kill the
SVN TW and tw.forms repositories at svn.turbogears.org to host them
exclusively in toscawidgets.org (this move involves switching to
Mercurial). If you have any uncommitted changes (I'm looking at you Paul
;) in SVN its better to commit them sooner than later.
Another thing that will move are all the TW related tickets from TG's Trac.
This infrastructure is open to anyone who wants to host their widgets
code. If anyone wants to come on board be sure to ping me so I can set
things up and explain how to use the uber-cool documentation facilities ;)
Feedback is welcome, enjoy :)
Alberto
[1]
http://beta.toscawidgets.org/documentation/tw.forms-0.8/modules/fields/forms.html#an-example
Christopher Arndt
> These last few days I've been working on the toscawidgets.org
> infrastructure to host widget docs, Hg repositories and Tracs.
It shows. Very good looking site, indeed!
> I'm planning to remove the ".beta" prefix sometime this week and kill the
> SVN TW and tw.forms repositories at svn.turbogears.org to host them
> exclusively in toscawidgets.org (this move involves switching to
> Mercurial).
I would be very much interested in your experiences with Trac+Merurial.
You are using the Mercurial Plugin for Trac [1], I suppose? The site
says it's still very much experimental, so I wonder, whether you would
say that it's ready for daily usage.
I'm looking for a way to host my private projects on a publically
accessible Trac but still keep my source repository on my local
computers and I considered using a distributed VCS like mercurial. I
like Trac very much, so I need a VCS that works with it.
Chris
Mark Ramm
> You are using the Mercurial Plugin for Trac [1], I suppose? The site
> says it's still very much experimental, so I wonder, whether you would
> say that it's ready for daily usage.
The pylons folks have been using mercurial and trac together for at
least 9 months, and they seem to have had no real problems with that
combination.
--Mark
Paul Johnston
>These last few days I've been working on the toscawidgets.org
>infrastructure to host widget docs, Hg repositories and Tracs.
>
>
Wow! I'm loving the sphinx generated docs. Gonna have a bash and see if
I can do something similar for tw.dynforms.
Like the registration too... blatent toscawidgets-ism :-)
>Mercurial). If you have any uncommitted changes (I'm looking at you Paul
>;) in SVN its better to commit them sooner than later.
>
>
Oooh, the no max_reps work. Still a little hacky for committing. If I
make a branch in svn, will that propagate to hg ok? I've never actually
done an svn branch, but I guess it's not so hard. I'll get on the case.
>This infrastructure is open to anyone who wants to host their widgets
>code. If anyone wants to come on board be sure to ping me so I can set
>things up and explain how to use the uber-cool documentation facilities ;)
>
>
How does this stack up against twtools.googlecode.com? I'm all for a
community widgets area, but I think we're better off having just one.
Take care,
Paul
//
Paul Johnston
>Oooh, the no max_reps work. Still a little hacky for committing. If I
>make a branch in svn, will that propagate to hg ok? I've never actually
>done an svn branch, but I guess it's not so hard. I'll get on the case.
>
>
Ok, done it. Dead easy in the end, beats CVS branching hands down. What
was I scared of? :-)
Paul
Alberto Valverde
> Hi,
>
>
>> These last few days I've been working on the toscawidgets.org
>> infrastructure to host widget docs, Hg repositories and Tracs.
>>
>>
>>
> Wow! I'm loving the sphinx generated docs. Gonna have a bash and see if
> I can do something similar for tw.dynforms.
>
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.
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.
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.
> Like the registration too... blatent toscawidgets-ism :-)
>
hehe, tw.org eats its own food ;)
>
>> Mercurial). If you have any uncommitted changes (I'm looking at you Paul
>> ;) in SVN its better to commit them sooner than later.
>>
>>
>>
> Oooh, the no max_reps work. Still a little hacky for committing. If I
> make a branch in svn, will that propagate to hg ok? I've never actually
> done an svn branch, but I guess it's not so hard. I'll get on the case.
>
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.
I think the easiest thing would be to clone the new tw.forms hg
repository (making an effective branch) and then apply a unified diff of
the last svn revision that has been imported into hg till where you are
and patch the hg checkout with it. Then you can work on it with full
version control until it can be merged.
>> This infrastructure is open to anyone who wants to host their widgets
>> code. If anyone wants to come on board be sure to ping me so I can set
>> things up and explain how to use the uber-cool documentation facilities ;)
>>
>>
>>
> How does this stack up against twtools.googlecode.com? I'm all for a
> community widgets area, but I think we're better off having just one.
>
We discussed this in tw-discuss a couple of days ago [1] and I explained
why I like toscawidgets.org better for that purpose. Summing up:
* The infrastructure is more flexible: can run trac, hg, sphinx, custom
code...
* The docs can be generated from each project's repository in the same
server (with commit hooks, etc) so they're always up to date.
* Docs can have a widget browser to see how the widget looks live and
interact with it.
* I like the theme better :)
Regards,
Alberto
[1]
http://groups.google.com/group/toscawidgets-discuss/browse_thread/thread/a2700123b7f0b9e0
Alberto Valverde
easier to branch on the Hg side... nevermind, that'll raise the pressure
on me to look at the changes and merge them before migrating so it'll
actually get done ;)
Alberto
Alberto Valverde
> Alberto Valverde schrieb:
>
>> These last few days I've been working on the toscawidgets.org
>> infrastructure to host widget docs, Hg repositories and Tracs.
>>
>
> It shows. Very good looking site, indeed!
>
Thanks :) Most credit should go to Daniel who is the theme's author.
>
>> I'm planning to remove the ".beta" prefix sometime this week and kill the
>> SVN TW and tw.forms repositories at svn.turbogears.org to host them
>> exclusively in toscawidgets.org (this move involves switching to
>> Mercurial).
>>
>
> I would be very much interested in your experiences with Trac+Merurial.
> You are using the Mercurial Plugin for Trac [1], I suppose?
Yep. You can see how all this is tied up in
http://beta.toscawidgets.org/hg/twWebSite if interested.
> The site
> says it's still very much experimental, so I wonder, whether you would
> say that it's ready for daily usage.
>
I haven't really stressed the combination but I haven't noticed anything
weird so far. From my limited experience, I'd say yes. As Mark pointed
out, Pylons is doing the same and seem to have had no problems.
One thing that sucks is that you can't use Trac for multiple hg
repositories ATM. The problem here is that every hg branch is actually a
repository of it's own. There's a Trac branch with multiple repository
support but I'm not brave enough to deploy it in tw.org until it it is
merged to the trunk. A workaround is to have one trac instance per
repository which is not that bad IMHO.
Alberto
Christopher Arndt
Thanks, good to know.
Chris
Paul Johnston
>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.
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.
>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 :-)
>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. 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. How much can we break compatibility? If a
little breakage is allowed, we can make this the default behaviour.
Another option is to leave WidgetRepeater as is, and create a sister,
something like UnlimitedWidgetRepeater (dodgy name I know :-)
>>How does this stack up against twtools.googlecode.com? I'm all for a
>>community widgets area, but I think we're better off having just one.
>>
>>
>We discussed this in tw-discuss a couple of days ago [1] and I explained
>why I like toscawidgets.org better for that purpose. Summing up:
>
>
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 :-)
Paul
Alberto Valverde
> 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.
> 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
Paul Johnston
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.
Ok, it's looking good, although I've not tried a push yet. I'll treat this as the official tw.dynforms repository as of now, although I won't remove the twtools.googlecode stuff for now, just in case :-)
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:
Well, it's a start. My main initial wants are:
1) Only show parameters that belong directly to the widget, not to its base classes
2) Pick up documentation in the params dict (perhaps this isn't possible though; I can always recode)
3) Generate doc for all the classes (perhaps everything in __all__, like apydia) without having to specify them manually
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.
I will have a look at this in detail over the coming days and let you know how I get on.
Yeah, I think I can do that. Let me mull it over for a few days before I say for sure. Gee, the whole point of this originally was to save time in doing web development, I seem to have got a little side-tracked :-)
Paul
Paul Johnston
hg push http://beta.toscawidgets.org/hg/tw.dynforms
You'll be prompted for your username and password and that shall be it.
pushing to http://beta.toscawidgets.org/hg/tw.dynforms
searching for changes
http authorization required
realm: ToscaWidgets repositories
user: paj
password:
abort: authorization failed
Alberto Valverde
Hmm, are you able to log in with the same username/passwd combo with the
login form? What version of mercurial are you using?
Alberto
Alberto Valverde
> 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.
>
>
> Ok, it's looking good, although I've not tried a push yet. I'll treat
> this as the official tw.dynforms repository as of now, although I
> won't remove the twtools.googlecode stuff for now, just in case :-)
>
> 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:
>
>
> Well, it's a start. My main initial wants are:
> 1) Only show parameters that belong directly to the widget, not to its
> base classes
'local'). Now the GUI needs the ability to hide the inherited ones until
the user wants to drill them, working on it...
> 2) Pick up documentation in the params dict (perhaps this isn't
> possible though; I can always recode)
> 3) Generate doc for all the classes (perhaps everything in __all__,
> like apydia) without having to specify them manually
Have you seen Sphinx ... autodoc extension [1]? There's a directive to
auto-document a module. The only reason I'm not using it is because I
don't like the results (it tries to document every single inherited
method of every widget wich are many). One of the things that has sold
me to Sphinx is that it you have more control over the documentation
process without having to retro-fit the code to play nice with the
introspection process (remember __pudge__all__?)
Alberto
Paul Johnston
Wow, we have been making loads of progress these last few days!
>Hmm, are you able to log in with the same username/passwd combo with the
>login form? What version of mercurial are you using?
>
>
Strange, just tried from a different computer and it worked first time.
Both computers have latest version of TortoiseHg for Windows.
No worries about the resource injector, with any luck TG2 will overtake
us and sideline CP.
I'm going to play some more with the widgets browser now.
Paul
Paul Johnston
> 1) Only show parameters that belong directly to the widget, not to itsDone. The new WidgetBrowser eggs separates both kinds (inherited and
> base classes
'local'). Now the GUI needs the ability to hide the inherited ones until
the user wants to drill them, working on it...
Ok, I've just committed a change adding a "param_doc_cutoff" parameter to widgets. Not sure it's 100% what we want, but it definitely helps for now.
> possible though; I can always recode)> 2) Pick up documentation in the params dict (perhaps this isn't
I've opened ticket #4 for it.
Ok, I've committed a fix.
Paul
Alberto Valverde
> Hi,
Hi Paul, thanks for closing that ticket.
>> 1) Only show parameters that belong directly to the widget, not to its
>> > base classes
>> Done. The new WidgetBrowser eggs separates both kinds (inherited and
>> 'local'). Now the GUI needs the ability to hide the inherited ones until
>> the user wants to drill them, working on it...
>
>
> Ok, I've just committed a change adding a "param_doc_cutoff" parameter to
> widgets. Not sure it's 100% what we want, but it definitely helps for now.
I've removed the parameter documentation code from WidgetType altogether
(hence your change too, sorry). The reason is that the WidgetBrowser now
has a class to do that [1] and shows the parameters in a tab. I think this
functionality belongs there better (right?).
I've also made some changes to tw.dynforms:
- I've included a MANIFEST.in so templates, js, icons, etc... are included
in the egg (since setuptools can no longer introspect that info from SVN)
- I've added some sample 'widgetbrowser' directives to the docs to see how
they play with tw.dynforms. Currently the demos are a little bit dull and
some don't event work. I'll try to write a better looking "demo" widget
later. The results are here [2] in case you haven't seen them.
>> > possible though; I can always recode)
>> > 2) Pick up documentation in the params dict (perhaps this isn't
>> I've opened ticket #4 for it.
>
>
> Ok, I've committed a fix.
... and a subtle bug ;) [3]
Alberto
[1]
http://beta.toscawidgets.org/documentation/WidgetBrowser/modules/util.html#widgetbrowser.util.WidgetParameters
[2] http://beta.toscawidgets.org/documentation/tw.dynforms/widgets/index.html
[3] http://beta.toscawidgets.org/trac/tw/changeset/229%3Aa465dd73d971