About danny help :)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

About danny help :)

Torsten Bergmann
Stef wrote:
>Hi danny
>
>I would like to integrate your help system in pharo so we will have see how we can proceed.
>...
>Yes this is good for my ego :)))

Hey, hey ... and it is not good for my ego if you keep saying it is danny's help system! Ever looked
at the project and code?  ;)


While I appreciate that Danny wants to contribute to the project I think his changes are not
aligned with the original goals, design and ideas.

First and most important: I want a simple model for the help system, which I first provided as  

          HelpTopic
            HelpBook
            HelpPage

after Danny's changes the baseline now looks like this:

          HelpTopic
            DynamicHelpPage
             ClassAPIHelp
             MethodListHelp
             PackageAPIHelpBook
            HelpBook
            HelpPage

I have several problems with these three introduced classes:

  - They do not stand the "is a" inheritance test since a book (PackageAPIHelpBook) now "is a" page (DynamicHelpPage)
  - To make it even worse the class DynamicHelpPage adds three new instance variables (using blocks) totally ignoring the
    ivars inherited from HelpTopic (leaving unused slots in the instances).
  - the three new classes are more intended towards extracting/building the three types of dynamic help informations
    (package, class, method),
    So the behavior is more oriented towards "building" a book or page - but this is what the (yet unfished) builders
    are used for. Therefore the classes are also misplaced.
  - there is no single test provided

Sorry Danny - but your changes look more like a quick way on getting a dynamic help "hacked in" than
a clean design towards a stable Pharo help system!

However - I'm in the midst of refactoring all this and hope to provide an even simpler model than the one
I originally used. Please be a little bit patient before we all jump into this "feature adding thing".


Stef/Danny wrote:
>>I would like to add it in a modular way. Does anybody has a nice idea?
>I am not sure what you mean by modular. It has a Metacello configuration.

Yes, it has a Metacello configuration which currently separates the test from the Core model/UI.
My further work will provide an exchangable and more enhanced UI and no dependency on the Help system itself
(at least for in image docu). I'm currently testing some ideas.

>my point is if you imagine that we want a small system with good packages
>where do we put the helpSystem.

I intend to use pragmas to decouple this. So you could comment your code without having the help system
installed.

We have to make a clean distinction for the help system for:
  - in image documentation on classes/methods/packages/test cases that can also be accessed by the usual tools like browsers
  - big-picture like help (books, tutorials)

I know you are all eager to play with the first in the help system but I think the second has more value
and need for a help system.


>A nice idea on squeak-dev was to add support for a simple structured markup
>language like Markdown in class comments. We could use this to write "big-
>picture" documentation directly in a class comment.

Yes ... but a class comment is as the name implies just a comment for a class. You typically dont write a "big-picture"
documentation in a class comment. If you write a documentation on how to use Streams, Collections or Exception Handling
... which is the class you would use for the comment?

Dont get me wrong: I like well described classes but the Help system should mainly address the "big-picture" documentation
for tools, frameworks, the system, ...

Adding other types like the dynamic API help are easy to integrate/generate.

Another goal is to use the HelpSystem to document a (commercial) software you have written in Pharo or reuse the content for a
documentation appearing on a website.

Danny wrote:
>In a package you put in the most important class a comment that looks somehow
>like this:

How do you measure the importance of a class ... ? ;)


Stef wrote:
>we can load HelpSystem and use it but since we want to have core
>we should get it in Pharo but still make sure that everything in Core is adapted to give info
>to Pharo.

Two simple goals:
  - help is always optional and core could be without it
  - infos provided should not be dependent on the help system itself (for comments)

>In addition I would like to have a tag for promoting test to be list in the help.
><documentation>
>
>Would be nice.

Yes, there are many things that would be nice like generating books/pages from tests or examples
or even dynamically build UML diagrams. We can have that in future. But first we need a simple and good
model we can built on and I'm working on it. Maybe I released too early ...

Thanks
T.



--
GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About danny help :)

Stéphane Ducasse

On Mar 5, 2010, at 9:25 PM, Torsten Bergmann wrote:

> Stef wrote:
>> Hi danny
>>
>> I would like to integrate your help system in pharo so we will have see how we can proceed.
>> ...
>> Yes this is good for my ego :)))
>
> Hey, hey ... and it is not good for my ego if you keep saying it is danny's help system! Ever looked
> at the project and code?  ;)

