Forum OpenACS Development: Re: The future of OpenACS

Collapse
10: Re: The future of OpenACS (response to 8)
Posted by Malte Sussdorff on
Hi Stefan, /xotcl is a nice Browser, sadly it does not help with my specific request at all. I need to move up the class hierachy and show all methods (even the undocumented ones) and when I reach it, I have no way of accessing the source of the class function let alone see where it (originally) is defined. I am aware that you can overwrite them on the fly, so the "where do they come from" might not be correct, but at least showing the body of the function would help (http://cognovis.de/xotcl/show-object?show%5fsource=0&object=%3a%3axowiki%3a%3aPage&show%5fmethods=2)

The above works nicely when a function is documented with ad_instproc, sadly it miserably fails for anything else.

Furthermore, when I type in e.g. "get_object_type", I see the generic class procedure (which is documented, so things are fine). Sadly, unless I know that a FormPage is a CrItem, I would not understand what xowiki::FormPage get_object_type does. So, I would love to see, if I type in "xowiki::FormPage get_object_type" that the API Browser finds me the Generic::CrItem get_object_type procedure and displays this (probably along with a hint that this is the version being used by xowiki::FormPage).

Does this make my problems a little bit clearer with the currently provided documentation? I do have the slight feeling, regardless what can be done with the API Browser and the XoTCL browser we still need make a lot more procedures using ad_instproc and Classes using the -ad_doc parameter for us to really "digg" XoTCL in OpenACS.

And I agree with Gustaf that on the XoTCL Browser having "Show all methods including inherited ones" will probably lead to pages of procedures / methods being displayed, but at least it helps us reading the code.

Not having developed in Java or other OO languages, how do the IDEs for them solve the problem of inherited Methods and the documentation for them. Any Pointers?