Hi Torsten, i like a lot of the new features.
regarding defining help in classes without the help system loaded - i
think it could be simpler. I am not sure how this would work as you
describe in my example where I want to shove some simple help in the
monticello package. I don't understand the asHelpTopic conversion and
which builder to use etc.
I think it should be possible for help to appear in the global help
browser without having to define a subclass of CustomHelp. This would
make the entry barrier really low for people to be able to document
parts of the system using this help system. For example I have spent
too long on this already ;-)
Can you consider the idea of a PragmaHelpBuilder as an extension to
your system?
I can define a method like this on some class:
helpForThisPartOfTheSystem
<helpTopic: 'Title goes here'>
^'Contents goes here.
foo
bar
wibble'
And then I can find all of these pragmas:
| pragmas topics |
pragmas := ((SystemNavigation default allMethodsSelect: [:each | each
pragmas notEmpty])
select: [:each | each compiledMethod pragmas
allSatisfy: [:eachPragma |
eachPragma keyword = #helpTopic:]])
collect: [:each | each
compiledMethod pragmaAt: #helpTopic:].
topics := pragmas collect: [:each |
HelpTopic
title: (each argumentAt: 1)
contents: (each method valueWithReceiver: nil arguments: #())]
With a bit more annotation we could build classes just like the simple
subclass case of CustomHelp where you only have a few methods on the
class side. i.e just like your metacello example. Then there is no
dependency on CustomHelp, and help comments can go anywhere in our
various package structures for e.g pharo core, dev image. We would
just need to decide on a set of annotations.
thanks,
Mike
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
