Ray Cromwell wrote in reply to Justin Wells:
[snip]
>
> 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.
>

I would hardly characterize Justin's postings as "flooding the
JSP and Servlet lists with propaganda."

As with many beginner Servlet programmers, I am struggling with
how to best separate processing logic from view. I have found
this thread, and similar threads, to be most helpful.

> > 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.
>

Yes, and JSP, with its custom tags and XML style syntax does seem
well suited to manipulation via visual tools.

I suspect that a template tool with elegant syntax will be
favored by those who prefer using text editors over visual tools
for text markup. Programmers tend to fall into this category, as
well as a significant portion of html designers.

JSP syntax, as it stands now, IMHO, is a drag to learn, type, and
look at. Discussions like this may help expose this as a
shortcoming that could be addressed. Perhaps something like the
<wm:webmacro> tag that you suggest below.

Or maybe JSP's verbose, unsightly (IMHO) syntax will relegate it to
*only* being manipulated by tools. If so, that leaves a sizeable
niche in the server-side java community for a decent template
tool with a simple, elegant syntax.

[snip]
> > 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.

This approach does sound very appealing. I look forward to
learning more about it as the standards and tools evolve.

But
   Servlet/JSP -> XML + (transformation) -> etc
could also be
   Servlet/TemplateTool -> XML + (transformation) -> etc
or
   Servlet/ECS -> XML + (transformation) -> etc
or
   Servlet/XMLC -> XML + (transformation) -> etc
right?

In this case, I personally would choose TemplateTool over JSP, because:
(1) simple text-editor-friendly syntax
(2) can easily be used without being attached to servlet engine
    (useful for generating static pages).
(3) supports of the concept of a template path.
    (I don't want to have to copy my JSP XML generation templates
    under the document root of each servlet context that needs to use
    them.)

To be fair, template path concepts and stand-alone capabilities
could be added to JSP.

[snip]
> > 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:
>

IMHO, I didn't detect any pitch in need of toning down. I've
found these discussions comparing JSP to alternative approaches
most helpful, and I hope they won't be discouraged.

>
> <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.

Yes, I'd like to have such a tag available.

> Diplomacy with the JSP/Servlet community will work much
> better than aggressive selling.

I, and perhaps others, see these comparisons of JSP to
alternative approaches as helpful, and fail to detect the
aggression you speak of.

>
> -Ray
>

- Robin

===========================================================================
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

Reply via email to