Quoting root ([EMAIL PROTECTED]):
^^^^
Interesting. Do you always read mail as root on your box?
> > Quoting Daniel Lopez ([EMAIL PROTECTED]):
.......
> > grain of truth in all of that--but, in my opinion, a lot more truth
> > in the notion that restrictions are necessary for good design.
>
> This is a straw man that can be extended in either direction. One
> could just as equally assert that Java's type restrictions are weak,
> such as the lack of templates and the almost universal need for
> dynamic casting. Or how about the lack of preconditions,
> postconditions, and invariants. And of course, WebMacro's
> restrictions are even worse, because it defers type checking until
> evaluation time when it can introspect.
Yes, and all those assertions are good and interesting, and illustrate
the point that the design space is rich and varied.
There is a lot of pressure coming from Sun that JSP should be considered
the primary, almost only, tool for building web-pages. Evidence this
silly notion that if you want to do MVC design you should do it within
the context of JSP.
WebMacro, FreeMarker, ECS, kona style solutions, Dash, etc., all
work within the servlet framework, and so you can mix and match
solutions within your code.
Each imposes its own different set of restrictions on the kind of
design you can pursue while using it. In some situations, the design
conditions imposed by a tool like WebMacro will turn out to be
wrong and you'll want to switch to a kona/ECS type solution. In
other situations that would be wrong, and instead you'll prefer
to use a template system like WebMacro.
Even in within the template domain there are choices. If the type
checking at compile time is very important to you, then there are
template systems that do that. If instead you prefer to work with
Java beans, and have some freedom to vary the data on the back
end, or avoid the cost of writing wrappers, then you'll prefer
a system that relies on introspection, such as WebMacro.
Nobody is claiming that there is one solution that applies to
every system, EXCEPT for the JSP people. That's why I am here and
I am so vocal about it .
I have never made any claim that WebMacro is well suited to every
problem. If you go back over the last year or two and look, you will
see me sending people toward ECS and other things when it's obvious
that what they're doing would be ill suited to a template approach.
> Time to get off your high horse here. Just about everyone I know
> who's been a long time web developer has written their own template
> system, starting with simple variable substitution, and progressing
> further into macros and loops.
Sure. I've been doing this since 1993. I used to do it in PERL. When
I got to Java I looked around for the equivalent way to do things
in the Java world and came up with nothing. I looked at JSP and I
wasn't very impressed, so I wrote WebMacro.
Around the same time I gather several other people came to the same
conclusion I did, and set out writing their own template systems. It
still does involve a lot of work, and in the presence of an existing
template system I might not have done it. Other people can save the
work by using WebMacro, or one of the others, rather than rolling
their own.
> (Why is it called WebMacro when you cannot define Macros in it?)
Good question :-)
Welcome to the wonderful world of free software where your program
grows and your designs adapt themselves to the real world, rather
than the imagined world.
Actually almost everything in WM is a macro, it just doesn't look
that way, and you can't define new ones from within WM itself. It's
fair to wonder whether that means they are actually "macros".
When I originally set out working on WM I thought it would look a lot
more like a traditional macro processing system. Implementation of the
directive to allow you to define new macros has been on the TODO list
since day one, but development has always been governmed by what
features were needed for current projects, and what features were
being demanded by WM users.
Since nobody ever demanded the #macro directive, and since I never
needed it on my own projects, it never got implemented. This is
the main reason why the version number is sitting at 0.89.1 despite
it being a fairly reliable and stable system--I can't justify
calling it 1.0 until the name makes sense :-)
I still plan to implement it eventually.
> I've been developing CGIs since 1993.
I used to write programs to update webpages out of .forward mail
filters, since the webserver I had didn't have usable CGI :-) Back
when I was beginning, we had to write all our code in 1's and 0's.
Actually the 0's came later, when I first started out we only had 1's.
The first statement is actually true, the rest is to show what a
stupid way to debate this is :-)
> When I wrote my first template language back in 95/96, there
> were already about 3 dozen out there, and growing rapidly, Cold Fusion
> being the most popular, but there was also metahtml, dynamo,
> htmlscript, popsite, and a handful of TCL based ones (AOLServer,
> Vignette, etc)
Sure. But none of them were available to me for free in the Java
language. I used to have a bunch of perl template stuff that was
built on top of M4, and I sorely missed it when I started working
on servlets.
The reason why all these systems you mentioned exist is that
templates are the right way to do things on the web. That's the
point that I've been trying to make here, thanks for helping :-)
> Frankly, WebMacro is a late comer to the party, and all
> the buzzwords listed on the WebMacro homepage are old hat. TCL coders
> have been doing exactly what WebMacro does for far longer, by
> providing precisely the variables and commands and restricting all
> others. My point? Don't presume to "talk down" to people on this list.
I don't presume to talk down to anyone. I think JSP made a big mistake
ignoring all the history you are describing and breaking with that
model of programming.
> > I believe people who say that highly experienced developers can avoid
> > this kind of thing through eternal vigilence, however no program
> > should be structured such that it's impossible for inexperienced,
> > new members of a team to work on it without committing design errors.
>
> And WebMacro solves this problem, how? Vs Cold Fusion? Vs
> FrontPage 2000 and InterDev and other 4GLs? vs JSP Taglets?
> Vs XML+XSL?
Design errors === program design errors. I think you misread that and
thought I was talking about page design errors. I realize reading
it that it was an easy mistake to make.
WebMacro prevents you from making design errors in the overall structure
of your servlet by architecturally keeping you from burying important
business logic in the middle of some ugly block of HTML.
> How do I define templates that can be reused multiple times later.
> Are you seriously
> suggesting that the "parse include" mechanism is good enough? There are
> times when you want to define a macro that is parameterized,
> and is callable by name anywhere within a page, without
> dependence on global variables.
The #macro/#filter directives I was talking about were to facilitate
creating these objects as templates, and declaring that certain
variables should be filtered through them. It's a powerful idea,
whose merits you just propounded. In practice I've never actually
needed it, and people on the WM list haven't demanded it.
In practice the #parse and #include methods, along with intelligent
selection of the template you want to use, turn out to be effective
most of the time. I'm not claiming all of the time.
Another powerful technique is to create an instance of org.webmacro.Macro
and implement it in terms of some other HTML generation system, such as
ECS or htmlKona. That lets you use a template to layout the general page
and place objects, but drop onto the page objects of completely unknown
type (which is what kona/ECS are good at dealing with).
WebMacro claims to be a framework, not an end-to-end solution. It was
designed to be integratable with other tools.
Eventually I should have the #macro and #filter directives defined
and you will have exactly what you want without leaving the WM
script langauge.
I think this part of the discussion is focussing more on WM in
particular and we've moved away from templates-vs-JSP. But you
asked the question and I felt obliged to answer.
> How can one implement the Strategy or Flyweight design pattern in
> WebMacro ala Swing's Cell renderers? If Webmacro had closures, atleast
> one would be able to pass in a snippet to a macro to change the
> look/view of a row or column without duplicating the rendering logic.
Any object that returns an object of type Macro will be recursively
evaluated until it's not a Macro, so if you're clever you can have
what you want. The WM script language does not yet give you the tools
you need in order to do this without being a little clumsy, but that's
the idea that originally spawned the name "WebMacro" in the first place.
As I mentioned above, the real world took over and carried the project
where people needed it to go, rather than where I originally thought
it would go.
> > I don't doubt that it's possible. I have also seen some well structured
> > assembler, and some OO code written in C. Smart people can pull it off,
> > but that's not a credit to the tool they used--it's a credit to smart
> > people.
>
> Straw man. Your analogy isn't even correct. C doesn't offer
> object-oriented capability, C++ does. C requires the developer
> to hand-roll OO style, C++ has it as part of its syntax. However,
> C++ also allows to the freedom to "fall back" to C-style.
> C++ is a super-set of C.
Sure you can write OO code in C. Just define all your structs to
have pointers to functions in them, and write constructor methods
that initialize those pointers to be to the right functions for
that type of struct. Then you write a lot of code like this:
foo->method(foo, arg)
it's ugly, but it works. You're forgetting that the original C++
compilers worked by translating C++ into code that looked very
much like that.
My point is that using C this way is a bad idea. It is much better
to go and use C++ where all of these things are supported by the
language and the tools that you're using. Similarly, if you want
to do MVC design, it is much better to go and use a tool like
WebMacro, FreeMarker, or one of the others, rather than trying to
force yourself to make it work in JSP.
> Likewise, JSP provides a mechanism to achieve what you are talking
> about, naming the USEBEAN/BEAN tags, and the 2.2 Taglet mechanism,
> just like JRun's taglet mechanism. However, JSP allows you to
> "fall back" to Java fragments if needed. JSP is a superset.
How do you prevent someone from putting code into the HTML portion
of a JSP template? If you can't, it doesn't offer you support.
That's just like saying "don't call private methods" rather than
having a compiler that enforces it.
> Worse, WebMacro doesn't support rapid prototyping or the iterative
> development model.
That's the most ridiculous thing I've ever heard. WebMacro was
designed to support rapid development:
-- You write an HTML page that looks like what you want, and
get the customer to sign off on it
-- You populate the HTML page with some script codes so that
it can be automatically generated, and fill a hashtable
with some data that fills in the blanks
-- Your page designers go off and play with the webpage, your
programmers go off and start turning some of the hashtable
data into real data from the real source
> In this model, a logic snippet is quickly
> prototyped in the template along with the display logic. After
> debugging, or satisfactory results, it is "refactored" into the
> back-end.
That doens't sound like something that's possible in WebMacro, so
I suspect you simply don't know what you're talking about here.
Unless I'm misunderstanding you and you are talking about JSP, in
which case I don't know what you're trying to say. Please elaborate.
> As a result, WebMacro forces too much
> interdependence/synchronization into the development cycle. The
> presentation/GUI developer is now twiddling his thumbs waiting for the
> backend guy to finish his work. Refactoring is a major part
> of software engineering.
Absolutely wrong. The GUI designer doesn't have to care what kind of
data the backend is supplying--only that it has the right names. Where
it came from, and what type it is, is irrelevant. The whole point of
WebMacro is to allow these two activities to go on in parallel, and
in practice that is exactly what users of WM do.
> If WebMacro was purely for presentation, why allow the SET mechanism
> at all? Why not force all beans to either return Swing models, or
> JDK1.2 style read-only collections/iterators.
The #set method is there so that you can declare the content-type
and other presentation issues from within the template, so that
the servlet doesn't have to know what kind of data the template
is going to create.
The controller gets to decide what things you are able to #set
by deciding what things live inside your context. If you want to
pass in read-only objects you can--WM has no way of breaking
Java encapsulation, so you'll succeed in that.
The #set directive also allows you to parameterize your template
at the top, and then use those values throughout the template later.
If you don't like the #set directive, don't install it. You can
delete it from the WebMacro.properties file and it won't be
available for use (just about everything in WM is dynamically
loaded and modular, it's a framework).
> That's the approach I
> took for one project. You got either a ListModel, a TableModel, a
> TreeModel, or a DocumentModel. You could simple require
> programmers to write an adapter for beans, or autogenerate
> adapters and compile them on the fly.
FreeMarker takes this approach. I took the view that the work of
creating all these adapters winds up getting in the way of rapid
development, iterative development, and prototyping, which you
were just propounding the merits of a few minutes ago.
> Instead, WebMacro allows one to set variables and call any public
> methods on objects, which opens up its own can of worms when it comes
> to design.
Not true. You can only access objects that are inside your context,
and it's up to your controller to decide what objects you get access
to, and whether or not they are readonly.
> Are objects stateless or stateful? Mutable or Immutable?
I think that's up to you. WebMacro doesn't insist either way. You
have all the power the Java language gives you to design this--WM
obeys Java's access models.
> Does invoking a function always return the same result? Is this
> object a singleton, per page, per session?
Again, that's up to you. WebMacro doesn't insist either way. You
have all the power of the Java language with which to make this
decision, and implement your design either way.
> WebMacro enforces none of these assertions explicitly, and is unable
> to encourage good design that comes from knowing these things clearly
> ahead of time.
WebMacro expects you to make these decisions in *java* code, and
puts the burden of creating the data model squarely on the shoulders
of the Java programmer. It doesn't pretend to be a replacement for
Java, it expects you to use Java effectively.
Once you have created a viable data model, WebMacro will help you
render it to HTML.
> Instead, you better hope the servlet/bean designer
> wrote good documentation, or good encapsulated classes.
WebMacro solves one problem: it separates your page design decisions
from your program design decisions. It does nothing to help you figure
out whether a blue picture looks good on a red background, and it does
nothing to help you figure out how your beans and other objects should
be designed.
You seem to think that I imagine WebMacro excuses you from designing
your servlet correctly. I don't think that--I think that WebMacro
makes it easier for you to do so, by keeping the page design issues
out of your face while you figure it out.
> But let's get back to the real world. In the real world, the
> presentation designer, which in the first pass, is more often
> than not, the back-end coder, ends up hacking in whatever methods
> he wants into the bean, and may end up with a bad design in
> the end.
In my experience it goes one of two ways:
-- a back end coder presents an HTML interface, and then everyone
complains and complains until it looks good.
-- a page designer hands you an HTML page and the back-end coder
is tasked with writing the program to create it dynamically
Templates are effective in both cases.
In the first case, you just make the ugliest first pass you can
and then get people to tell you how it should look. It's trivial
to change the look of the page, since it's encapsulated in the
template--you just edit the template live, and keep hitting reload
until people are happy.
In the second case it's even easier--you just open up the HTML and
drop the script tags in as needed to replace the hard coded examples
with your placeholders. This process also tells you exactly what you
need to create on the back-end in your data model to make it work.
The third way of doing things, where you have a savvy page designer
who is not afraid to learn a little scripting, is also well supported.
The back-end coder and the page designer get together, work out the
data model, and go their separate ways. Usu. you stick in a hashtable
full of dummy values to let the page designer go ahead while the
code is being written.
In all three cases templates are an effective way to go.
It is only in JSP where the nightmare you describe above is the
natural way to do things. Yes, if you were evil you could use WebMacro
in ways you shouldn't to violate the encapsulation--but it doesn't
come naturally, you have to work at it. You won't do it by accident.
With JSP it's easy to stick a few lines of code into your HTML, as
needed, to update your objects, to grab that extra bit of information
from the database, etc.
What you're describing is what I see happening all the time when
people try to use JSP as a template language--but I don't often
see people doing that with WebMacro, FreeMarker, etc,. because
although it's probably possible, it's totally unnatural.
> Overall, you have failed to establish how WebMacro solves this
> problem.
Obviously you are not convinced, but I doubt I've failed. I can see
how many people are downloading WM, and I can see how big the mailing
list is getting, and I can read in the Java Report that at least
some people think I've done something right.
I don't expect to convince everyone. Some people will think that
templates are the right way to go. Some people will not. Of those
who choose WM, some will like the design decisions I've made, and
some will prefer the ones someone else has made.
You think "good design" revolves around a single concept:
> separation of model from view (and you beat that dead horse into the
> ground). While is it important, it isn't the only design goal in a
> project. Furthermore, WebMacro *doesn't* separate these things
> completely cleanly. Just try writing a multilingual multibrowser
> version, and you'll see what I mean. XML+XSL solves the problem much
> more cleanly, by dealing with structured DATA, not method calls, and
> is much more amenable to writing VISUAL EDITORs than WebMacro is.
XML+XSL solves an important problem, and has a very big niche in
which WebMacro is not an appropriate tool. I spent a year and a half
working in the SGML division of SoftQuad Inc., back when it was one
of the largest SGML vendors (before the company got eaten from the
inside out by the HoTMetaL product).
I totally believe in XML/SGML technology and have been actively using
it for years. I make a good chunk of my living as an XML consultant.
I can tell you this about it: it isn't an appropriate approach to
take on 80% of the sites that you will build. In the other 20%,
it's irreplacable.
I don't see XML+XSL as competition for WebMacro. I see it as a very
important and useful solution for the kinds of problems that WebMacro
is not good at solving. I see WebMacro as the correct way to go when
dealing with the kinds of things that XML+XSL doesn't do well.
> But JSP 1.1+, rigorously defines how to interact with beans,
> enterprise javabeans, how to define TAGs, how to interact with input
> /output, sessions, and threads. This *is* needed. WebMacro doesn't even
> specify a *contract* that presentation code should adhere to. When I see
> a WebMacro page, I have no idea if the page is reetrant, side-effect free,
> manipulates local or global variables, etc
This is a smokescreen. JSP only has to deal with these issues because
it removes the programmers ability to solve the problem in Java.
With WebMacro these issues only come up if the servlet programmer decides
to allow them to come up by choosing to place dangerous objects in the
context, making them accessible to the template.
The servlet programmer has complete and total power to decide what types
of objects, in what form, and under what conditions the template can
access them.
Java is an excellent language for solving problems like these. WebMacro
takes the view that it is in Java code that you should deal with these
issues, using the available Java language mechanisms for doing so--JSP
takes the view that it should solve all the worlds problems, and so
it brings all the worlds problems down on its shoulders.
This is one of the biggest problems I have with JSP: by trying to be
too much, it winds up having to be a total replacement for the Java
programming language.
> Sun could drop the JSP spec, and release an open-source implementation.
> But that implementation would become the defacto-standard, and yes, it
> would be forked by vendors and users, but at the core, everyone would
> be coding to, you guessed it, the reference implementation.
That would be preferable, in my view. If they released it under a
sensible license (as opposed to SCSL) then everyone would be willing
to contribute to it, and we wouldn't have all these different
competing (and possibly buggy and therefore potentially incompatible)
implementations of JSP lying around.
Anyway, this sounds like a whole different can of worms.
> ECS/htmlKona are non-scalable, non-maintainable designs looking for a
> problem to solve.
....
So use XML+XSL then. I think the ECS/kona stuff are fairly good when
you are writing a code generator to produce objects. I don't think
that's all that common, but when it does occur I think they're fairly
good solutions.
I agree humans wouldn't ordinarily want to edit it. I'll let Jon, if
he's around, take up the defense of ECS.
> So? JSP Taglets allow far more rigorous design restrictions by enforcing
> a DTD, but with runtime performance that will blow WebMacro's implementation
> out of the water.
This is a lot of nonsense. XML parsing is fairly expensive, even with
some of the fast XML parsers now available. But the big point is that
in either case, once something has been parsed, it doesn't matter. Both
JSP and WebMacro parse only once, so this isn't ever likely to become
a performance issue for anybody, ever.
Justin
===========================================================================
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
