[Mono-docs-list] Monodoc aspx .1

Ben Maurer bmaurer@users.sourceforge.net
13 Jul 2003 20:16:37 -0500 

On Sun, 2003-07-13 at 17:50, Miguel de Icaza wrote:
> -                       string res = n.tree.HelpSource.GetText (url, out x);
> -                       ((Browser)browser).Render (res, n, url);
> +                       // The root tree has no help source
> +                       if (n.tree.HelpSource != null)
> +                               res = n.tree.HelpSource.GetText (url, out x);
> +                       else
> +                               res = ((RootTree)n.tree).RenderUrl (url, out x);
> +                                       
> +                       browser.Render (res, n, url);
> 
>     Can you explain me when do we trigger this particular case?  This
> pattern `n.tree.HelpSource != null' is used in a few more places, and
> I
> am wondering why we would have a null HelpSource.
This is the RootTree. That class has no help source. Maybe I should
replace this with if (n.tree is RootTree).

>     Also, these changes are to browser.cs, which is the GUI component
> of
> the Monodoc browser, so am not entirely sure why we need this in the
> first place.
Yeah, this was just a patch to allow those root:/ url's to load in the
browser. They are *not* necessary for the web client.

> * Handling of the "root:" url
> 
>     I like its principle, but it should probably have a different
> name,
> as "root:" gives the wrong idea.
I have no problem with a new name.
> 
> * monohb provider
> 
>     I fail to understand the rationale for most of the changes here,
> could you post a ChangeLog entry, or details?
All the other providers generate content like this:
<h1>this is content</h1>

whereas monohb does this:
<html><head><title></title></head>
<body>
<h1>this is content</h1>
</body></html>

Thus, when we put it inside <html><body> like we do in browser.exe and
web monodoc, it is invalid.

Also, the color of the header had a typo that made it purple in Moz.
> 
> * provider
> 
>     Seems like you got some old code in there;  There is a name_to_hs
> hack there that is never used, so those parts should probably be
> removed.
name_to_hs is used:
@@ -815,7 +817,20 @@
        ///    URL.
        /// </summary>
        public string RenderUrl (string url, out Node match_node)
-       {
+       {
+               if (url.StartsWith ("root:"))
+               {
+                       match_node = null;
+                       if (url == "root:") {
+                               StringBuilder sb = new StringBuilder
("<h1>Welcome to Monodoc</h1>");
+                               foreach (Node n in Nodes)
+                                       sb.AppendFormat ("<a
href='{0}'>{1}</a></br>", n.Element, n.Caption);
+                               return sb.ToString ();
+
+                       } else
+                               return ((HelpSource)name_to_hs
[url.Substring (6)]).GetText ("root:", out match_node);

The hack is meant to allow use to map the name of a provider (eg,
classlib) to the HelpSource for that provider. This way, we can allow
each provider to be responsible for its own root. If you can think of a
better way...I would love it.
>   The changes to populate are also very bizarre, can you explain
> what they are for?  (They reference root:)
Before, each node below Mono Documentation had a url such as "classlib".
now they have "root:/classlib". 
> * attribute patching
> 
>     I still think we should use some mechanism other than JavaScript
> to
> replace the a href targets, because that will not work with
> text-client
> web browsers, like Lynx on Unix.
UNIX?

The problem is that this turned out to be the easiest way to do it. I
would like to do this some other way, but doing it would require more
changes. 

> >       * Install the two patches I have attached. (this is a workaround
> >         for a bug in the runtime with threading). 
> 
> There is only one patch to the runtime, and it changes XmlUrlResolver,
> can you explain the need for this?  Is there a bug assigned to get this
> patch into CVS
This is just a hack to make XmlUrlResolver not freeze inside xsp. There
is a bugzilla for the root issue.


> >       * Create a directory for xsp to work in 
> >       * move browser.exe in that bin/. also cp that file to browser.dll
> >         (this is a hack that we will fix) 
> 
> monodoc now installs monodoc.dll as a system assembly, with the Monodoc
> namespace.
Thank you!


> >       * Compile the attached .cs file, /r:browser.exe. Make sure to
> >         replace /devel/install with your own path. 
> 
> Can you use the .NET configuration infrastructure for this?  So people
> can do this by installing the .aspx file and its configuration files?
Yep. Now that monodoc is a dll, we can have one central config file
(another advantage of having it in a dll). Until we implement that, I am
going to make a quick hack in the hanlder to use reflection to get the
current path.

Install instructions coming as soon as I figure it out...

-- Ben