On 2/8/07, Ben Sizer <[EMAIL PROTECTED]> wrote: > > On Feb 8, 11:09 am, Christopher Arndt <[EMAIL PROTECTED]> wrote: > > Ben Sizer schrieb: > > > > > Once the developers have done what > > > should have been done long ago, only then can the typical user of the > > > framework be expected to have a decent enough understanding of what is > > > going on to be able to contribute anything of significant worth. > > > > Any contribution is significant, IMHO. Karl has pointed out a few times now > > how > > people can help out without having in-depth knowledge of TurboGears. > > That is true. But I think that a lot of us would really be better > placed to contribute if we felt that there was at least a solid > baseline from which to work. For example, I have a few use cases that, > once I solve them, might be useful for submission to the docs. > However, given that quite often I have no idea why they work, or if > I'm doing everything the right way, I am reluctant to propose such > solutions. We really need API docs, even if they only exist for the > core packages. I admit I don't understand why there seems to be a > problem auto-generating them. How hard can it be to list all the > possible arguments for the expose() decorator and what they do, for > example?
this is already finish, we are having some troubles uploading it to the server I hope it's fix in this week. Until that is done you can use my test system (please don't abuse my bandwidth) http://tg.maetico.com/api/, or you can generate your own with easy_install epydoc and then http://trac.turbogears.org/ticket/104#comment:11 In fact this is one place where users can contribute all you need to know is how a apitool works. (epydoc has a problem with some of the widgets code) As for generating the docs you will be impress of how hard it is to build such a tool for python code being it all dynamic, metaclasses are a problem and some parts of TG are a bit complicated. > > I'd take a look at it myself now, but I can't install TurboGears here, > because it wants an old version of Python. Hopefully somebody will fix > that Real Soon Now. > I believe your windows pc is the one having python25? please don't refer as python24 as *old* is the default on almost all OS, now just step back for 1 min and think what feature python25 has that TG *really* needs, at most I'll say sqlite which is not a good idea for deployment, and any() all() which could be used for identity (they are currently implemented in TG code),and TG needs the "extended" ET. So there is really no advantage here, but ones again svn code already works. > > I think, no-one *demands* anything, we're just asking for help. And yes, I > > think it is perfectly valid to ask mere "users" to contribute. That's what > > Open > > Source is about. Give and take. The distinction between users and developers > > blurs. > > I agree. But Turbogears is quite a complex project, including well > over 25 separate packages last time I checked. Many have different > coding styles. Half of those packages are poorly documented. There is > little way that the average user-developer can dedicate an adequate > amount of time to reading that source code and working out what it > does. Digging through those package boundaries is quite awkward. At > least in C++ I can quickly browse around the source with something > like Visual Studio; is there anything similar for Python? > actually that's not entirely true, most of those packages are small take a look at TurboKid, the ones that really mather are the major kid, SQLobject, Cherrypy, ConfigObj everything else is just used "internally" for example I have never had to touch any C code to fix/implement anything on TG and there is no C code on TG itself just on it's dependencies. > > If you [2] can't help with TurboGears, help another project. Your Karma > > will increase and - who knows - next life you will be re-born as a nice > > little > > mouse instead of a beetle [1] ;-) > > I've contributed several comments to the docs pages, most of which > seem to have been acted upon, which is good. I'd be much happier if it > was in Wiki format and I could refactor some of the overly > unstructured pages as and when I find the time, but it's not. I > appreciate that it may be reserved for a select group of people. > yes me too, check out my lastest post on turbogears-docs about this, I believe reverting to wiki is a good thing because most people like ReST because of <insert reason here> > There's not much else I feel I can do though, especially since my own > Turbogears work is regularly halted by poor documentation. I even > bought the book - sadly through a degree of desperation rather than > desire - but haven't managed to read much of it yet. > > -- > Ben Sizer --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
