Quoting Carlos Amengual ([EMAIL PROTECTED]):
> Webmacro's constructs are probably the most useful out there, but nobody
> saves you from having to learn the "#foreach", etc. In your web pages I
> find things like "No programming issues in the template", and then
> "Script language easy to learn and use by page designers". But writing
> scripts is programming.
Think of WebMacro script as the HTML stlesheet language for Java objects.
http://webmacro.org
WebMacro templates contain no programming issues in the sense that
they focus 100% on rendering a page, and have nothing to do with
the generation or manipulation of data structures, algorithms, etc.
You do not write a WebMacro application in WebMacro script. You write
it in Java. WebMacro script is the rendering language you use to
construct the HTML once the programming issues have been dealt with
(in pure Java servlet code).
I agree that learning a script language just for the web is absurd,
given the option of programming in a fully general language like
Java instead. This is just as fundamental to WebMacro's design as
my statements about templates:
-- Use Java to implement your logic and session management
-- Use templates (WebMacro script) just for the rendering to HTML
Trying to render HTML in Java would be like trying to write complex
algorithms and processing code in WebMacro script--ie: wrong.
In order to traverse and render normal Java objects, you do need
some control structures. However, they are kept as simple as
possible--powerful enough to walk through an object's properties,
but not powerful enough to implement business logic.
The only control structures are:
#foreach $thing in $list {
<ul>$thing
}
and
#if ($condition) {
include this
} #else {
include that
}
Notice that these require the least amount of "programming" knowledge
possible. The loop doesn't have an invarient or increment or even
a condition. It assumes the Java programmer provided only the
objects that were wanted.
Now, since WebMacro allows you to plug in your own directives, and
call arbitrary methods, you could break out of this mindset and do
more general things if you wanted to, and knew what you were doing.
However, you are encouraged not to do that--you're encouraged to
write the guts of your servlet in regular old Java.
I think this requires less programming background than the XML
alternatives. XSL, and especially DSSSL, expect you to have a good
grasp of functional programming concepts, including recursion. Either
that or you must give up on doing anything complex in your rendering.
Personally I think WebMacro is a better XML transformation and rendering
language than either of those. I intend to work on making that a more
legitimate claim once 1.0 is out, by building in better DOM support
on the back end--so that WebMacro variables will be references into
an XML document. Hopefully the XLINK vs XPointer debate will be
settled by then (if it hasn't been already).
> A good separation of layout (style sheets), document structure (XML),
> and programming logic (Java) would be perfect, but we still do not have
> it.
I think if you view WebMacro is a style sheet language which operates
on regular Java objects, we're getting close.
Consider that XML can be represented with a Java API and you'll see
where I am headed.
As for document structure: if your application really is 99%
document centric, XML based approaches are definately a big win.
This opens up a whole new class of problems which people previously
rarely attempted to solve.
However, 90% of servlets are not document centric. They're centered
around traditional, simple objects like Customer, Account, Product,
User, etc., likely stored as a row in a table somewhere. Even most
web message boards have a shallow, simple structure.
You can represent these things as XML, but it's usually simpler
not to.
On the other hand, technical manuals, reports, etc., are not easily
represented the traditional way. XML/SGML becomes a huge win, and
has dominated this kind of application for over 10 years. (I know,
this is the field I worked in until quite recently).
> Meanwhile, if I had to write applications that only comprise the kind of
> things where your excellent webmacro is appropriate, I certainly would
> use it, but for many uses I find it easier to go for other solutions
> that do not require you to have yet another scripting language (even a
> simple one) hanging around.
Well there's not much left. XML is out; XSL/DSSSL are much more
complex scripting languages than WebMacro's script language.
Don't let the functional programmers who created them convince
you that you don't have to be a programmer to write scheme
code. It's a myth.
You'll find you can only write trivial stylesheets without having
to work with XSL/DSSSL as a functional programming language.
I know I'm a bit of a heretic in the XML/SGML world for saying
so, but a simpke procedural language is better suited to manipulating
document structure than a functional language.
Functional languages often pretend not to be languages, which really
bugs me, because they are far from simple for non-trivial work. Only
a programmer would think scheme is simple.
WebMacro Servlet Framework
http://webmacro.org
Justin
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
