On Tue, Jan 6, 2009 at 10:54 AM, Christopher Arndt <[email protected]> wrote: > > Jorge Vargas schrieb: >> Yes I think a TG app for this should be a better solution. In fact I >> think we should have 2 app (or instances of the same app) >> >> 1- a pastebin-like app (I plan to finish my port of spammcan to tg2 for this >> 2- a snips app >> >> The difference between the two is simply the use, ideally we should >> have "throw away pastes" at #1 and "important" pastes (probably with a >> big rst text field) with the explanation for snips, that will serve as >> mini-tutorials. > > What the about revision control that a wiki offers? A pastebin app is > simple, but a document management system (even the most simple one), is > a bit more involved. > for the most complex examples (for example wiki20 and my tgextjs sample) I believe the repo + sphinx is the way to go.
The recepies app is for short code (less than 100 lines) which is normally version specific, and answers quick questions, some that come to my mind. - how do I run trac/mercurial,etc from inside TG2? - how do I run trac/mercurial,etc from inside TG1.1? - how can I return json from my app? - how to use jsnonify? - how to write a file upload & download controller - deployment script for webfaction - monitoring script of paster - integration with deliverance (this may be a little more work) - how to enable auth-related unitests - etc. The point is, or my "general idea" is that everything will be stages of complexity, where more complexity = more useful example. So for example a quick one of will be born as a pastebin-like post, if that provides to be very useful it will jump into a "snip", where someone (maybe not even the original author) will write a mini-tutorial explaining it, and probably provide more context (IE: instead of just the controller code, add the template code to use it), and if that turns out to be a very valuable resource then it should be migrated to a hg repo(or svn) + sphinx source, by this point someone is probably an active maintainer of the sample and it could/should be integrated into the buildbot's tests to see if everything works out of the box. Now of course the key for all this to work is keeping text formats in sync, which is why we should use rst everywhere. As you can tell not all examples need to go to all stages but I think having a simple "middle ground" app is a nice thing to have and that could be keep simple (without getting into the document management tasks) by making sure the samples stay version specific and simple. I think the following compromises will keep that db small, clean and useful. (of course these are conventions not really enforced by the app) A snips - it contains the following fields (think of the form) a code textfield (maybe several for multiple file snips), a title, a description (In rst), a set of tags, a rating. - must be short (as I said above -100 LOC) should be a good compromise, anything bigger deserves a repo+sphinx version. - the app itself could have, comments on snips, a "copy snip to new" (to track history of the snip), an ok for version x.y.z, so we could detect broken snips with new versions and provide fixes. - it must indicate the version it was written against - there is no guarantee it will work with trunk/current - it's not part of the maintenance work by tgdevs (other than keeping spam at bay) My idea predates, pylons new site but a good explanation of the difference can be found on their links. http://beta.pylonshq.com/snippets http://beta.pylonshq.com/pasties > > Chris > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Docs" 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-docs?hl=en -~----------~----~----~----~------~----~------~--~---
