You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Lorenzo Pastore <lo...@lince.it> on 2001/01/08 17:29:59 UTC
ssl direct
Good morning
i'm trying to use ssl direct with tomcat on linux machine, following the
detailed how-to lists i don't succeded to conclude the certification. If
i not varing the provider2 voice i conclude the certification but when i
open the hppts page on 8443 port on my tomcat machine retur error
"unrecognized ssl handshake"
Can you help me PLEASE
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/11/01 12:12 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> I think these two quotes from the website will address your concern.
My concern?
> There is no official release yet, but there will be one shortly.
However, you can get daily snapshots which are quite stable and ready to
use.
> Velocity's design concept is borrowed from WebMacro.
However, it is vastly different in implementation.
-jon
Re: An alternative to JSP
Posted by Brad Cox <bc...@virtualschool.edu>.
I think these two quotes from the website will address your concern.
There is no official release yet, but there will be one shortly.
Velocity's design concept is borrowed from WebMacro.
At 11:42 AM -0800 01/11/2001, Jon Stevens wrote:
>on 1/11/01 11:21 AM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>
>>> Please take a look at:
>>> http://www.enhydra.org
>>> and
>>> http://xmlc.enhydra.org
>>> for more information.
>>
>> Will do. Looks a lot like WebMacro at first glance.
>> --
>
>Absolutely not. XMLC is way different than WM or Velocity.
>
>Also, look at:
>
><http://jakarta.apache.org/velocity/>
>
>p.s. It is interesting that you are a PhD. yet you haven't done any research
>into the alternatives that are out there. Instead you just invented your
>own. Sigh.
>
>-jon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
---
Dr. Brad Cox; bcox@superdistributed.com
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/11/01 11:21 AM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>> Please take a look at:
>> http://www.enhydra.org
>> and
>> http://xmlc.enhydra.org
>> for more information.
>
> Will do. Looks a lot like WebMacro at first glance.
> --
Absolutely not. XMLC is way different than WM or Velocity.
Also, look at:
<http://jakarta.apache.org/velocity/>
p.s. It is interesting that you are a PhD. yet you haven't done any research
into the alternatives that are out there. Instead you just invented your
own. Sigh.
-jon
Re: An alternative to JSP
Posted by Brad Cox <bc...@virtualschool.edu>.
At 11:30 AM -0500 01/11/2001, Shawn McMurdo wrote:
>I agree with most of your discussion of the disadvantages of JSP/ASP/etc,
>but I believe your solution does not address a fundamental problem, which
>is the complete separation of presentation resources from presentation logic.
That is correct. My goal at this point is to get free of JSP so the
goal was only to duplicate what JSP does in a way I can live with.
>Having the HTML embedded in a java class may be suitable for small
>applications
>built by engineers but does not address the vast majority of applications
>where designers work on HTML using many different HTML editing tools
>while developers work on the application logic in Java using various IDEs and
>editors.
Perhaps I miscommunicated. The private methods that contain the
{{html}} need not be private methods in the controller class,
although that is the style I demonstrated in the paper and that I use
in my own I-do-it-all work.
Also there is nothing that requires these view methods to contain
hardcoded strings, other than the crude measurements in the
Conclusion section that makes me doubt that the space issue is a
primary concern. Each method could aim MLS at an html file at runtime
(using the doStream() method that it provides for this purpose but
which I didn't mention in the article) and let it do the executable
inclusion at runtime. But good point; I'll make this explicit in the
article.
This would also eliminate the need for the outermost enclosing {{...}}, but
the executable inclusion brackets would remain. Do you object to my
belief that html experts and their tools couldn't be trained to
ignore the {{...}} wrappers around the html? I'd be interested in
hearing more about this. After all, JSP has the same problem its <%=
... %> executable inclusion syntax.
>Please take a look at:
>http://www.enhydra.org
>and
>http://xmlc.enhydra.org
>for more information.
Will do. Looks a lot like WebMacro at first glance.
--
---
Dr. Brad Cox; bcox@superdistributed.com
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
Re: An alternative to JSP
Posted by "Kyle F. Downey" <kd...@amberarcher.com>.
Right on. HTML-in-Java vs. Java-in-HTML is a silly argument AFAIK.
Neither's a very good solution long-term. The Java-in-HTML makes it
near-impossible for designers to collaborate with coders, while the
HTML-in-Java has that problem, plus the code bloat problem (the bytecode
format will choke on overly large HTML strings in classes), and the fact
that it's just a bitch to edit HTML inside Java files. The author of
FreeMarker or WebMacro wrote an article on this subject a while back.
Our chosen solution is to generate XML and style it with XSL. The only
thing missing from that picture is a really solid XSL designer integrated
with a well-known editor like Dreamweaver. Given that, your designers can
work 100% independently of the coders, and you get many other benefits in
the bargain, like ability to morph your sites appearance to the needs of
the incoming browser and ability to publish XML-only Web services using
the same content.
regards,
kd
> I agree with most of your discussion of the disadvantages of JSP/ASP/etc,
> but I believe your solution does not address a fundamental problem, which
> is the complete separation of presentation resources from presentation logic.
>
> Having the HTML embedded in a java class may be suitable for small
> applications
> built by engineers but does not address the vast majority of applications
> where designers work on HTML using many different HTML editing tools
> while developers work on the application logic in Java using various IDEs and
> editors.
>
> Having the HTML and Java mixed together whether it is in a JSP file or in a
> servlet
> with multiline strings is a maintanence problem.
> It becomes difficult for designers to change the layout or developers to
> change the
> logic without walking all over each other.
> These mixed files are also problematic for many design or development tools.
>
> A superior approach is to completely separate the HTML presetation from the
> Java logic as is done in XMLC (the Enhydra XML Compiler).
> With XMLC, HTML (as well as any XML resource such as WML, cHTML,
> XHTML, VoiceML, etc) files are compiled into Java class files that use the
> W3C (World Wide Web Consortioum)'s DOM (Document Ovject Model) standard
> to represent the document. The developer can then manipulate the presentation
>
> directly from within the Java presentation logic.
>
> After 4+ years of working with templating languages (including one we wrote
> that
> predates JSP), we have found this to be a vastly superior way to develop web
> applications.
>
> Please take a look at:
> http://www.enhydra.org
> and
> http://xmlc.enhydra.org
> for more information.
>
> XMLC is open source and freely available.
>
> Shawn
>
>
> Brad Cox wrote:
>
> > I've uploaded an early rough draft of a pair of articles that boils
> > down to a critique of the JSP approach plus source code for a quite
> > different approach. I'd be very interested in feedback... of the
> > constructive variety, of course ;)
> >
> > The articles are at http://virtualschool.edu/wap
> > --
> > ---
> > Dr. Brad Cox; bcox@superdistributed.com
> > Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
> > http://superdistributed.com: A new paradigm for a new millinneum
> > PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
> --
> Shawn McMurdo mailto:shawn@lutris.com
> Lutris Technologies http://www.lutris.com
> Enhydra.Org http://www.enhydra.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
Re: An alternative to JSP
Posted by Shawn McMurdo <sh...@lutris.com>.
Hi Brad,
Interesting articles.
I agree with most of your discussion of the disadvantages of JSP/ASP/etc,
but I believe your solution does not address a fundamental problem, which
is the complete separation of presentation resources from presentation logic.
Having the HTML embedded in a java class may be suitable for small
applications
built by engineers but does not address the vast majority of applications
where designers work on HTML using many different HTML editing tools
while developers work on the application logic in Java using various IDEs and
editors.
Having the HTML and Java mixed together whether it is in a JSP file or in a
servlet
with multiline strings is a maintanence problem.
It becomes difficult for designers to change the layout or developers to
change the
logic without walking all over each other.
These mixed files are also problematic for many design or development tools.
A superior approach is to completely separate the HTML presetation from the
Java logic as is done in XMLC (the Enhydra XML Compiler).
With XMLC, HTML (as well as any XML resource such as WML, cHTML,
XHTML, VoiceML, etc) files are compiled into Java class files that use the
W3C (World Wide Web Consortioum)'s DOM (Document Ovject Model) standard
to represent the document. The developer can then manipulate the presentation
directly from within the Java presentation logic.
After 4+ years of working with templating languages (including one we wrote
that
predates JSP), we have found this to be a vastly superior way to develop web
applications.
Please take a look at:
http://www.enhydra.org
and
http://xmlc.enhydra.org
for more information.
XMLC is open source and freely available.
Shawn
Brad Cox wrote:
> I've uploaded an early rough draft of a pair of articles that boils
> down to a critique of the JSP approach plus source code for a quite
> different approach. I'd be very interested in feedback... of the
> constructive variety, of course ;)
>
> The articles are at http://virtualschool.edu/wap
> --
> ---
> Dr. Brad Cox; bcox@superdistributed.com
> Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
> http://superdistributed.com: A new paradigm for a new millinneum
> PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
Shawn McMurdo mailto:shawn@lutris.com
Lutris Technologies http://www.lutris.com
Enhydra.Org http://www.enhydra.org
Re: An alternative to JSP
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Paul Speed wrote:
>
> I'll be curious to see where the JSP spec evolves next. To
> me it seems logical to start incorporating more tags along the lines
> of the current bean tags. Iteration and other control structures
> seems like the most common part of the wheel that tag libraries seem
> to be re-inventing. Standard versions sure would be nice.
>
Funny you should mention that ... there is a current JCP specification request
(JSR-052) to do exactly that ... formulate a standard set of tags for commonly
required things. (Yes, the Struts tags will be looked at as input to the
process, along with submissions from others who have already developed such
libraries).
For more info, see
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html
Eduardo Pelegri-Llopart (who is also spec lead for JSP 1.2) is the specification
lead for this.
>
> -Paul
>
Craig McClanahan
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/14/01 5:34 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
> Seems to me that your argument rests on the assumption that there exists
> such a beast as a "template engineer" - someone who is skilled in HTML and
> who understands coding without ever having had formal programming training.
Actually, we have several TE's working for us at CollabNet and several of
our clients also "supply" people with these skills to work with us.
> Call me traditionalist, but having coding done by non-coders is a recipe for
> disaster. For example, I think that a template engineer who was capable of
> rewriting templates to split a form across several pages would probably be
> worth paying as much as a Java coder anyway. For example, you can easily
> hire a qualified HTML coder or a Java coder, but it's pretty difficult to
> hire a qualified "template author", especially when you want them to know
> your own flavour of YATL.
I agree, that is a traditionalist point of view. That is why I'm working
hard to come up with solutions to break that POV and smash it to shreds.
We are getting very close over in Turbine/Velocity land. There is one last
major thing to do which John McNally is working on...automatic handling and
generation of the objects which represent the <form>. In other words, we
want to be able to define the business logic for our forms in a .xml file
and then auto-generate Java code as needed to deal with handling of the
forms. Think Object-Relational tool not for RDBMS, but for <FORMS>! :-) Even
cooler is that this will be tied into the OR definitions in order to define
things like the maxlength of a form input text field based on the size of
the column definition. We will also support things like auto-populating of
the form data when the page is redisplayed due to an error or in the case
where we are re-displaying the page to show previously entered data.
This isn't anything really "new"...however, it is fairly new in the context
of Java App Frameworks that are OSS as well as being implemented within the
idea of the 100% pull paradigm.
If you would like to be part of this, we welcome you to subscribe to the
Turbine list and start discussing it.
> Saying all that I'm sure if you set up your organisation with these three
> classes of developers it would work. It's simply a question of which way
> would be more efficient overall. I favour the 2 role way, you the 3 role
> way.
Right, let me repeat what I'm hearing you say: in the 2 role way, you would
have a designer and an java engineer. In that case, that is fine as well,
the java engineer would simply be responsible for the template engineer's
job.
In CollabNet's case though, we have clients which may be "web savvy" enough
to be able to learn enough template language and API's (although maybe not
savvy enough to learn Java) and we need to be able to give them a way to
edit/modify their sites that we create for them without having to have us
involved all the time. In other words, we need to be able to scale our
business without having to hire huge teams of engineers to support our ever
growing client base.
> Aw, chill out man! You just come across as, er, quite opinionated, thats why
> people always get the wrong impression. I've been hanging around this scene
> for long enough to appreciate the way you do stuff... without getting _too_
> upset :-) Certainly no need for any paranioa ... :-)
I agree. I'm very opinionated. I'm also glad there is someone like
me...otherwise, we would all continue to sit around the table looking silly
at each other at dinner with nothing to say! :-)
thanks,
-jon
RE: An alternative to JSP
Posted by Paulo Gaspar <pa...@krankikom.de>.
I would not call them "template engineers", but I already called them
scripters.
Anyway, I am sure there is an intermediate class of coders and there
are much more of them (with different degrees of skill) than of the
so called "Java engineers".
My experience is that they are able to take over after I build a basic
template by placing the necessary markers/instructions on the basic
HTML. Being used to do tasks like writing/changing simple Javascript,
they have no problems understanding the very basic syntax of these
"template languages".
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Geoff Soutter [mailto:geoff@whitewolf.com.au]
> Sent: Monday, January 15, 2001 02:35
>
> Seems to me that your argument rests on the assumption that there exists
> such a beast as a "template engineer" - someone who is skilled in HTML and
> who understands coding without ever having had formal programming
> training.
> Call me traditionalist, but having coding done by non-coders is a
> recipe for
> disaster. For example, I think that a template engineer who was capable of
> rewriting templates to split a form across several pages would probably be
> worth paying as much as a Java coder anyway. For example, you can easily
> hire a qualified HTML coder or a Java coder, but it's pretty difficult to
> hire a qualified "template author", especially when you want them to know
> your own flavour of YATL.
>
> Saying all that I'm sure if you set up your organisation with these three
> classes of developers it would work. It's simply a question of which way
> would be more efficient overall. I favour the 2 role way, you the 3 role
> way.
>
Re: An alternative to JSP
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Jon Stevens" <jo...@latchkey.com> wrote:
> on 1/14/01 3:11 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
>
> > "Jon Stevens" <jo...@latchkey.com> wrote:
> >> on 1/11/01 8:30 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
> >
> > [snip]
> >
> >> Let me also state that at this point in time, I see Velocity+Turbine as
> >> being one of the best solutions out there.
> >
> > I agree it has benefits over JSP, but I do think it's still too hard for
> > HTML only coders to deal with the Velocity syntax. Does an HTML person
> > understand what $data.Parameters.getString($key) means? I think not. So,
> > WM/Velocity is good (or at least better than JSP :-) for developing apps
> > where the HTML is developed by people with Java experience - but thats
> > exactly what I believe we should be heading away from.
>
> Actually, you have missed the point entirely. I'm not expecting or even
> asking designers to understand what $data.Parameters.getString($key)
means,
> however, I can expect them to be able to work around those fields in a
page.
>
> There are several classifications of people who are expected to work on a
> web application:
>
> #1. Designers. People who know HTML. May know some javascript. Nothing
more.
> #2. Template Engineers. People who know how to work with an API and
> understand the template language (ie: people who understand what
> $data.Parameters.getString($key) *does*, but may not understand the Java
> behind it). Eventually, they may become engineers.
> #3. Java Engineers. People who are responsible for developing the API and
> doing the Actions.
[snip]
> > In contrast XMLC seems to be heading in the right direction because
template
> > authors need only understand (pure) HTML. Not that I'm necessarily
> > recommending XMLC as a practical solution, I've never used that
either...
> > but I have written YATL, so I feel I have enough experience to comment.
>
> Right, however XMLC is push based and that is bad for all the reasons
> documented in my Pull document. It also has the problem of tying the HTML
to
> the Java code. For example, say you want to break elements of a <form>
> across several pages. If you can't do that without editing Java code on
the
> back end, that is bad because then you have to pay java engineers to make
> the changes that template engineers should be able to do.
Seems to me that your argument rests on the assumption that there exists
such a beast as a "template engineer" - someone who is skilled in HTML and
who understands coding without ever having had formal programming training.
Call me traditionalist, but having coding done by non-coders is a recipe for
disaster. For example, I think that a template engineer who was capable of
rewriting templates to split a form across several pages would probably be
worth paying as much as a Java coder anyway. For example, you can easily
hire a qualified HTML coder or a Java coder, but it's pretty difficult to
hire a qualified "template author", especially when you want them to know
your own flavour of YATL.
Saying all that I'm sure if you set up your organisation with these three
classes of developers it would work. It's simply a question of which way
would be more efficient overall. I favour the 2 role way, you the 3 role
way.
> > Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm
only
> > interested in the theoretical issues.
>
> It wasn't a flame war. It really saddens me to always be guilty before
being
> proven innocent. Quit thinking that I'm always trying to start a flame
war.
> This is a conversation and if I don't agree with something, that isn't a
> flame...that is me stating an opinion.
Aw, chill out man! You just come across as, er, quite opinionated, thats why
people always get the wrong impression. I've been hanging around this scene
for long enough to appreciate the way you do stuff... without getting _too_
upset :-) Certainly no need for any paranioa ... :-)
> I spent a bunch of time coming up
> with valid reasons why other technologies are sorely lacking. At least you
> could do the same.
I think I am! :-)
Cheers
Geoff
RE: An alternative to JSP
Posted by Paulo Gaspar <pa...@krankikom.de>.
I have seen even DreamWeaver-only designers (with low understanding of
HTML) doing just that with no problems.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Monday, January 15, 2001 01:49
>
> on 1/14/01 3:11 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
>
> Actually, you have missed the point entirely. I'm not expecting or even
> asking designers to understand what
> $data.Parameters.getString($key) means,
> however, I can expect them to be able to work around those fields
> in a page.
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/14/01 3:11 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
> "Jon Stevens" <jo...@latchkey.com> wrote:
>> on 1/11/01 8:30 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
>
> [snip]
>
>> Let me also state that at this point in time, I see Velocity+Turbine as
>> being one of the best solutions out there.
>
> I agree it has benefits over JSP, but I do think it's still too hard for
> HTML only coders to deal with the Velocity syntax. Does an HTML person
> understand what $data.Parameters.getString($key) means? I think not. So,
> WM/Velocity is good (or at least better than JSP :-) for developing apps
> where the HTML is developed by people with Java experience - but thats
> exactly what I believe we should be heading away from.
Actually, you have missed the point entirely. I'm not expecting or even
asking designers to understand what $data.Parameters.getString($key) means,
however, I can expect them to be able to work around those fields in a page.
There are several classifications of people who are expected to work on a
web application:
#1. Designers. People who know HTML. May know some javascript. Nothing more.
#2. Template Engineers. People who know how to work with an API and
understand the template language (ie: people who understand what
$data.Parameters.getString($key) *does*, but may not understand the Java
behind it). Eventually, they may become engineers.
#3. Java Engineers. People who are responsible for developing the API and
doing the Actions.
> In contrast XMLC seems to be heading in the right direction because template
> authors need only understand (pure) HTML. Not that I'm necessarily
> recommending XMLC as a practical solution, I've never used that either...
> but I have written YATL, so I feel I have enough experience to comment.
Right, however XMLC is push based and that is bad for all the reasons
documented in my Pull document. It also has the problem of tying the HTML to
the Java code. For example, say you want to break elements of a <form>
across several pages. If you can't do that without editing Java code on the
back end, that is bad because then you have to pay java engineers to make
the changes that template engineers should be able to do.
> Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only
> interested in the theoretical issues.
It wasn't a flame war. It really saddens me to always be guilty before being
proven innocent. Quit thinking that I'm always trying to start a flame war.
This is a conversation and if I don't agree with something, that isn't a
flame...that is me stating an opinion. I spent a bunch of time coming up
with valid reasons why other technologies are sorely lacking. At least you
could do the same.
-jon
--
Honk if you love peace and quiet.
Re: An alternative to JSP
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Jon Stevens" <jo...@latchkey.com> wrote:
> on 1/11/01 8:30 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
[snip]
> Let me also state that at this point in time, I see Velocity+Turbine as
> being one of the best solutions out there.
I agree it has benefits over JSP, but I do think it's still too hard for
HTML only coders to deal with the Velocity syntax. Does an HTML person
understand what $data.Parameters.getString($key) means? I think not. So,
WM/Velocity is good (or at least better than JSP :-) for developing apps
where the HTML is developed by people with Java experience - but thats
exactly what I believe we should be heading away from.
In contrast XMLC seems to be heading in the right direction because template
authors need only understand (pure) HTML. Not that I'm necessarily
recommending XMLC as a practical solution, I've never used that either...
but I have written YATL, so I feel I have enough experience to comment.
> In conclusion, let me restate that I feel that Turbine+Velocity is the
right
> way to implement Pull functionality for a simple to complex web
application.
Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only
interested in the theoretical issues.
Cheers
Geoff
RE: An alternative to JSP
Posted by Tomas Rokicki <ro...@instantis.com>.
> Exactly. It would have been nice if JSP was done right from the start
> instead of having an original goal of attempting to provide a solution to
> strictly compete with ASP.
My thought is that JSP was `done right from the start' (at least, with
custom taglibs)---it just doesn't solve the whole problem, nor would I
want it to.
> <logic:iterate id="parameter" name="parameters">
The main problem I have against tag libs and tag-based templates is the
tags are either invisible in the HTML view or else some squiggly little
box; it's really tough to get semantic information (hence my use of
%% rather than <> in my template language). Of course, dreamweaver is
making that better, but even in dreamweaver it's still a box that
looks like [~].
Until of course you turn on tomcat, which we do and our developers do, to
see what's happening with the real server, but it's great to actually
have a clue what you're looking at in the main view too.
I'll shut up now and let everyone get back to work on TOTL (their own
template language).
-tom
RE: An alternative to JSP
Posted by Peter Donald <do...@apache.org>.
At 07:22 12/1/01 -0600, Nick Bauman wrote:
>Somewhat unrelated, I hear a lot of people going gaga over XSLT for web
>development. I understand the desire: a single document represents the
>data of the page, while other documents are used to convert that data for
>different clients / views with an emphasis on content seperation from
>presentation logic.
>But AFAIK, this is only 1/2 the battle. I still have business logic which
>cannot be handled in the XSLT code. Add the amount of work just to get the
>presentation away from the content in a standards-compliant fashion
>(work in both a human and a computer terms) isn't worth it unless, say, I
>was going to implement web, WAP and Palm OS views for the Library of
>Congress or the Human Genome Project. But all that just for Acme Widgets,
>who has, at the most, 2000 products.
Have a look at Cocoon - it's got the early stages of it going through. True
it is still too complex but as it matures I think it will come down to a
reasonable level of complexity thou I mainly worked with XML so I may be
biased ;)
Plain XML + XSLT is not a possibility (if you have the slightest concern
for performance) but with various generation techniques (like XSP - cocoons
answer to asp/jsp) combined with enforced separation of concerns (ie set a
flag to disable embedded logic and only go through taglibs) it could
definetly be a good option for the future.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: An alternative to JSP
Posted by Paulo Gaspar <pa...@krankikom.de>.
I used XSLT as a template mechanism and my feeling is that it is too heavy
and too problematic for that purpose. WebMacro, Velocity and FreeMarker
are less problematic and lighter.
I have seen people trying to use XSLT for business logic just because they
want to do everything with it, and they turned simple problems into very
complicated ones. Just take a look at the XSLT mailing list archives and
you too will have e good idea of what I am talking about.
With designers and "scripters", it gets even worse:
- They can not use DreamWeaver and other visual design tools to
manipulate the template;
- They don't really understand the idea behind XSLT that affects many of
its constructions (the stream of nodes thing and how transformations
pipe those nodes);
- They get lost with syntax issues all the time, even stumbling in things
like the importance of the value in the "xmlns:xsl" property in the
"xsl:stylesheet" tag, as in:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
(If you change that value to what was used by Internet Explorer's
version of the MSXML parser, most other XSLT engines will do nothing
with it and MSXML3 will try using IE's XSLT dialect instead of the
standard.)
Now, this designers and scripters with a low level of sophistication are
very productive with simpler template mechanisms like WebMacro, Velocity
or Freemarker. And there are a lot more of them then full fledged
programmers.
We need the few full fledged programmers we have to work in the core
business logic instead of having them solving XSLT related issues.
OTOH, JSP's custom taglibs provide a mechanism to build simple dialects
that make those scripters that understand SQL (we have several)
productive on the simple logic that is necessary to build the data for
a report - and most of our dynamic pages are reports.
With taglibs for retrieving SQL data and applying a Velocity/WebMacro
template to it, one can do a lot.
With a caching taglib around JSP code which results can be cached, one
can do a lot working with a lot of performance.
For me, this is just a real world scenario.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: Saturday, January 13, 2001 02:23
>
> Somewhat unrelated, I hear a lot of people going gaga over XSLT for web
> development. I understand the desire: a single document represents the
> data of the page, while other documents are used to convert that data for
> different clients / views with an emphasis on content seperation from
> presentation logic.
>
> But AFAIK, this is only 1/2 the battle. I still have business logic which
> cannot be handled in the XSLT code. Add the amount of work just to get the
> presentation away from the content in a standards-compliant fashion
> (work in both a human and a computer terms) isn't worth it unless, say, I
> was going to implement web, WAP and Palm OS views for the Library of
> Congress or the Human Genome Project. But all that just for Acme Widgets,
> who has, at the most, 2000 products.
>
> Kinda like using the Space Shuttle to go grocery shopping.
>
RE: An alternative to JSP
Posted by Nick Bauman <ni...@cortexity.com>.
Somewhat unrelated, I hear a lot of people going gaga over XSLT for web
development. I understand the desire: a single document represents the
data of the page, while other documents are used to convert that data for
different clients / views with an emphasis on content seperation from
presentation logic.
But AFAIK, this is only 1/2 the battle. I still have business logic which
cannot be handled in the XSLT code. Add the amount of work just to get the
presentation away from the content in a standards-compliant fashion
(work in both a human and a computer terms) isn't worth it unless, say, I
was going to implement web, WAP and Palm OS views for the Library of
Congress or the Human Genome Project. But all that just for Acme Widgets,
who has, at the most, 2000 products.
Kinda like using the Space Shuttle to go grocery shopping.
On Fri, 12 Jan 2001, Paulo Gaspar wrote:
> Besides, I still found no great support for custom taglibs on
> DreamWeaver/UltraDev.
>
>
> OTOH, JSP + Custom Taglibs + Velocity/WebMacro can be a nice solution. I
> work with people that can use a couple of custom taglibs + SQL to get data
> from a database and then make a Vel./WM template work. They already do it
> with the XSQLServlet, and using XSLT as a template mechanism is much
> harder.
>
> Custom taglibs can be used to provide simple dialects that help getting
> productive people able to do simple scripting.
>
> There is a lot of this people. It is not only designers/full fledged
> programmers.
>
>
> Have fun,
> Paulo
>
>
> > -----Original Message-----
> > From: Jon Stevens [mailto:jon@latchkey.com]
> > Sent: Friday, January 12, 2001 21:58
> >
> >
> > > One can edit this stuff by hand if you want, but we're also
> > starting to see
> > > IDE
> > > tools that understand this stuff -- complete with popping up
> > dialong boxes to
> > > populate the appropriate attributes -- in the same way the IDE tools for
> > > building JavaBeans took much of the drudgery out of that process.
> >
> > Right, Dreamweaver's recent additions sound very cool and a much needed
> > advancement for helping with JSP, however, it isn't real feasible as a
> > requirement for working on OSS projects since it is commercial
> > (expensive!)
> > software. :-(
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
RE: An alternative to JSP
Posted by Paulo Gaspar <pa...@krankikom.de>.
Besides, I still found no great support for custom taglibs on
DreamWeaver/UltraDev.
OTOH, JSP + Custom Taglibs + Velocity/WebMacro can be a nice solution. I
work with people that can use a couple of custom taglibs + SQL to get data
from a database and then make a Vel./WM template work. They already do it
with the XSQLServlet, and using XSLT as a template mechanism is much
harder.
Custom taglibs can be used to provide simple dialects that help getting
productive people able to do simple scripting.
There is a lot of this people. It is not only designers/full fledged
programmers.
Have fun,
Paulo
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Friday, January 12, 2001 21:58
>
>
> > One can edit this stuff by hand if you want, but we're also
> starting to see
> > IDE
> > tools that understand this stuff -- complete with popping up
> dialong boxes to
> > populate the appropriate attributes -- in the same way the IDE tools for
> > building JavaBeans took much of the drudgery out of that process.
>
> Right, Dreamweaver's recent additions sound very cool and a much needed
> advancement for helping with JSP, however, it isn't real feasible as a
> requirement for working on OSS projects since it is commercial
> (expensive!)
> software. :-(
>
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/12/01 12:31 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> So did you Jon ... it's called Velocity :-)
Exactly. It would have been nice if JSP was done right from the start
instead of having an original goal of attempting to provide a solution to
strictly compete with ASP.
> JSP, as Tomas points out, is a low level toolkit, on top of which you can
> build
> higher level constructs (with custom tags). For example, the Struts-based
> equivalent of your example is (where "parameters" is a bean in some scope that
> is a Collection, a Map, or an array):
>
> <logic:iterate id="parameter" name="parameters">
> <tr>
> <td><bean:write name="parameter" property="key"/></td>
> <td><bean:write name="<%= parameter.getKey() %>"/></td>
> </tr>
> </logic:iterate>
I will restate the point of my earlier email...
Jon said:
> In other words, yes, you could have done the above JSP snippet correctly,
> however, my issue with JSP is that it almost encourages you to do it
> incorrectly.
...
> One can edit this stuff by hand if you want, but we're also starting to see
> IDE
> tools that understand this stuff -- complete with popping up dialong boxes to
> populate the appropriate attributes -- in the same way the IDE tools for
> building JavaBeans took much of the drudgery out of that process.
Right, Dreamweaver's recent additions sound very cool and a much needed
advancement for helping with JSP, however, it isn't real feasible as a
requirement for working on OSS projects since it is commercial (expensive!)
software. :-(
> But, of course, Jon and I go *way* back on this particular topic :-).
:-)
-jon
Re: So? Is it ready yet?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Nick Bauman wrote:
> Have you gotten the new Bugzilla system ready?
>
> Please let me know when / if I should close down the report page for
> bugrat.
>
Almost ... personally, I want to do just a bit more testing first ...
>
> Thanks
>
> -Nick (The guy running bugrat for Jakarta)
>
Craig
So? Is it ready yet?
Posted by Nick Bauman <ni...@cortexity.com>.
Have you gotten the new Bugzilla system ready?
Please let me know when / if I should close down the report page for
bugrat.
Thanks
-Nick (The guy running bugrat for Jakarta)
Re: An alternative to JSP
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:
> on 1/12/01 11:49 AM, "Tomas Rokicki" <ro...@instantis.com> wrote:
>
> > With the solution we're deploying in-house here, your dynamic row
> > example is just
> >
> > <table><tr><td>%tr rundata%%key%</td><td> = %value%</td></tr></table>
> >
> > which is editable in WYSIWYG HTML editors, contains no Java code,
> > and so on . . . the magic %tr ...% tells it to iterate on table rows.
> >
> > Oh, but of course it's YATL so I'll shut up now. (It compiles down
> > to JSPs.)
>
> Exactly. JSP alone didn't solve your problem. You had to do YATL in order to
> get it to do what you want. That just seems odd to me.
>
So did you Jon ... it's called Velocity :-)
JSP, as Tomas points out, is a low level toolkit, on top of which you can build
higher level constructs (with custom tags). For example, the Struts-based
equivalent of your example is (where "parameters" is a bean in some scope that
is a Collection, a Map, or an array):
<logic:iterate id="parameter" name="parameters">
<tr>
<td><bean:write name="parameter" property="key"/></td>
<td><bean:write name="<%= parameter.getKey() %>"/></td>
</tr>
</logic:iterate>
One can edit this stuff by hand if you want, but we're also starting to see IDE
tools that understand this stuff -- complete with popping up dialong boxes to
populate the appropriate attributes -- in the same way the IDE tools for
building JavaBeans took much of the drudgery out of that process.
But, of course, Jon and I go *way* back on this particular topic :-).
>
> -jon
>
Craig
RE: An alternative to JSP
Posted by Tomas Rokicki <ro...@instantis.com>.
I don't look at it as odd at all. JSP and servlets in general
are *very low level* abstractions. They are incredibly useful,
but they are at such a low level that it's very difficult to
build a complex application. It's like coding in machine
language. It's not that difficult to add a layer or two to
raise the level of abstraction.
The good thing about JSP and servlets is they provide a stable,
portable, and solid base with good engineering. They are
complex enough that getting them implemented correctly is
nontrivial (hence all the work on tomcat etc.) but yet generic
enough that different abstractions can easily be constructed
on top of them. This is precisely what I want, a
good solid base engineered well on which I can build what
we need.
All the experimentation with the various macro languages and
the like is all good, and we'll all learn from them and
eventually it will all converge [or fail to do so]; I don't
see that it has happened yet, and each solution has its pros
and cons, none of which were acceptable when we started our
project, which is why I've got a stupid lightweight YATL that
we use in-house that solves our problems.
I just thought I'd toss out an example of how we solved the
`no code in JSP' problem.
-tom
-----Original Message-----
From: Jon Stevens [mailto:jon@latchkey.com]
Sent: Friday, January 12, 2001 11:54 AM
To: tomcat-dev@jakarta.apache.org
Subject: Re: An alternative to JSP
on 1/12/01 11:49 AM, "Tomas Rokicki" <ro...@instantis.com> wrote:
> With the solution we're deploying in-house here, your dynamic row
> example is just
>
> <table><tr><td>%tr rundata%%key%</td><td> = %value%</td></tr></table>
>
> which is editable in WYSIWYG HTML editors, contains no Java code,
> and so on . . . the magic %tr ...% tells it to iterate on table rows.
>
> Oh, but of course it's YATL so I'll shut up now. (It compiles down
> to JSPs.)
Exactly. JSP alone didn't solve your problem. You had to do YATL in order to
get it to do what you want. That just seems odd to me.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/12/01 11:49 AM, "Tomas Rokicki" <ro...@instantis.com> wrote:
> With the solution we're deploying in-house here, your dynamic row
> example is just
>
> <table><tr><td>%tr rundata%%key%</td><td> = %value%</td></tr></table>
>
> which is editable in WYSIWYG HTML editors, contains no Java code,
> and so on . . . the magic %tr ...% tells it to iterate on table rows.
>
> Oh, but of course it's YATL so I'll shut up now. (It compiles down
> to JSPs.)
Exactly. JSP alone didn't solve your problem. You had to do YATL in order to
get it to do what you want. That just seems odd to me.
-jon
RE: An alternative to JSP
Posted by Tomas Rokicki <ro...@instantis.com>.
With the solution we're deploying in-house here, your dynamic row
example is just
<table><tr><td>%tr rundata%%key%</td><td> = %value%</td></tr></table>
which is editable in WYSIWYG HTML editors, contains no Java code,
and so on . . . the magic %tr ...% tells it to iterate on table rows.
Oh, but of course it's YATL so I'll shut up now. (It compiles down
to JSPs.)
-----Original Message-----
From: Jon Stevens [mailto:jon@latchkey.com]
Sent: Friday, January 12, 2001 11:39 AM
To: tomcat-dev@jakarta.apache.org
Subject: Re: An alternative to JSP
on 1/11/01 8:30 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
> Yeah, but thats an impl detail. You could easily modify it to load the
HTML
> on the fly, so that the HTML could be modified separately. The main thing
I
> like here is that you actually start with a "proper" HTML file, without a
> proliferation of proprietary "Cold Fusion" style tags. That way HTML codes
> can actually code real HTML, rather than some weird proprietary HTML
> sublanguage. Allaires "content management" thingo Spectra defines 400 +
> tags - how is your average HTML coder gonna deal with that? Course, it has
> other problems but hey, that was my original thesis ... unfortunately the
> real world is a complex place :-).
Ok, so what I hear you saying is that you are comparing XMLC against
something we all already know is not a good way of doing things? :-)
> Weren't you implying that under complex (read real world) scenarios, the
> tradtional Webmacro "push" style way of doing things breaks down? Thats
all
> I was saying. Note your pull model Webmacro starts to sound like JSP to
> me... interpreted HTML...
Quite the opposite. Let me correct you and state that I don't use/recommend
WM, I use/recommend Velocity these days as Velocity is a much better
re-implementation of the original WM *concepts*.
Let me also state that at this point in time, I see Velocity+Turbine as
being one of the best solutions out there.
WM/Velocity is *parsed* HTML, however, that is where the similarities to JSP
stop. For example, people who code JSP tend to do things like this (taken
from a recent CVS check-in by a guy from IBM to the Jetspeed project):
<%
keys = rundata.getParameters().keys();
while ( keys.hasMoreElements() )
{
key = (String) keys.nextElement();
value = rundata.getParameters().getString(key);
out.println("<tr><td><b>"+key+"</b></td><td> = " + value +
"</td></tr>");
}
%>
The issue with that is that you are no embedding HTML code into your Java
code. How many designers without any programming skills (but have HTML
skills) do you know can edit something like that? What if the person wanted
to embed a bgcolor= attributed into the <td> tag? Then they would suddenly
also have to learn how to escape double quotes as well. Not very
maintainable IMHO.
With WM/Velocity, you would write the above something like this:
#foreach ( $key in $data.Parameters.Keys )
<tr>
<td><b>$key</b></td>
<td> = $data.Parameters.getString($key)</td>
</tr>
#end
Velocity has a well defined simple *template* syntax that prevents you from
making the mistakes that JSP doesn't prevent you from. In other words, yes,
you could have done the above JSP snippet correctly, however, my issue with
JSP is that it almost encourages you to do it incorrectly.
Also, the other advantage of the above Velocity example is that if you load
it into a browser without running it through the parser (ie: just load the
static template), it shows up ugly, but you can easily see the logic of what
you are trying to accomplish. If you loaded the JSP example the same
way...all you would see is...nothing.
In conclusion, let me restate that I feel that Turbine+Velocity is the right
way to implement Pull functionality for a simple to complex web application.
thanks,
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/11/01 8:30 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
> Yeah, but thats an impl detail. You could easily modify it to load the HTML
> on the fly, so that the HTML could be modified separately. The main thing I
> like here is that you actually start with a "proper" HTML file, without a
> proliferation of proprietary "Cold Fusion" style tags. That way HTML codes
> can actually code real HTML, rather than some weird proprietary HTML
> sublanguage. Allaires "content management" thingo Spectra defines 400 +
> tags - how is your average HTML coder gonna deal with that? Course, it has
> other problems but hey, that was my original thesis ... unfortunately the
> real world is a complex place :-).
Ok, so what I hear you saying is that you are comparing XMLC against
something we all already know is not a good way of doing things? :-)
> Weren't you implying that under complex (read real world) scenarios, the
> tradtional Webmacro "push" style way of doing things breaks down? Thats all
> I was saying. Note your pull model Webmacro starts to sound like JSP to
> me... interpreted HTML...
Quite the opposite. Let me correct you and state that I don't use/recommend
WM, I use/recommend Velocity these days as Velocity is a much better
re-implementation of the original WM *concepts*.
Let me also state that at this point in time, I see Velocity+Turbine as
being one of the best solutions out there.
WM/Velocity is *parsed* HTML, however, that is where the similarities to JSP
stop. For example, people who code JSP tend to do things like this (taken
from a recent CVS check-in by a guy from IBM to the Jetspeed project):
<%
keys = rundata.getParameters().keys();
while ( keys.hasMoreElements() )
{
key = (String) keys.nextElement();
value = rundata.getParameters().getString(key);
out.println("<tr><td><b>"+key+"</b></td><td> = " + value +
"</td></tr>");
}
%>
The issue with that is that you are no embedding HTML code into your Java
code. How many designers without any programming skills (but have HTML
skills) do you know can edit something like that? What if the person wanted
to embed a bgcolor= attributed into the <td> tag? Then they would suddenly
also have to learn how to escape double quotes as well. Not very
maintainable IMHO.
With WM/Velocity, you would write the above something like this:
#foreach ( $key in $data.Parameters.Keys )
<tr>
<td><b>$key</b></td>
<td> = $data.Parameters.getString($key)</td>
</tr>
#end
Velocity has a well defined simple *template* syntax that prevents you from
making the mistakes that JSP doesn't prevent you from. In other words, yes,
you could have done the above JSP snippet correctly, however, my issue with
JSP is that it almost encourages you to do it incorrectly.
Also, the other advantage of the above Velocity example is that if you load
it into a browser without running it through the parser (ie: just load the
static template), it shows up ugly, but you can easily see the logic of what
you are trying to accomplish. If you loaded the JSP example the same
way...all you would see is...nothing.
In conclusion, let me restate that I feel that Turbine+Velocity is the right
way to implement Pull functionality for a simple to complex web application.
thanks,
-jon
Re: An alternative to JSP
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Jon Stevens" <jo...@latchkey.com> wrote:
> on 1/11/01 6:32 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
>
> > Certainly I've never seen what I consider to be a clean way of letting
HTML
> > people do HTML and Java people do Java. Yes, I've seen some that are
better
> > than others (XMLC is probably the cleanest I've seen)
>
> XMLC has the disadvantage of being entirely push based. It requires
changes
> to your Java code in order to change your HTML. That is bad.
Yeah, but thats an impl detail. You could easily modify it to load the HTML
on the fly, so that the HTML could be modified separately. The main thing I
like here is that you actually start with a "proper" HTML file, without a
proliferation of proprietary "Cold Fusion" style tags. That way HTML codes
can actually code real HTML, rather than some weird proprietary HTML
sublanguage. Allaires "content management" thingo Spectra defines 400 +
tags - how is your average HTML coder gonna deal with that? Course, it has
other problems but hey, that was my original thesis ... unfortunately the
real world is a complex place :-).
> >, but there are always
> > problems if you consider anything other than completely simplistic
examples.
> > Witness Jon's Pull Model document... :-)
> >
> > Geoff
Weren't you implying that under complex (read real world) scenarios, the
tradtional Webmacro "push" style way of doing things breaks down? Thats all
I was saying. Note your pull model Webmacro starts to sound like JSP to
me... interpreted HTML...
Geoff
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/11/01 6:32 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
> I think the real problem with the whole JSP/WebMacro/XMLC/ASP/CF scenario is
> that HTML itself mixes presentation with logic to the point where any
> solution which needs to generate HTML is naturally going to be hacky.
I don't agree in the Velocity/WM case because there really isn't any "logic"
that you can embed into your HTML in this case.
> Certainly I've never seen what I consider to be a clean way of letting HTML
> people do HTML and Java people do Java. Yes, I've seen some that are better
> than others (XMLC is probably the cleanest I've seen)
XMLC has the disadvantage of being entirely push based. It requires changes
to your Java code in order to change your HTML. That is bad.
>, but there are always
> problems if you consider anything other than completely simplistic examples.
> Witness Jon's Pull Model document... :-)
>
> Geoff
I'm confused by that statement. Please explain.
-jon
Re: An alternative to JSP
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Paul Speed" <Pa...@metrixpoint.com> wrote:
>
> Geoff Soutter wrote:
> >
> > "Paul Speed" <Pa...@metrixpoint.com> wrote:
> >
> > [snip]
> >
> > > For what it's worth, I think that custom tags are the thing
> > > that really saves JSP. On my last project, we were able to
> > > encapsulate all logic into a servlet framework and custom tags.
> > > (Actually, our framework ended up looking very similar to struts
> > > which I think is a very natural evolution of the smart-servlet
> > > design.)
> >
> > Depends what you are trying to do. If you want non-java developers to
edit
> > the source, then custom tags _do_ save the day. Alternatively, Java in
HTML
> > ruins things nicely.
> >
> > IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not
_useful_,
> > it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
> > there are out there. Course now it has the J2EE stamp of approval, how
good
> > it actually is becomes irrelevant. Sigh.
> >
>
> Yeah, but the nice thing is that it's easy to spot Java code
> in HTML during a code-review... it just looks ugly. It would be nice
> if there was a switch on the JSP compiler that specifically
> disallowed it.
>
> Once you've clamped down on the use of Java code inside the
> JSP's then the developer is forced to use the custom tags. If the
> custom tags only provide presentation control then you can be fairly
> sure that no business/application logic is creeping its way into the
> JSP code.
It reminds me of C or C++ compared to Java - any language where you require
too much self control in order to use it effectively is nasty.
> I've always found it funny that the custom tag examples put
> out by Sun inevitably show how to implement some SQL/JDBC custom
> tags. It's nice as a comparison to Cold Fusion or PHP, but putting
> SQL code right into the HTML is the thing that makes most of us who
> have been doing this for a while cringe. :)
Yeah, it's funny huh. And of course thats exactly the kind of feature that
the majority of JSP coders probably use... sigh.
I think the real problem with the whole JSP/WebMacro/XMLC/ASP/CF scenario is
that HTML itself mixes presentation with logic to the point where any
solution which needs to generate HTML is naturally going to be hacky.
Certainly I've never seen what I consider to be a clean way of letting HTML
people do HTML and Java people do Java. Yes, I've seen some that are better
than others (XMLC is probably the cleanest I've seen), but there are always
problems if you consider anything other than completely simplistic examples.
Witness Jon's Pull Model document... :-)
Geoff
Re: An alternative to JSP
Posted by Paul Speed <Pa...@metrixpoint.com>.
Geoff Soutter wrote:
>
> "Paul Speed" <Pa...@metrixpoint.com> wrote:
>
> [snip]
>
> > For what it's worth, I think that custom tags are the thing
> > that really saves JSP. On my last project, we were able to
> > encapsulate all logic into a servlet framework and custom tags.
> > (Actually, our framework ended up looking very similar to struts
> > which I think is a very natural evolution of the smart-servlet
> > design.)
>
> Depends what you are trying to do. If you want non-java developers to edit
> the source, then custom tags _do_ save the day. Alternatively, Java in HTML
> ruins things nicely.
>
> IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not _useful_,
> it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
> there are out there. Course now it has the J2EE stamp of approval, how good
> it actually is becomes irrelevant. Sigh.
>
Yeah, but the nice thing is that it's easy to spot Java code
in HTML during a code-review... it just looks ugly. It would be nice
if there was a switch on the JSP compiler that specifically
disallowed it.
Once you've clamped down on the use of Java code inside the
JSP's then the developer is forced to use the custom tags. If the
custom tags only provide presentation control then you can be fairly
sure that no business/application logic is creeping its way into the
JSP code.
I've always found it funny that the custom tag examples put
out by Sun inevitably show how to implement some SQL/JDBC custom
tags. It's nice as a comparison to Cold Fusion or PHP, but putting
SQL code right into the HTML is the thing that makes most of us who
have been doing this for a while cringe. :)
I can't think of a better generalized example though.
-Paul
RE: An alternative to JSP
Posted by Tomas Rokicki <ro...@instantis.com>.
> Whatcha looking for: np.instantis.com ???
Just curious to see what's happening over there, nothing more.
That's what browsers are for. What's the relevance to Tomcat?
-tom
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/11/01 4:53 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> <http://www.whichever.com/jsp.gif>
Now this is fun...
216.216.10.57 - - [11/Jan/2001:17:03:45 -0800] "GET /jsp.gif HTTP/1.1" 200
74620
216.216.10.57 - - [11/Jan/2001:17:06:54 -0800] "GET / HTTP/1.1" 200 5
216.216.10.57 - - [11/Jan/2001:17:07:01 -0800] "GET /WEB-INF HTTP/1.1" 404
287
216.216.10.57 - - [11/Jan/2001:17:07:08 -0800] "GET /index.html HTTP/1.1"
200 5
216.216.10.57 - - [11/Jan/2001:17:07:23 -0800] "GET /robots.txt HTTP/1.1"
404 29
Whatcha looking for: np.instantis.com ???
-jon (who is amazed at how many people have looked at that image)
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/11/01 4:25 PM, "Geoff Soutter" <ge...@whitewolf.com.au> wrote:
> IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not _useful_,
> it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
> there are out there. Course now it has the J2EE stamp of approval, how good
> it actually is becomes irrelevant. Sigh.
>
> Geoff.
This is one of my more memorable .gif images...
<http://www.whichever.com/jsp.gif>
:-)
Nice to see NASA using our software.
-jon
Re: An alternative to JSP
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Paul Speed" <Pa...@metrixpoint.com> wrote:
[snip]
> For what it's worth, I think that custom tags are the thing
> that really saves JSP. On my last project, we were able to
> encapsulate all logic into a servlet framework and custom tags.
> (Actually, our framework ended up looking very similar to struts
> which I think is a very natural evolution of the smart-servlet
> design.)
Depends what you are trying to do. If you want non-java developers to edit
the source, then custom tags _do_ save the day. Alternatively, Java in HTML
ruins things nicely.
IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not _useful_,
it's just not _elegant_. Look at all the spagetti-code ASP and CF sites
there are out there. Course now it has the J2EE stamp of approval, how good
it actually is becomes irrelevant. Sigh.
Geoff.
Re: An alternative to JSP
Posted by Shawn McMurdo <sh...@lutris.com>.
Paul Speed wrote:
[...]
> As it turned out, for many of the custom tags we were able
> to write web-developer versions that didn't require the full back-end
> application server. Our web developers were then able to run tomcat
> locally to help develop their pages and see what they looked like as
> they developed. We were fortunate that most of our web designers
> steered away from WYSIWYG tools... even though they did use web edit
> tools like Homesite. The more savvy web guys were even able to make
> the tool integration look pretty seamless.
One of the advantages of XMLC is that you don't have to write any special
prototype code.
The prototype HTML used for storyboarding is exactly the same HTML used in the
applicaiton
with no modifications. The dummy data in the prototype is removed when the
real dynamic data
is inserted into the page.
With XMLC designers can use best of breed WYSIWYG design tools without
requiring special tool integration.
Shawn
--
Shawn McMurdo mailto:shawn@lutris.com
Lutris Technologies http://www.lutris.com
Enhydra.Org http://www.enhydra.org
Re: An alternative to JSP
Posted by Paul Speed <Pa...@metrixpoint.com>.
"Craig R. McClanahan" wrote:
>
[ snip ]
>
> * My personal preference for the presentation layer is JSP (and has
> been since long before I adopted a "sun.com" email address :-), for
> several reasons:
[ snip ]
>
> * Custom tags - can be used to encapsulate sophisticated
> functionality in a variety of ways, including smarter generation
> of HTML to configuring application functionality). See the
> Struts Framework project <http://jakarta.apache.org/struts>
> to get a feel for what's possible. (And Struts/Turbine/Barracuda
> each offers an alternative approach to the organization of the
> business logic as well.)
For what it's worth, I think that custom tags are the thing
that really saves JSP. On my last project, we were able to
encapsulate all logic into a servlet framework and custom tags.
(Actually, our framework ended up looking very similar to struts
which I think is a very natural evolution of the smart-servlet
design.)
We had _no_ Java code in any of our JSP pages. This was a
goal from the beginning of the project and it would have been
impossible without custom tags.
As it turned out, for many of the custom tags we were able
to write web-developer versions that didn't require the full back-end
application server. Our web developers were then able to run tomcat
locally to help develop their pages and see what they looked like as
they developed. We were fortunate that most of our web designers
steered away from WYSIWYG tools... even though they did use web edit
tools like Homesite. The more savvy web guys were even able to make
the tool integration look pretty seamless.
I'll be curious to see where the JSP spec evolves next. To
me it seems logical to start incorporating more tags along the lines
of the current bean tags. Iteration and other control structures
seems like the most common part of the wheel that tag libraries seem
to be re-inventing. Standard versions sure would be nice.
-Paul
Re: An alternative to JSP
Posted by Brad Cox <bc...@virtualschool.edu>.
At 11:12 AM -0800 01/11/2001, Craig R. McClanahan wrote:
>* I don't see any reasoning for why HTML-in-Java is better
> than any of the alternatives -- just a presumptive conclusion.
> The vast majority of the article is simply a description of your
> recommended approach.
Good point. I'll expand on this argument in the article even though
it is most relevant in the context of JSP *AND* MLS versus the
template approaches I'm aware of. That's because both JSP and MLS use
a general purpose language for executable inclusions, whereas the
template systems I've examined closely (one at this point) do not
provide general-purpose language capabilities.
>* Worse, this approach does other things:
>
> * Embeds presentation and business logic in one class,
which is not a particularly scalable approach
> * Requires a Java developer to do your page development
>
> * Makes it difficult to leverage page authoring tools
Perhaps I miscommunicated. The private methods that contain the
{{html}} need not be private methods in the controller class,
although that is the style I demonstrated in the paper and that I use
in my own work.
Noting requires the view methods to contain hardcoded strings, other
than the crude measurements in the Conclusion section that makes me
doubt that the space issue is a primary concern. Each method could
aim MLS at an html file at runtime (using the doStream() method that
MLS provides for this purpose but which I didn't mention in the
article) and let it do the executable inclusion at runtime. But good
point; I'll make this explicit in the article.
This would also eliminate the need for the outermost enclosing {{...}}, but
the executable inclusion brackets would remain. Do you object to my
belief that html experts and their tools couldn't be trained to
ignore the {{...}} wrappers around the html? I'd be interested in
hearing more about this. After all, JSP has the same problem its <%=
... %> executable inclusion syntax.
>
>* My personal preference for the presentation layer is JSP (and has
> been since long before I adopted a "sun.com" email address :-), for
> several reasons:
>
> * Separation of concerns - Mixing business logic and presentation
> logic in one file (no matter what the syntax) works OK for simple
> applications, but is not a particularly flexible long term approach.
> All of the alternatives you compare yourself to have learned (and
> implemented) this lesson. Is there perhaps a message here that
> you are missing?
I never advocated this. Syntactic validation is the responsibility of
each field, low-level semantic validation is the responsibility of
the controller, and high-level semantic validation is the
responsibility of the Bean, in some cases even in the DBMS (although
MySQL doesn't support this).
> * Custom tags - can be used to encapsulate sophisticated
> functionality in a variety of ways, including smarter generation
> of HTML to configuring application functionality). See the
> Struts Framework project <http://jakarta.apache.org/struts>
> to get a feel for what's possible. (And Struts/Turbine/Barracuda
> each offers an alternative approach to the organization of the
> business logic as well.)
I've looked at struts but not at the others. Struts sounds like a great
improvement to JSP and I'd probably have adopted it were it not for
the base objection to the whole java-in-html approach.
> * Development tools - Watch what tools like Macromedia Ultradev
> do for page developers (*not* Java developers!!!) who want to
> author pages that use custom tags for dynamic pages. I do
> not see a big future in hand coded HTML.
See above re reading html from files through MLS.
> * Alternative implementations - If Tomcat doesn't generate "good
> enough" or "fast enough" code for you (and it's pretty minimally
> acceptable at the moment), you've got choices of other vendors,
> with a reasonable shot at your pages being portable if you take
MLS relies only on Java and the servlet API. Should be portable to
anywhere, right?
--
---
Dr. Brad Cox; bcox@superdistributed.com
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
Re: An alternative to JSP
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Brad Cox wrote:
> I've uploaded an early rough draft of a pair of articles that boils
> down to a critique of the JSP approach plus source code for a quite
> different approach. I'd be very interested in feedback... of the
> constructive variety, of course ;)
>
> The articles are at http://virtualschool.edu/wap
>
I didn't (and won't) have time to study the article in depth, but would make the
following observations:
* I don't see any reasoning for why HTML-in-Java is better
than any of the alternatives -- just a presumptive conclusion.
The vast majority of the article is simply a description of your
recommended approach.
* The Multi-line Strings style will certainly appeal to PERL
developers, but to me it is YATL (yet another template language)
and does nothing to improve the expressive abilities or
productivity of a page designer.
* Worse, this approach does other things:
* Embeds presentation and business logic in one class,
which is not a particularly scalable approach
* Requires a Java developer to do your page development
* Makes it difficult to leverage page authoring tools
* My personal preference for the presentation layer is JSP (and has
been since long before I adopted a "sun.com" email address :-), for
several reasons:
* Separation of concerns - Mixing business logic and presentation
logic in one file (no matter what the syntax) works OK for simple
applications, but is not a particularly flexible long term approach.
All of the alternatives you compare yourself to have learned (and
implemented) this lesson. Is there perhaps a message here that
you are missing?
* Custom tags - can be used to encapsulate sophisticated
functionality in a variety of ways, including smarter generation
of HTML to configuring application functionality). See the
Struts Framework project <http://jakarta.apache.org/struts>
to get a feel for what's possible. (And Struts/Turbine/Barracuda
each offers an alternative approach to the organization of the
business logic as well.)
* Development tools - Watch what tools like Macromedia Ultradev
do for page developers (*not* Java developers!!!) who want to
author pages that use custom tags for dynamic pages. I do
not see a big future in hand coded HTML.
* Alternative implementations - If Tomcat doesn't generate "good
enough" or "fast enough" code for you (and it's pretty minimally
acceptable at the moment), you've got choices of other vendors,
with a reasonable shot at your pages being portable if you take
care not to use platform-specific features. If I like a template
language, but don't like the one and only implementation, what
can I do? (NOTE: Yes, Jon, I recognize that Velocity and
WebMacro intend to implement common features -- "two" is
better than "one" but still not as good as "many".)
* Wide acceptance - Go onto monster.com etc. and see how many
jobs want JSP experience nowdays. If I have a project that is due
next month, do I really want to have to take the time to train my
developers on the details of the template approach being used? And
know that I'm going to have to do that *every* time I hire someone
new from now on?
I'm not going to have time to get into any extended discussion on this, but it
was worth a cup of coffee to write down some quick thoughts.
> --
> ---
> Dr. Brad Cox; bcox@superdistributed.com
Craig McClanahan
Re: An alternative to JSP (REVISED)
Posted by Brad Cox <bc...@virtualschool.edu>.
Thanks to everyone for the comments on my paper. I've tried to
address them in the revised version by emphasizing the validation and
site architecture and moving MLS into the supporting article. The new
version is
at http://virtualschool.edu/wap.
I'd be interested whether the validation/site stuff would be appropriate
to add to Tomcat. I'd be glad to do the work if someone would point
me in the right direction.
>on 1/10/01 7:52 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>
>> I've uploaded an early rough draft of a pair of articles that boils
>> down to a critique of the JSP approach plus source code for a quite
>> different approach. I'd be very interested in feedback... of the
>> constructive variety, of course ;)
>>
> > The articles are at http://virtualschool.edu/wap
--
---
Dr. Brad Cox; bcox@superdistributed.com
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
Re: An alternative to JSP
Posted by Brad Cox <bc...@virtualschool.edu>.
Thanks. No I'm not aware of Turbine, but I am aware of the approach
described in the paper. That's what the company I was consulting for
took
that I (perhaps inaccurately) described as "similar to WebMacro".
MLS? Preprocess code? WHAT?
Could you explain what you mean by this?
At 9:41 PM -0800 01/10/2001, Jon Stevens wrote:
>on 1/10/01 7:52 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>
>> I've uploaded an early rough draft of a pair of articles that boils
>> down to a critique of the JSP approach plus source code for a quite
>> different approach. I'd be very interested in feedback... of the
>> constructive variety, of course ;)
>>
>> The articles are at http://virtualschool.edu/wap
>> --
>> ---
>> Dr. Brad Cox; bcox@superdistributed.com
>> Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
>> http://superdistributed.com: A new paradigm for a new millinneum
>> PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
>
>MLS? Preprocess code? WHAT?
>
>Have you even looked at what we are doing in Turbine/Velocity land?
>
>Also, let me also refer you to:
>
><http://java.apache.org/turbine/pullmodel.html>
>
>-jon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
---
Dr. Brad Cox; bcox@superdistributed.com
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
Re: An alternative to JSP
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/10/01 7:52 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> I've uploaded an early rough draft of a pair of articles that boils
> down to a critique of the JSP approach plus source code for a quite
> different approach. I'd be very interested in feedback... of the
> constructive variety, of course ;)
>
> The articles are at http://virtualschool.edu/wap
> --
> ---
> Dr. Brad Cox; bcox@superdistributed.com
> Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
> http://superdistributed.com: A new paradigm for a new millinneum
> PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
MLS? Preprocess code? WHAT?
Have you even looked at what we are doing in Turbine/Velocity land?
Also, let me also refer you to:
<http://java.apache.org/turbine/pullmodel.html>
-jon
An alternative to JSP
Posted by Brad Cox <bc...@virtualschool.edu>.
I've uploaded an early rough draft of a pair of articles that boils
down to a critique of the JSP approach plus source code for a quite
different approach. I'd be very interested in feedback... of the
constructive variety, of course ;)
The articles are at http://virtualschool.edu/wap
--
---
Dr. Brad Cox; bcox@superdistributed.com
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
RE: ssl direct
Posted by Zhu Ming <mi...@bequbed.com>.
Hi,
I succeeded to use ssl with tomcat 4.0-m5 on Windows 98.
What you need to do is just to follow the instruction
in the comment of "conf/server.xml" file.
I think that on linux, the thing is same.
Ming
-----Original Message-----
From: Lorenzo Pastore [mailto:lorenzo.pastore@lince.it]
Sent: Monday, January 08, 2001 17:30
To: human-response@apache.org
Cc: tomcat-dev@jakarta.apache.org
Subject: ssl direct
Good morning
i'm trying to use ssl direct with tomcat on linux machine, following the
detailed how-to lists i don't succeded to conclude the certification. If
i not varing the provider2 voice i conclude the certification but when i
open the hppts page on 8443 port on my tomcat machine retur error
"unrecognized ssl handshake"
Can you help me PLEASE
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org