> Quoting Ray Cromwell ([EMAIL PROTECTED]):
> >
> > 1) design and write objects for parse nodes,
> > and objects to represent LHS and RHS expressions and
> > variables.
> >
> > 2) write parser generator (JavaCC or ANTLR)
> > 3) write evaluator
> > 4) write core library objects/taglets (minimum: if, for,
> > and access to CGI)
> >
> > Steps #1 and #3 are the most work.
>
> You obviously have almost no idea what WebMacro does.
And you obviously can't parse simple sentences. It's like you ignore
and skip over stuff I write, and then interpret it to mean what you
want. I was talking about my implementation of a template
system. Didn't you see that part that said I had written 3 template
systems, one of them a servlet/Java template system years ago? And
that I used JavaCC to do it? And that it took me 16 hours? Do you
really believe I have *NO*, as in *ZERO* ideas about what WebMacro
does? Do you think writing a template engine is some kind of arcane
blackart that any undergrad taking Compiler Theory or Automata
couldn't understand?
If you want to be specific, let's talk about WebMacro. I told
you I had already looked at the source code. I have a pretty good
working knowledge of it's execution flow. From WMServlet, to Template,
ParseTools, Block -> (dispatched to various Directive objects)
1) parse node objects implement Macro interface, non-leaf
nodes called Block used as containers.
2) Uses StreamTokenizer and hand coded parser, with parse
rules implemented via a static parse() function on each directive.
3) Same nodes in parse tree implement write() and evaluate() functions
that perform the required semantics.
4) core library of builtin directives: If, Include, Parse, Foreach, Use, Param,
and Set. Supporting objects for Variables, Boolean expressions, Resource
management, and property introspection.
Places design can be improved:
1) Hardcoded directive array in Block.java should be moved to property file, or some
other easy to configure or dynamic mechanism that doesn't require a recompile.
2) #parse and #include (IncludeDirective superclass) are inefficient,
because they bypasses caching. While the Template method may cache the
parsed template, it doesn't cache *included* content or templates,
therefore #include causes the included file to be re-read everytime the
evaluation phase occurs. Meanwhile, #parse causes re-reading, and
re-parsing.
Thus, the following bit of code is not optimal under WebMacro 0.89.1:
#include "big content"
or
#parse "bigheader.wm"
3) IncludeDirective.write() could be improved by doing
try
{
// FileReader oriented code
}
....
finally
{
// close the file reader
}
Obviously, you could rely on garbage collection to take care of it,
but you could also overrun the file descriptor limit in Unix before
those streams are finalized. On some Unices, this defaults to as low
as 256, which means after 256 web hits and no-gc: kaboom. Especially
on large memory systems or those with async GC turned off.
-Ray
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
