clethrill said:
Only just noticed this, happy to help out where and when I can
@clethrill feel free to jump in and modify / add content where ever you can. Don't worry about starting things you can't finish, it ok. others will help round out content. just capture what you feel is important.
this should be a more user friendly address. The old address still works, but i recommend you begin using this one, as eventually I will retire the old one.
designers and developers section almost cover all that's covered in the official doc site.
I'm doing quick guide on writing application as i am making one. along the way will fill in infos on all the main classes (API section) as i read them to understand applications. Already covered Gdn_ApplicationManager.
Jongos said:
designers and developers section almost cover all that's covered in the official doc site.
I'm doing quick guide on writing application as i am making one. along the way will fill in infos on all the main classes (API section) as i read them to understand applications. Already covered Gdn_ApplicationManager.
will need reviews and corrections.
i've been trying to review as i notice new content. mostly making typographical corrections. you're way ahead of me on the technical content.
Presenting all info in table form or should the table contains only the basic info and the rest in it's section?
If in table form, the space might be restricted.
If all method is in their own subsection, might be a bit harder for brain to digest (that's how it seems to me). And a method prone to be left out when checking it's validity after a new update is available.
like, an important methods (those commonly used, esp. those in Gdn_Controller) might need a good elaborate explanations and examples.
I wouldn't re-invent the wheel. Code documentation should be done with code documenting software.
Wiki should be more about how to, but teaching general php is a bit beyond its scope. However the code doc could be linked.
There is already in-line documentation, although some of it is incomplete, and occasionally incorrect, a code documenter should be able to pull this out of the code base.
I've already made a doxygen doc (i shared a download link in this forum), but a lot of methods is missing inline documentation. I had to include source code to it, but then it's hard to read. Try generate one or download the one i shared. It's helpful in visualising the relationship between classes but not in describing what a class/method do.
Methods/params that I don't understand or is not so clear what it's about even after jumping from file to file, hopefully someone would explain in plain term. Setting a breakpoint in debugger and try to trace thru trace stack is very time consuming. Add sample output, etc.
It's a wiki, anyone can contribute. You dont have to have access to hbf server filesystem to edit the docs, unlike a generated docs.
I'm not expecting the whole Garden library would be documented, just the fundamentally important ones that matter to most apps and/or plugins.
Regarding PHP :
I guess you're talking about the Help for Learning Programmers, it's just merely to tell them that such a concept exist.
It's from my own experience, trying to learn OOP & Framework and stuck again-again in 10 years, because it simply didn't register to me that concepts of software pattern etc. exist.
So when i tried to learn stuffs like Joomla, I went like "wtf, what kind of code is this, how can this work, just when do the classes got instantiated?" simply because I didn't know there was such a thing as Factory pattern and that is not covered in any OO book I've read. No one cared to say "joomla use the factory pattern in".
It's not gonna teach much, just links and excerpts, and how it is applied in Vanilla.
When i say "Learning Programmers" it includes me, and i put it so i could put my notes/bookmarks to share with others.
Comments
done.
I continue to be amazed at the progress you guys are making on the content.
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
Only just noticed this, happy to help out where and when I can
@clethrill feel free to jump in and modify / add content where ever you can. Don't worry about starting things you can't finish, it ok. others will help round out content. just capture what you feel is important.
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
and the path to the wiki is
http://www.homebrewforums.net/vanillawiki/
just posting it again so you don't have to search through this thread to find it.
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
@hbf
some padding would be nice. to the code box would be nice.
same css selectors. padding : 12px;
Ok
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
hehe.. it's blue now! I'm loving it!
been thinking about it too but thought too much to ask.
nice!
******** NOTE *********
I've moved the wiki to a new address.
http://vanillawiki.hombrewforums.net
this should be a more user friendly address. The old address still works, but i recommend you begin using this one, as eventually I will retire the old one.
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
designers and developers section almost cover all that's covered in the official doc site.
I'm doing quick guide on writing application as i am making one. along the way will fill in infos on all the main classes (API section) as i read them to understand applications. Already covered Gdn_ApplicationManager.
will need reviews and corrections.
i've been trying to review as i notice new content. mostly making typographical corrections. you're way ahead of me on the technical content.
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
Cannot get to your new url three posts up, is it live?
There was an error rendering this rich post.
yes, it's live for me. please try again, maybe the DNS just hasn't updated on your end?
Is anyone else having trouble reaching the new address?
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
AH.... Typo in the post!!!
http://vanillawiki.homebrewforums.net/
I was missing the 'e' in 'home'
my mistake!
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
i would edit the original post but, alas, i can not.
Vanilla Wiki, Tastes Great! 31,000 viewers can't be wrong. || Plugin Development Explained
Can't decide the best way to document a class....
How do we want a class documented?
Presenting all info in table form or should the table contains only the basic info and the rest in it's section?
If in table form, the space might be restricted.
If all method is in their own subsection, might be a bit harder for brain to digest (that's how it seems to me). And a method prone to be left out when checking it's validity after a new update is available.
like, an important methods (those commonly used, esp. those in Gdn_Controller) might need a good elaborate explanations and examples.
I wouldn't re-invent the wheel. Code documentation should be done with code documenting software.
Wiki should be more about how to, but teaching general php is a bit beyond its scope. However the code doc could be linked.
There is already in-line documentation, although some of it is incomplete, and occasionally incorrect, a code documenter should be able to pull this out of the code base.
grep is your friend.
phpBB3 uses PHPDoctor for documenting its code debase. This might be an option, or some other.
grep is your friend.
Regarding the Classes :
reason i want to cover classes in the wiki :
I've already made a doxygen doc (i shared a download link in this forum), but a lot of methods is missing inline documentation. I had to include source code to it, but then it's hard to read. Try generate one or download the one i shared. It's helpful in visualising the relationship between classes but not in describing what a class/method do.
Methods/params that I don't understand or is not so clear what it's about even after jumping from file to file, hopefully someone would explain in plain term. Setting a breakpoint in debugger and try to trace thru trace stack is very time consuming. Add sample output, etc.
It's a wiki, anyone can contribute. You dont have to have access to hbf server filesystem to edit the docs, unlike a generated docs.
I'm not expecting the whole Garden library would be documented, just the fundamentally important ones that matter to most apps and/or plugins.
Regarding PHP :
I guess you're talking about the Help for Learning Programmers, it's just merely to tell them that such a concept exist.
It's from my own experience, trying to learn OOP & Framework and stuck again-again in 10 years, because it simply didn't register to me that concepts of software pattern etc. exist.
So when i tried to learn stuffs like Joomla, I went like "wtf, what kind of code is this, how can this work, just when do the classes got instantiated?" simply because I didn't know there was such a thing as Factory pattern and that is not covered in any OO book I've read. No one cared to say "joomla use the factory pattern in".
It's not gonna teach much, just links and excerpts, and how it is applied in Vanilla.
When i say "Learning Programmers" it includes me, and i put it so i could put my notes/bookmarks to share with others.
http://stackoverflow.com/questions/3052036/how-to-include-custom-files-in-doxygen
grep is your friend.
@hbf
can you please add this extension, http://en.wikipedia.org/wiki/User:MarkS/Extra_edit_buttons
inserting code/small/pre/ tags manually repetetively is quite irritating...