> I am with Jorge on this one, while you are testing it just use a kid > page that displays the widget. Automatically solves the reloading and > too-much-stuff-on-a-page issues. AFAIK there has been discussion about > putting some pagination on the widget list, but that will be in an > upcoming release at the earliest.
How to do so? Did you already try a tg-admin quickstart -t tgwidget yourself? If not - you maybe aren't aware that there is no start-script whatsoever, you basically create an egg. Of course I can create a new webapplication just for testing my widget project. But first of all, the toolbox widget list mechanisms already _allow_ for convenient, self-embedded rendering. There is everything available already. And as my answer to my own post says, obviously somebody also felt the need to restrict the display of widgets to just one. And second, it would render the whole approach somewhat moot if I need a special webapp to test a widget, then I'd just go for the webapp. Beside that, both approaches won't help with the reloading-on-code-change-issue, if I'm not mistaken. Because a type tgwidget-application is basically a deployed egg, and just as touching any file in the python distro doesn't trigger a reload, changing the egg-contents won't do that as well (unless one takes special measures). To summarize: I think having a convenient testbed for widget development would be a good idea. I don't care too much about where it lives, but if it _is_ integrated in the toolbox, the advantage to me clearly is that a developer is more encouraged to package her widget to be usable out-of-the-box. Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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 -~----------~----~----~----~------~----~------~--~---
