Coding Critique is the place to post source code for peer review by other members of DevNetwork. Any kind of code can be posted. Code posted does not have to be limited to PHP. All members are invited to contribute constructive criticism with the goal of improving the code. Posted code should include some background information about it and what areas you specifically would like help with.
Popular code excerpts may be moved to "Code Snippets" by the moderators.
Hope to get more feedback than with my previous library fjor
I've been working hard at making documentating coding efforts as easy as possible. The result is Vidola. It allows to write your in an easy format (a Markdown extension) and transfrom this to documentation for the project.
Of course I eat my own dog food. Here is an example page written for Vidola:
The thing about these systems is that the reason to keep the content in markdown is so you can generate multiple outputs (e.g. HTML, PDF, Window Doc, manpage, etc.). If that's not the goal and all it does is convert markup then it is just one extra layer. So why not just use HTML?
I started with HTML and it didn't feel like writing documentation should feel. I could live with writing tags but writing about code proved too annoying. Same with docbook.
I guess I was wondering why someone should add an extra build step to their documentation and also need to learn a new syntax when they already know HTML -- just because "Writing ____ in HTML is annoying."
Christopher wrote:I guess I was wondering why someone should add an extra build step to their documentation and also need to learn a new syntax when they already know HTML -- just because "Writing ____ in HTML is annoying."
Hehe, I prefer this extra build step to be done programatically and not manually by typing "<" everytime. The extra build step is either using Vidola , or manually writing HTML around the documentation and converting entities when writing about PHP and/or HTML. I think in both ways this step is done.
That brings me to the second argument. I believe learning (and how much is there to learn?) Markdown is worth the effort compared to a lifetime of converting entities within code tags.
Ok ... I am just pestering you to see how strong you reasons are. It looks like an interesting library. Have you separated the pure Markdown parser from the documentation part so it can be used stand-alone?
It uses a list of patterns, pre/post processors to get the job done. So it is customizable also. I decided on using the power of PHP DOM. Disadvantages of this approach were that it does nasty thing with entities on moments you don't want it. The speed of processing is probably also very very low.
Christopher wrote:Just looked at the code a little. Does AnyMark need a dependency on Fjor? Or is there another way to achieve this outside of AnyMark?
It does need Fjor. It would not be much work to wire it by hand and add this as an option. However, Fjor is also used for instantiating the patterns. I don't know if anyone could be bothered to create these manually and add them to the \AnyMark\Pattern\PatternList.
Christopher wrote:Just looked at the code a little. Does AnyMark need a dependency on Fjor? Or is there another way to achieve this outside of AnyMark?
I've added to possibility to install through composer. Maybe that makes it easier not to care about Fjor since that is taken care of automatically by composer.