Justin Wells:
> Ray, you continue to labour under the mistaken impression that WebMacro
> script language is intended to be a general purpose programming language.
I never asserted that, I asserted that there should be some minimal
expression functionality. You have drawn the line at #if and conditions
containing simple boolean operators. I happen to think that math expressions
are *very* useful in views, when calculating dimensions, sizes, etc. You
happen to think that simple math like addition and division should be
delegated to some bean. I think it's useful enough that it should be
a part of the syntax. Heed the words of Larry Wall.
> Meanwhile you talk about writing complex logic to deal
> with selecting between 50+ views from within the script language. You
> talk about deeply nested function calls down many levels of view. And
> on and on it goes for pages.
Justin, do you even read my messages at all? Do you? I didn't talk
about selecting views, I never once mentioned actually selecting
views. Clearly, the servlet chooses which template to render. I talked
about *REUSABLE VIEW COMPONENTS* Can you not understand this concept
at all? You see to understand the concept of headers and footers. You
seem to understand that it is a good thing to use the same
header/footer code in all your views, so that they can be changed
easily.
What you seem incapable of understanding is components, that's why I
gave you a widely used, *specific* example -- RSS. RSS is used
everywhere: MyNetscape, Slashdot, Scripting.com, Freshmeat,
MozillaZine, just about every web log. RSS requires taking a
list of simple links and titles, and rendering them in a nice
looking headline box. You can bet good money that these are
implemented as Cold Fusion macros, Javascript subroutines,
Perl Modules, etc on most sites.
On weblogs, people like to select several of these boxes at once,
and they like them to be present on every view, everywhere. Clearly,
the code that renders these boxes should be reusable on everypage,
and for multiple projects.
WebMacro lacks parameter passing. It relies exclusively on global
variables for passing data. This is a bad design, a shortcoming,
and you refuse to acknowledge it. Instead, you keep asserting
that anything that requires this functionality is "a bad design".
I'm sorry, but you're wrong. Your design idealogy is wrong.
Views are not MONOLITHIC. A page is made up of many components
(more than just header, body, footer).
If your design methodology were adopted for GUIs, you would have
a single top-level Component whose paint() method had to do EVERYTHING,
and could not call on other reusable libraries to help it.
> The whole point of WebMacro is that such designs are *bad*.
What design? You mean relying on high-level reusable components to handle
common tasks like rendering RSS, CDF, database results, LDAP address books,
tables of contents, glossarys, etc? Stop attacking strawmen. I'm sure
everyone on this list is aquainted with the wonderful world of
seperating presentation from business logic.
> You continue to look at WebMacro script as if it were the main part of
> a WebMacro application, and it bugs you that you don't find a full
> fledged programming language when you look there. You insist on wanting
> to use a tool that lets you do generic, turing-complete programming
> inside the template view.
No it doesn't bother me. I don't even use JSP like you suggest. My own
system surpasses your technique of isolating to view. My servlets
output XML which is then passed throught XSLT to output HTML, HDML,
DHTML, and PDF, not to mention multiple "skins" that can be overlayed.
My code is internationalized by using XML entities, the exact same
way the Mozilla XUL/CSS/DTD model works. The end result is a system
that can render to the browser, cellphone, or printer, in multiple
languages, and can be customized for each client's look-and-feel by
altering a few stylesheet rules.
XSL provides even less functionality than WebMacro, because it cannot
make dangerous Java calls (tell me, will the following work in WebMacro
$someObj.getClass().forName("java.lang.System").exit(0)), and XSL is
way easier to componentize and allow overriding behavior like CSS.
However, XSL still allows me to do this:
<img src="{@imagename}" width="{@width/2}" height="{@height/2}"/>
so I can shrink an image by 1/4, whereas WebMacro lacks even this
basic expressive power, that, incidently, doesn't make the
language turing-complete, and doesn't make the view harder to
understand.
> At any rate, I think you are so biased by your JSP-centric view of the
> world that you are never going to understand my point.
I understand you perfectly, I just don't think you understand real-world
development realities. Your answer to any WebMacro criticism is either
"no one will ever do that", or "if they did do that, it would be a
bad design", or "they can add it if they need it by hacking it in"
You keep pushing your particular design as the one true solution,
and ironically, refer to the Model-View-Controller paradigm which
contradicts you, since a *DECADE* of real world design experience
suggests that you can't effectively separate the controller from
the view. It has been tried over and over, and fails as soon as
an application grows in size.
In reality, WebMacro is a tool like every other. It is not
a revolution, not innovative, and your ideas are not new to any
experienced designer. WebMacro will work just as well as
the other hundred template systems out there. In reality,
it will work just as well as JSP in most products, and will not
revolutionize anything, or lead to huge cost savings, yadda
yadda.
It's just a small template engine that you have every
right to be proud of, it's your baby. It's cool, it's nice.
But just as many people think XML is nice, and JSP taglibs
in Jakarta/Tomcat will be nice, and sometimes, just sometimes,
people need to get something done quickly, and are going
to hack it up in Model1/Scriptlets, and then refactor it into
Model2 later. That's reality.
Think of it this way: What if I went on the WebMacro mailing
list and kept babbling about any design that doesn't use
3-tier and application servers is bad? What if, all of a sudden,
I got "J2EE religion" and started heavily evangelizing it,
and whenever someone pointed out that there was something it
couldn't do, or made harder, I just said "but that's a bad
design", or "you would just use this workaround"
That's how you appear to me on the JSP and Servlet mailing lists
right now.
-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
