Justin Wells wrote:
> Quoting Ray Cromwell ([EMAIL PROTECTED]):
> > Well, he might be able to learn it in a day, but would he neccessarily
> > use it in the best way without experience? Would he use #parse
> > directives effectively, or cut-and-paste? Would he rely on $Request
> > too much, or delegate to the servlet?
>
> Here is the entire set of WebMacro directives:
>
> if, foreach, include, param, parse, set, use
<Justin goes on trying to demonstrate how simple the syntax, and the
the small number of constructs needed to learn>
Justin, you completely miss the point. I don't care if WebMacro only
had 2 primitives in its language. Lisp/Scheme are also so simple, you
can fit the entire language spec on a single page. Lisp-like languages
are utterly simple to learn, but take a lifetime to master.
(Actually, this was once said about games -- "The best games are simple
to learn but take a lifetime to master")
You focus 100% of your attention on the business logic, and totally
overlook the problem of designing and maintaining all the views,
which are also non-trivial. Large scale view architecture, even
with a simple substitution language is still non-trivial.
WebMacro utterly lacks anything to promote view reuse, or code
parameterization. Maybe in the future, you will add macros and the
ability to use "macro libraries" (so WebMacro can be competetive with
1993 technology) which can be a repository of knowledge that the view
coders can build upon over and over, but right now, you're stuck with
#parse and cut-and-paste.
WebMacro is probably one of the least useful template systems out
there right now when you compare it to those that went before.
Thus, since WebMacro lacks macros (ironic, huh), and lacks the
ability to build up parameterized libraries, it means that
the truly experienced users are going to have code that looks like this:
#parse "header.wm"
Here's your data Mr. Smith
#parse "TableModelRenderer.wm"
Do you wish to change any of the above?
#parse "PropertySheetForm.wm"
#parse "footer.wm"
However, since you can't pass parameters, these script fragments will have
to make assumptions about global variable names, which is a *horrible*
idea. I'm glad your adding macros to WebMacro, but it doesn't
make up for the fact that right now, it lacks them, which hurts
your argument. Of course, until I see your macro design, I will
withold further comment, but hopefully, macros will be parameterized
with local state.
All large sites have segmented pages like these, where the views are built up out
of *components*
Anyway, let's not even talk about WebMacro's total lack of even basic arithmetic
expressions. I suppose your theory is that, if I need to add "1" to a number,
I should delegate that to that poor overloaded Java servlet right? And that
WebContext object is properly loaded with properties now like $myval, and
$myval_plus_one, and $myval_div_8. BTW, are you still sure that the
controller should be in the Servlet? Traditional GUI design experience
actually suggests it should be in the view. BTW, can WebMacro even
do *boolean expressions*? Let me check the source, oh ok, I see
them in Condition.java. A little more up-to-date documentation
would also help your cause.
Maybe you think I'm being inflammatory in tone, but if you weren't flooding
the JSP and Servlet lists with propaganda, I wouldn't be. I mean,
I read on the servlet lists how you and the open source army are going
to destroy JSP in features. You started a war that didn't even need
to exist. JSP is barely being used by anyone, and you are trying
to heavily sell and market it against it.
> JSP is *much* more complex than WebMacro templates. The complexity in WM
> is all on the Java side--and that's the *Java* side, you only need a
> good Java programmer. WM experience will not be so important.
If it's not important, why not eliminate it all together? Why should I
force my view people to learn an underpowered variable interpolation
language, when I could instead, output XML and get them a nice GUI
tool to style it?
The weird thing about your arguments is that you postulate a person
unskilled enough to handle Java code or JSP, who is primarily
designing nothing but page layout, but who would rather hack
HTML + proprietary syntax instead of using a real page layout
tool, like commmercial RAD tools. Have you ever worked with
a team, with real graphic artists? Here's a hint: the people
who do the nice pretty little HTML layouts don't like editing
HTML. They like immediate visual feedback, and are used to
laying things out with tools.
> > > It's things like JSP where you might have to worry whether your hire
> > > has previous experience or not, because it builds a new architecture
> > > that limits the value of ordinary Java experience. WebMacro doesn't
> > > do that.
> >
> > Oh please. JSP's are servlets.
>
> Plus tag libraries, special codes, methods of invocation, property inspect,
> and a lot of other junk that is not nearly as simple as WM. Jason's article
> is a pretty good overview of the difference in complexity between WM and JSP.
Ultimately, they are compiled to servlets. JSP's are nothing more than
syntactic sugar for including large amounts of HTML in a servlet,
because it is a pain to type
out.println("<img src=\""+filename+"\">");
and then recompile.
And by being servlets, JSP's will blow WebMacro right out of the
water in performance and scalability.
>
> There is, however, no such thing as an XML developer. At least not in
> my vocabulary. I also don't talk about "HTML programmers".
Well, according to Jason, evidently, typing "/>" is much harder than ";",
so I guess I must hire people with XML experience or they won't be
able to use JSP tag libraries since "/>" is too difficult.
Nevertheless, you are wrong about XML developers.
> Knowing XML syntax entitles you to understand
>
> <document><title>hello</title>...
>
> it does not entitle you to understand how to iterate through a loop in
> JSP, or quickly understand that, if you have no previous programming
> or scripting experience.
No, it entitles you to understand *document design* , *parsing*, and
writing transformations. But you really don't want to put
XML+CSS, XML+XSLT, or XML+Java transformation up against WebMacro do
you, in terms of cleanness of separation between view and data model?
Not to mention that CSS/XSLT are a *declarative* programming paradigms
that are much easier for people to understand, and much easier to
write editing tools for.
It's very simple: Servlet/JSP -> XML + (transformation) -> HTML, XHTML, HDML,
WML, Chinese, Japanese, DHTML, PDF all without anyone having to understand
variables, properties, method calls, contexts, global state, etc.
#set is probably the single most damning primitive in the entire WM
definition. It destroys the whole separation argument you keep making,
but perhaps you are unaware of it. I mean, the separation should
be *forced* right? JSP merely allows Model/View, but people can violate it
right? It's like OO in C/C++. I keep hearing this over and over.
But, the #set directive, and the ability to make method calls which can
affect global state breaks the whole argument down. These #set directives
can be miused to cause side-effects in the controller/model processing.
view/model separation by allowing the view to cause potential side
effects in the servlet logic. For instance, #set $someObj.staticVariable = "true"
> If you have any previous scripting experience, I maintain WM script will
> come easier. Try it and see if you agree.
I've already tried it, and looked at the source code. That's why I feel
confident in criticizing it. Anyway, I hope you understand I am purposely
being inflammatory. I mean, if Guido went on the perl mailing lists
pitching Python as the new panacea, you don't think some people would
be annoyed? I still remember the original WebMacro announcements
a while ago, that pitched it like WebMacro invented the concept of
templates, which is a rather bold concept if you've been around for
awhile.
Tone down the pitch a little bit, work with Sun/Jarkarta, rather than
against it, and maybe you have a chance. You yourself said that people
who integrate with open-source projects succeed. For instance, why not
create a JSP Tag that lets one use WebMacro expressions:
<wm:webmacro context="varname">
Yay, I can use variables like $foo.bar to represent
varname.get("foo").getBar();
and
#foreach $item in $blah {
<LI> $item
}
to represent
Iterator i = narrowToCollection(varname.get("blah"));
while(i.hasNext())
{
Object item=i.next();
out.print("<LI> ");
out.print(item);
}
</wm:webmacro>
It should be rather easier to wrap/embed the WM engine
in a tag. Embrace-and-extend rather than rip-and-replace.
Diplomacy with the JSP/Servlet community will work much
better than aggressive selling.
-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