;)
I noticed it :)


> While I appreciate that Danny wants to contribute to the project I think his changes are not
> aligned with the original goals, design and ideas.
>
> First and most important: I want a simple model for the help system, which I first provided as  
>
>          HelpTopic
>            HelpBook
>            HelpPage
>
> after Danny's changes the baseline now looks like this:
>
>          HelpTopic
>            DynamicHelpPage
>             ClassAPIHelp
>             MethodListHelp
>             PackageAPIHelpBook
>            HelpBook
>            HelpPage
>
> I have several problems with these three introduced classes:
>
>  - They do not stand the "is a" inheritance test since a book (PackageAPIHelpBook) now "is a" page (DynamicHelpPage)
>  - To make it even worse the class DynamicHelpPage adds three new instance variables (using blocks) totally ignoring the
>    ivars inherited from HelpTopic (leaving unused slots in the instances).
>  - the three new classes are more intended towards extracting/building the three types of dynamic help informations
>    (package, class, method),
>    So the behavior is more oriented towards "building" a book or page - but this is what the (yet unfished) builders
>    are used for. Therefore the classes are also misplaced.
>  - there is no single test provided
>
> Sorry Danny - but your changes look more like a quick way on getting a dynamic help "hacked in" than
> a clean design towards a stable Pharo help system!

You are the boss there. I was not aware of the design and I did not look at the code.
I was just reading tests and class comments and I would like to get some of them promoted to help :)

> However - I'm in the midst of refactoring all this and hope to provide an even simpler model than the one
> I originally used. Please be a little bit patient before we all jump into this "feature adding thing".

we are not in rush.

>>>
> Yes, it has a Metacello configuration which currently separates the test from the Core model/UI.
> My further work will provide an exchangable and more enhanced UI and no dependency on the Help system itself
> (at least for in image docu). I'm currently testing some ideas.
>
>> my point is if you imagine that we want a small system with good packages
>> where do we put the helpSystem.
>
> I intend to use pragmas to decouple this. So you could comment your code without having the help system
> installed.

yes this is important
>
> We have to make a clean distinction for the help system for:
>  - in image documentation on classes/methods/packages/test cases that can also be accessed by the usual tools like browsers
>  - big-picture like help (books, tutorials)

you lose me there. ;)

> I know you are all eager to play with the first in the help system but I think the second has more value
> and need for a help system.

ok I guess I got it.
But I'm pragmatic.
        - how to we fill up the help
        - when I here book I know the pain it is to write.

>
> A nice idea on squeak-dev was to add support for a simple structured markup
>> language like Markdown in class comments. We could use this to write "big-
>> picture" documentation directly in a class comment.
>
> Yes ... but a class comment is as the name implies just a comment for a class. You typically dont write a "big-picture"
> documentation in a class comment. If you write a documentation on how to use Streams, Collections or Exception Handling
> ... which is the class you would use for the comment?
>
> Dont get me wrong: I like well described classes but the Help system should mainly address the "big-picture" documentation
> for tools, frameworks, the system, ...
>
> Adding other types like the dynamic API help are easy to integrate/generate.
>
> Another goal is to use the HelpSystem to document a (commercial) software you have written in Pharo or reuse the content for a
> documentation appearing on a website.

ok

>
> Danny wrote:
>> In a package you put in the most important class a comment that looks somehow
>> like this:
>
> How do you measure the importance of a class ... ? ;)
>
>
> Stef wrote:
>> we can load HelpSystem and use it but since we want to have core
>> we should get it in Pharo but still make sure that everything in Core is adapted to give info
>> to Pharo.
>
> Two simple goals:
>  - help is always optional and core could be without it
>  - infos provided should not be dependent on the help system itself (for comments)
>
>> In addition I would like to have a tag for promoting test to be list in the help.
>> <documentation>
>>
>> Would be nice.
>
> Yes, there are many things that would be nice like generating books/pages from tests or examples
> or even dynamically build UML diagrams. We can have that in future. But first we need a simple and good
> model we can built on and I'm working on it. Maybe I released too early ...

No this is interesting to get ideas.
For the UML I would like to have a simple sccripting descriptoin so that we can define it.


>
> Thanks
> T.
>
>
>
> --
> GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
> http://portal.gmx.net/de/go/dsl02
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project