justin Wells wrote:
> Quoting Ray Cromwell ([EMAIL PROTECTED]):
>
> > 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.
> So Ray, what is there to "master" here? What is so complex that you
> would need to be a lisp/scheme programmer to understand? There is
> nothing more complex than this in the WM script language.
Sigh, you're still not getting it. Ok, let's remove WebMacro from
the picture. Let's take a completely static website as an example
that uses nothing but HTML and possibly includes. Do you still
think anyone who knows HTML can design a large web site that
is easy to maintain, manage, update, and navigate. Do you
think that design is simply a matter of knowing the syntax?
I'll reiterate my point: experience with a tool matters.
Infact, what's even more important is an experienced team.
Feedback between the guy dealing with the Java code, and
the *API* he is providing them, and the way they are using
it. I personally don't care if WebMacro is limited to
just variable substitution alone. It is still going to
require training to get them to use it in the most
effective manner, such that the Java developer is providing
them *what they need* to make the user interface work.
Then there is the opportunity cost of being locked into WebMacro
and having all your people use it, instead of not using the
most popular tools which invariable will yield the best tools
and extensions.
> If you need more complex stuff, you write it in Java either in your
> servlet, or in a bean that you drop into your context.
> In WM your controller, the servlet, processes the input from the
> web user and decides which views to use. Rather than implementing
> complex view selection logic in the WM template (which would be ugly)
> you do it in the controlling servlet like this:
>
> Template t = /* pick your template however you like */
> return t;
Sigh...do you really think this is all there is to it? Let's imagine
you have *50* templates. Now, let's imagine you do a DHTML
version of the site. And a WML/WAP version. Do you realize
the tremendous amount of duplicated rendering code present?
Do you know what happens if you need to change some of it?
> Also you claim this:
>
> > WebMacro utterly lacks anything to promote view reuse, or code
> > parameterization.
>
> What's wrong with this:
>
> #parse $header
What's wrong with it is that it is a horrible design. This code snippet
you are including relies on *GLOBAL VARIABLES* and it implicitly uses
them. It's bad practice to be, in effect, calling functions that rely on
modifying global context, and then, trying to reuse those snippets
elsewhere!
Look, let's say I have a bean that provides RSS content or CDF
channels. I want to iterate over this data and render it as a
nice little HTML box like MSN, MyNetcape, MyYahoo, Slashdot Slashboxes,
etc.
You're asserting that I write a small snippet of .wm like so
<h3> $rss.title </h3>
<UL>
#foreach $link in $rss.links {
<LI> <A href="$link.url"> $link.text </A>
</Ul>
}
And that the way I include it in the 50 or so webpages on my
site is by doing
[... lots of wm code...]
<!--- RSS Box section --->
#parse "rssview.wm"
<!--- RSS box section ends -->
However, this code snippet absolutely relies on $rss being
defined and being the correct bean in every single page I use it in,
and every single servlet must make it available, and make sure it
uses the exact same context name.
If I am a view writer, and I want to loop over several collections,
I need to write code like this
foreach $rss in $rssbean.collection {
#parse "rssview.wm"
}
What's critical is that the iteration variable is named $rss, because
if it isn't, there will be an error.
WebMacro's lack of simple *local* scope context, and the ability
to pass parameters to script fragments, and have script fragments
that don't have global side effects can be *devasting* to a large
website. Don't have much experience with the dangers of global
state and side-effects do you?
I'll reiterate: a design which forces the use of nothing but
global variables and global side-effects sucks.
> How is that not re-using views, or not parameterized? Where the
> value of the $header variable comes from is up to you. You could
> have defined it earlier in the template; you could have defined
> it in the servlet; you could have written a context tool that
> implements complex selection logic in Java.
I think I made my point. Implicit global variables don't bode
well for large scale reuse in a site.
> > 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 already supports Macros, you just can't define them in
> WebMacro. You have to write them in Java. It's supported them from
> day one.
Thus, now the Java programmer is back to hacking view code oriented
macros that the view people, who are the experts on user interfaces,
should be writing. So, to use my example above, I must now have
my view coders ask the Java coder "could you please make a #rss macro
that draws a RSS box using the following color scheme, and layout?"
> It's one of those really powerful, really cool features that turns
> out not to be needed in 99% of real world applications, despite how
> cool it might be.
It turns out to not be needed in 99% of toy projects. I see this
same attitude with C programmers claming that inheritance turns out
not to be needed in most projects, except GUI toolkits, for example.
> > However, since you can't pass parameters
>
> I showed you how to pass parameters above. It's very simple: you
> use a variable.
You didn't pass any parameters *INTO* the parsed fragment. And your
technique for passing arguments relies on global variables which is
about the worst design technique imaginable.
> > 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,
>
> Just do this:
>
> #set number = $math.sqrt(32)
>
> and drop an appropriate math object into your toolkit. WebMacro provides
> you with a mechanism to make any tool you like automatically available
> across all your templates.
Yeah, and so does every other system. But every system should come with
some built in functionality. You are now suggesting that every
WebMacro project that needs simple math will have to implement their
own (mutually incompatible) math objects for doing operations as simple
as
#if ($trys > 3 && $viewprefs.kbytelimit*1024 > $datalen) {
...
}
by now defining objects so one can do
#if($math.compareTo($trys, 3) = -1 && $math.compareTo($math.mul($viewprefs.kbytelimit,
1024), $datalen) == 1) {
...
}
Pardon me if I puke. Shall I dig up RMS's devastating critique of TCL
which focused on this exact same math limitation, and apply it you?
> And so it goes, I don't have time to go on with this. I've only responded
> to a few key misconceptions.
No misconception. The ability to add extensions says nothing about the need
to have atleast some standardized builtin extensions. That's why JSP needs
some standard useful TagLibs. What if WebMacro didn't even ship
with IfDirective and ForeachDirective? The fact that anyone can write
them and add them in means didly squat to the people who need to get
work done quickly. It also means anyone looking at WebMacro code
can't automatically understand what it's doing without looking up
what $math does.
> Since I don't intend this thread to go on forever, I suggest you
> respond to me privately, or we move this thread to the WM list, or
> at the very least, the servlet list.
I'm done with this thread too, but I wouldn't suggest continuing it on
the servlet list. The people there are even more fedup with this
template topic.
===========================================================================
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
