Hi,

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/field...

Alberto Valverde schrieb:

It shows. Very good looking site, indeed!

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

[1] http://trac.edgewall.org/wiki/TracMercurial

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

Hi,

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 :-)

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.

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
//

Hi,

Ok, done it. Dead easy in the end, beats CVS branching hands down. What
was I scared of? :-)

Paul

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.

hehe, tw.org eats its own food ;)

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.

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/thr...

Oops, seems you did this while I was writing the post I said it would be
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

Thanks :) Most credit should go to Daniel who is the theme's author.
Yep. You can see how all this is tied up in
http://beta.toscawidgets.org/hg/twWebSite if interested.
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

Mark Ramm schrieb:

Thanks, good to know.

Chris

Hi,

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.

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.

Let me know when you do - I'm waiting with baited breath :-)

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 :-)

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

Ok, I'll try to write a demo for the widgetbrowser for it later today.

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.

Sure :)

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.
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.
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.
It's an improvement over the current kludgy implementation which I
wanted to do sometime anyway so sure, lets make it the default.

(...)
BTW, tw.org is looking for backup sysadmin volunteers in case I
hibernate again... Sharing servers with tg.org will also help :)

Alberto