jvanzyl 00/10/14 12:20:44 Modified: xdocs install.xml todo.xml user-guide.xml Log: Edits. Revision Changes Path 1.6 +5 -2 jakarta-velocity/xdocs/install.xml Index: install.xml =================================================================== RCS file: /home/cvs/jakarta-velocity/xdocs/install.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- install.xml 2000/10/05 02:12:21 1.5 +++ install.xml 2000/10/14 19:20:43 1.6 @@ -15,7 +15,9 @@ <s1 title="Installation"> <p> - Everything required to build Velocity comes with the distribution. + Everything required to build Velocity comes with the distribution, which + be obtained via <link href="http://jakarta.apache.org/getinvolved/cvsindex.html">CVS</link> + or <link href="http://jakarta.apache.org/builds/jakarta-velocity/nightly/">downloaded</link>. </p> </s1> @@ -23,7 +25,8 @@ <s1 title="Compiling"> <p> - On Unix/Linux, execute the following script in the velocity/build directory: + On Unix/Linux, sh to the velocity/build directory and execute the following + script: </p> <p> 1.6 +21 -21 jakarta-velocity/xdocs/todo.xml Index: todo.xml =================================================================== RCS file: /home/cvs/jakarta-velocity/xdocs/todo.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- todo.xml 2000/10/13 16:50:14 1.5 +++ todo.xml 2000/10/14 19:20:43 1.6 @@ -16,12 +16,11 @@ <p> This is an informal document describing what needs to -be done in the Velocity code base, and the -Velocity documentation. If you need more detailed help, please -send mail to the mailing list -(<link href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</link>) -and ask your specific questions there. The list below is vaguely in order of -importance. +be done in the Velocity code base and the +Velocity documentation. If you need more detailed help, or have specific +questions, please send mail to the mailing list +(<link href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</link>). +The Todo list that follows is roughly in order of importance. </p> </s1> @@ -31,7 +30,7 @@ <strong>Runtime API</strong> <br/> The Velocity Runtime is the single access point for all - of Velocity's functionality. A standard API for the + Velocity's functionality. A standard API for the Runtime should be defined so that in the span between the 0.5 Milestone release and a 1.0 release, the Runtime API changes as little as possible. @@ -71,7 +70,7 @@ <strong>Sample Applications</strong> <br/> Any type of sample application would be useful to - help kickstart new developers get acquainted with + help new developers get acquainted with Velocity. Any suggestions are welcome. <p/> @@ -89,7 +88,7 @@ <strong>Developer Guide</strong> <br/> This would be a guide for developers who would use - Velocity as a stand-alone servlet tool, or in conjuction + Velocity as a standalone servlet tool, or in conjuction with a servlet controller framework like Turbine. <link href="mailto:[EMAIL PROTECTED]">Jason van Zyl</link> is currently working on this guide, but any and all suggestions @@ -111,13 +110,14 @@ It would be good to have a discussion about how objects in the context should be cached, how the caching should be specified, and who should control the - caching: the designer by specifying something in the template, the developer - by place expiry times on objects placed in the context, - or a third party like a content manager. For example, + caching: the designer, by specifying something in the template; + the developer, + by placing expiry times on objects placed in the context; + or a third party, such as a content manager. For example, say an array consisting of a top 10 list of books is placed in the context. This top 10 list might be valid for a 24 hour period: how should that be specified? Say - a content manager decides that this list is now valid + a content manager later decides this list will be valid for a week. Do they tell the designer, who in turn changes the template, or could we provide a mechanism that would allow a content manager to change the default expiry time @@ -141,7 +141,7 @@ <strong>UML Overview</strong> <br/> It would great to include a set of comprehensive - UML diagrams that describe Velocity in order to + UML diagrams that describe Velocity. This would allow new developers to get up to speed quickly. <p/> @@ -177,7 +177,7 @@ <strong>Context Tools</strong> <br/> - What kind of tools might be good to add to Velocity. There + What kind of tools might be good to add to Velocity? There are several utilties that have been created in Turbine that might be good to move over to the Velocity code base. <p/> @@ -185,7 +185,7 @@ <strong>Syntax Dumper</strong> <br/> Right now there is a primitive syntax dumper in the Velocity - code base, but it could be improved. This tool is very helpful + code base, and it could be improved. This tool is very helpful in debugging, and it is also good for creating directives. It basically has a simple dump method that is used for all the AST node types. It would be good to tailor dump methods @@ -195,7 +195,7 @@ <strong>Syntax Checker</strong> <br/> - It would be good to have a standard syntax checker. Something + It would be good to have a standard syntax checker, something that would find all syntax errors and report them to the designer in some intelligible format. This tool could be hooked into various designer tools like DreamWeaver. @@ -213,8 +213,8 @@ <strong>Compiler</strong> <br/> It would be great to have a template compiler. There is a great - utility call JavaClass that provides a very clean and simple way - to create class files; there is also some byte code generating + utility called JavaClass that provides a very clean and simple way + to create class files, and there is also some byte code generating code present in the DynamicJava package that could be utilized. <p/> @@ -228,10 +228,10 @@ <br/> This is something that has been discussed on the Turbine list. Allowing Context building classes to be written - in JPython, Rhino or another scripting language. This would + in JPython, Rhino or other scripting languages would dramatically improve development time and might allow technically proficient web designers who are familiar JavaScript to create - an entire servlet solution with Velocity. And as most of these + an entire servlet solution with Velocity. As most of these scripting solutions provide a compiler, performance would still remain at an acceptable level. <p/> 1.4 +5 -5 jakarta-velocity/xdocs/user-guide.xml Index: user-guide.xml =================================================================== RCS file: /home/cvs/jakarta-velocity/xdocs/user-guide.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- user-guide.xml 2000/10/13 18:47:18 1.3 +++ user-guide.xml 2000/10/14 19:20:44 1.4 @@ -17,17 +17,17 @@ <p> This guide is meant to provide an easy way for designers to get aquainted with Velocity. Velocity may be used as a - stand-alone servlet framework, or may be used in conjuction - with another servlet framework like - <link href="http://java.apache.org/turbine/">Turbine</link>, - but in both cases a designer will be using the Velocity + standalone servlet framework or in conjuction + with another servlet framework such as + <link href="http://java.apache.org/turbine/">Turbine</link>. + In all cases a page designer will use the Velocity Template Language (VTL) to incorporate dynamic content into a site design. </p> <p> The VTL is meant to provide the easiest, simplest, and - cleanest way to render dynamic content in a page design. + cleanest way to render dynamic content in a web page. </p> </s1>
