Hello, > "In the future we will have an ASP.NET front-end to present the > documentation > on the web as well". Is anyone doing active development on that front? Does > anyone have a plan, or even just quick notes on what's required to achieve > this?
Nobody is working on this right now. > Is there currently a relatively simple (don't mind if it's ugly) known hack > that I missed that would let me deliver Monodoc content on the web in a > matter > of minutes (an hour would do :))? For the "1 hour hack", I suggest this: * Monodoc can generate HTML. * The urls that Monodoc generates are Monodoc-urls, so they need to be mapped into some sort of cgi-bin to re-query things. * The HTML we generate should hopefully be processable with an XML/XSLT processor. So you only need to rewrite urls that do not start with http:// to include some sort of processor. So things like: <a href="T:System.Char"> Needs to be changed into: <a href="cgi-bin/run-monodoc?T:System.Char"> Or something along those lines. > Looking at the source I figured the easiest way, if using only the ECMA > Provider (that's the only one I need myself...), would be to modify > mono-ecma.xsl in order to prepend a cgi script in front of URLs, such as > "monodoc.cgi?", and then have a cgi script that invokes > "monodoc --html QUERY_STRING". Something like that would work too. > The more generic way would be to have Providers support URL prepending, and > have each of them implement it in whatever way it needs to (which, in the > ECMA Provider's case, would require modifying the XSLT amongst other > things...). > > I believe this may be required no matter what, even if using ASP.NET instead My feeling is that this should be handled by an upper layer processor. Miguel _______________________________________________ Mono-docs-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-docs-list