Quoting Daniel Lopez ([EMAIL PROTECTED]):
> If JSP was
> like WebMacro, people would be claiming now that Sun tried to enforce
> their own framework to develop applications... instead they gave
> developers all the freedom, and all the risks.
People might say that. I think that those same people would be the ones
who, when Java was first released, complained that they did not have
enough control over memory management, that private/protected access was
too restrictive and made programming difficult, and that they really
wanted to hang themselves by the multiple inheritence rope. There's a
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.
Not everyone agrees with that, as is obvious from the responses here.
If you don't agree with it--continue using unstructured tools. I think
that at some point you will realize the value of structure, because I
think eventually you will be burned.
> I also can understand why Daniel Kirkdoffer got offended, as I also got
> a little bit when you stated that:
> "
> > The consequence is that nobody ever manages to pull this off. There
> > always winds up being some mixing of session logic with presentation
> > logic in JSP--it just slips in there, eventually.
In my experience, this is a very true statement. In my consulting
business I am always picking through the way people have implemented
things, and I see messy code everywhere. In the case of web applications
the mess usually involves a horrible combination of presentation and
business logic.
It DOES slip in there, it can be very subtle at first, it can happen
the day before a deadline, or late at night, or at the hands of some
less experienced member of a team.
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.
A good design limits junior member of the team to introducing
implementation errors.
> I have developed our own small framework (not to enforce this kind of
> design but to give common services like security, application-wide
> events...) and we have been able to succesfully pull this off in our
> first application, as we are using EJB for the business logic,
> semi-servlets (they are not full fledged servlets as we follow the
> one-servlet approach) for the application logic, and JSP for the
> presentation part. Not a single line of code in the JSP talks about
> session logic. Of course JSP does not restrict this, but this doesn't
> mean that we are not smart enough as to be careful about it. Our ligth
> framework could work as well with webmacro so no restrictions in that
> sense.
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.
I don't accept that "smart people" are a generic substitute for good
design supported by the language/tools of implementation. The problem
is that smart people aren't smart late at night, and junior developers
have a lot of important lessons to lean before they too will be smart
in this respect.
> Your probably didn't want to imply it, but this sounds as "If you don't
> support WebMacro then it's probably because you are not experienced
> enough or smart enough to realize the importance of its advantages."
You're right, I didn't mean to imply that. All I meant is that many people
coming to JSP don't realize the benefits of important design at all, and
those people are encouraged by JSP to do the wrong thing.
Obviously people who know what the right thing to do is can fight with
the tool and win, as you have described above. I know some people might
find this language a little bit sharp--but consider whether it's true:
if you want to maintain the separation in JSP, you have to audit and
check yourself every time you go in and poke something.
> Well, IMHO, enforcing these kind of issues is good for a product but I'm
> not that sure is that good for a specification. Should we ask now for
> the servlet specification to enforce the restriction of not being able
> to write the HTML directly from a servlet so separation is REALLY
> enforced? I know you are not promoting the JSP spec to be changed, but I
> don't think that the spec is bad or useless because it gives you freedom
> to shoot yourself in your foot, or that people that use it are not
> experienced enough.
It's true that there is an important principle of minimalism in the design
of broadly used APIs, languages, and so forth. It's important that the JSDK
be applicable to a broad range of situations, and in order to accomplish
that, it must not try to specify too much.
However, you are attempting to take that kind of thinking and apply it to
JSP, in order to come up with "The only way people design web pages should
place no architectural restraints on design."
There are a couple of problems with this:
#1- JSP is not attempting to be a broadly applicable standard in
the same way as the JSDK. The JSDK *must* solve almost all
server implementations, whereas there is no such requirement
placed on JSP.
#2- JSP does not leave open your choices, it closes them off. It
throws up obstacles in the way of people who want to implement
a clean, effective, and architecturally supported MVC model. You
have to move away from JSP to accomplish this.
JSP is, in my opinion, an attempt to duplicate the success of ASP on the
Java platform. I think the name gives it away if nothing else. That means
JSP is aiming at one specific way of programming, for one specific kind
of person.
I don't dispute that there is an important niche for that.
I do dispute whether it needs to be standardsized, and promoted as some
kind of generic replacement for servlets. It isn't, it's a specific design
that isn't, in my own opinion, appropriate in most design contexts.
In this context, I am not sure that JSP should have been standardized. By
standardizing it, Sun is essentially saying "This is the right way to do
things", when as I have been arguing, it is often the wrong way to do things.
The fact that it is the right way to do things in some situations does not
excuse the attempt to apply it to everything.
Although obviously there are a lot of politics around what I say next,
since a lot of people have committed too much, I think the right thing to
do is drop the JSP standard and replace it with a good 100% pure implementation
of JSP that works on any platform. I fail to see the need to standardsize it.
It seems like one tool in a toolbox, not, by design, any more sophisticated
or important than any other tool.
> So to summarize, WebMacro is a product(open source but still a product)
> and JSP is a specification.
Nobody who uses JSP uses a specification. They use products.
> They are something different and
> unfortunately incompatible because JSP doesn't allow you to enforce the
> restrictions you want to have in your development framework, otherwise
> you might use JSP as the html template system for WebMacro.
I have to point out that they are not incompatible. You could probably combine
them on the same page with hard work, which would be somewhat silly. More
importantly though, they can live together in the same servlet environment,
and access the same servlet context, same session storage area, etc., so they
are very much compatible.
> But freedom
> is costly and in JSP that means letting developers clutter their HTML
> pages with code. So I agree with you in almost everything except in the
> tone some sentences were stated. Constraining peoples' freedom is very
> difficult because you have to be sure they can do everything they need
> to do within their restricted environment, and convince them too ;).
WebMacro does not claim to be a monolithic solution. I don't think it is the
right solution for all designs--especially, for example, in situations where
you programatically build up every object on the page from base components.
In situations like that I think tools like apache.org's ECS, or htmlKona,
are much more effective than the template model (which WebMacro and JSP
both fit into).
WebMacro provides you, in the servlet, with the ability to create and
execute templates. It doesn't force you to write the two or three lines
of code that it takes to do that--you could choose to write some different
lines of code instead: perhaps you will use kona to construct some object
this time, rather than using WebMacro.
Lest I be accused of plugging WebMacro too much again, I will point out
that the same thing applies to other template solutions to--they provide
you with a way to create templates, they don't force you to do it.
It is JSP that attempts to provide the monolithic solution--and it is
precisely for this reason that JSP has had to water down any design
constrants and allow anything at all to happen.
> So good luck with WebMacro,
Thanks :-)
Justin Wells
- - -
WebMacro Servlet Framework
http://webmacro.org
===========================================================================
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
