Server-side system and documentation compatib
Status: Beta
Brought to you by:
gbrault
Menu
▾
▴
Hi,
I'm very intersted in jsp documentation and have in fact developped a concurrent tool (unfortunatly nammed also JSPDoc). The main difference between your and my tool is the server-side orientation of your tool. I would like to know why you've chosen such a process, since it will need a heavy-duty for each documentation generation where a simple program would (as my program does) need only a little work during a little time, for a browsable result that seems as attractive as yours is.
Reading my question, it seems it's a little trollistic. It is not the goal and the only thing I want is a good information on the reason.
Thanks
Riduidel
The reason is very simple: jsp are likely to change very often and unlike javadoc, where you are suppose to propose API which 'should' be quite invariant, Jsp are not.
I agree that this feature is quite heavy in terms of sever load -- I was quite surprised by the performance however... but it should be accessible only to 'administrators' and is not likely to impact that much the server performance.
Th 'directory' feature is cached because it's the one that use much of the CPU. The caching is very simple, using a session variable to hold the directory state and a refresh link to forc reload...
Very cool :) We'll be using it in a number of sites with rather complex JSPs (hence the need). I'd actually developed a 2 page python script that did this (see http://newgate.socialchange.net.au/~jeff/jspdoc/\). I used javadoc-style tags, like @author, @version, which might be easier to get right than XML.
Anyway, when I tried running the war file in Tomcat 4.0.1, I got an error because the JSP page doesn't explicitly import java.io.* (in particular, java.io.InputStream). Some non-conformant servlet containers (Tomcat 3.2.1, and Resin it seems) go and import java.io.*, violating the JSP1.1 spec, p45, where it says:
"The default import list is java.lang.*, javax.servlet.*, javax.servlet.jsp.* and javax.servlet.http.*."
The other question I have is, is there source code available anywhere? CVS is empty, and I couldn't find any non-binary releases on the page.
Anyway, great work!
--Jeff
This will be done in the next weeks, some work still to be done
Thanks fore your interest