RE: An alternative to JSP
hi all, Among the alternatives we've kicked around: comp.lang.java.html+template comp.lang.java.template+tag comp.lang.java.servlet+template comp.lang.java.template-tech comp.lang.java.web-tech Again, any suggestions welcome either here or in private e-mail. how about comp.lang.java.web-apps comp.lang.java.web-applications comp.lang.java.tagged comp.lang.java.tag-html comp.lang.java.tagged-text comp.lang.java.embedded comp.lang.java.embedded-programming comp.lang.java.dynamic-html comp.lang.java.in-ascii-formats no real blockbusters... maybe someone else gets inspired. :-) robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
Glenn, Speaking of which: Yes, we need a place where the various templating and tagging approaches that somehow involve Java can be discussed. A thread like this thread needs a logical place for it to take place and right now there doesn't seem to be one as each list or Usenet group seems too specific to particular approaches.. Well, it just so happens that over in comp.lang.java.programmer we've just had a couple of long discussions about the need to add some new Usenet comp.lang.java.* groups. If anyone here has a good idea for a group name or two that would relate Java to the various template and tag languages for developing HTML pages that have active content I'd like to hear about them. Our discussion has moved to private e-mail involving sime regular heavy posters on comp.lang.java.* groups and we are hashing out exactly what is going to be voted on. I'd like a place that is a logical place for the users of various competing technologies in this area (JSP, WebMacro, Velocity/Turbine, Cocoon, FreeMarker, etc) to talk about the sorts of things this thread just discussed. We are working on some formal proposal write-usp for some new Usenet groups. But one of the proposed group names is comp.lang.java.servlet+jsp and that just seems too narrow and with the wrong emphasis. Among the alternatives we've kicked around: comp.lang.java.html+template comp.lang.java.template+tag comp.lang.java.servlet+template comp.lang.java.template-tech comp.lang.java.web-tech Again, any suggestions welcome either here or in private e-mail. On Fri, 26 Jan 2001 11:44:17 -0600, Glenn Nielsen wrote: This list is for discussing issues related to developing the Tomcat servlet container, not design of web applications. Could this discussion get moved elsewhere? Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
String/StringBuffer (was Re: An alternative to JSP)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
From: Paul Speed [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: An alternative to JSP
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
Mel Martinez wrote:
Without getting into the larger issue, one problem
that jumped out at me from your article is (at least
in your examples) the MLS precompile looks at the
expression inside the digraphs and replaces line
terminations in the *.j source with linefeed
characters ('\n'). That presumes the line termination
character of choice for the output is a linefeed
character. It may be a '\n' is fine for most cases,
but the truth is that it depends on the platform upon
which the output is to be used. In generall, it is
always best to use the line.separator property instead
or use a PrintWriter's println() method to insert the
correct line termination.
Another issue is that the example creates catenated
String literals. I would hope that the actual code
produced would use appropriately initialized
StringBuffers or performance could be a problem.
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer ("My").append("dog").append("has").append("fleas").toString();
It is also possible to write a statement like:
"My" + "dog" + '.'
The ability to concatenate a char points at an underlying StringBuffer
implementation, which supports append(String) and append(char) methods.
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string concatentation operator
( + ), and for conversion of other objects to strings. String concatenation is
implemented through the StringBuffer class and its append method. String
conversions are implemented through the method toString, defined by Object and
inherited by all classes in Java. For additional information on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java Language Specification.
Arieh
of literals it can be more efficient than StringBuffer as long as
they are grouped together as above. Since I haven't looked at the
code directly, I don't know how or if this affects your point.
-Paul Speed
Just some thoughts on the implementation. On the
larger issue of this thread, I don't really see the
benefit of something like MLS over JSP, which
potentially allows you to completely remove all Java
code from the html (by using jsp tags and taglibs),
but take that as an imho.
Dr. Mel Martinez
Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- Brad Cox [EMAIL PROTECTED] wrote:
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 {{...}} wrappe
RE: String/StringBuffer (was Re: An alternative to JSP)
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer
("My").append("dog").append("has").append("fleas").toString();
It is also possible to write a statement like:
"My" + "dog" + '.'
The ability to concatenate a char points at an underlying StringBuffer
implementation, which supports append(String) and
append(char) methods.
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string
concatentation operator
( + ), and for conversion of other objects to strings. String
concatenation is
implemented through the StringBuffer class and its append
method. String
conversions are implemented through the method toString,
defined by Object and
inherited by all classes in Java. For additional information
on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java
Language Specification.
On a performance note, doesn't it strike anybody the methods
on StringBuffer are declared 'synchronized' is a bad thing?
Object creation and synchronization are 2 of the most costly operations in
Java.
- Chris.
Brainbench MVP Java2.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
At 11:03 AM -0800 01/25/2001, Mel Martinez wrote: That presumes the line termination character of choice for the output is a linefeed character. Good point. Will fix when I get a moment. Another issue is that the example creates catenated String literals. I would hope that the actual code produced would use appropriately initialized StringBuffers or performance could be a problem. I've been assuming that concatenation of constants is collapsed at compile time. I'm sure this is true for SOME compilers but less sure this is true across the board. Could you elaborate on this point? Concatenation of non-constants is, of course, a different matter. I do use StringBuffers for these. Just some thoughts on the implementation. On the larger issue of this thread, I don't really see the benefit of something like MLS over JSP, which potentially allows you to completely remove all Java code from the html (by using jsp tags and taglibs), but take that as an imho. I don't view "eliminating java" as automatically beneficial. My goal is more to "eliminate html"; e.g. hiding it from view within classes in a format (MLS) that can be manipulated even by nonprogrammers, without "..."+ noise in the way. In other words, I view html as a problem to be hidden away and forgotten whereas JSP uses it as the foundation of the very programming language which keeps it right in my face. Some specific gripes with html: page references (a href, form) are hard-coded into each page. There is no way to check referential integrity except by testing each and every link. More seriously, every link bypasses all url session-encoding logic, so the user's session will be lost if they ever browse to a hard-coded html page. This has really poisonous user interface implications obviously. Finally, request.getParameter() returns Strings and/or nulls instead of providing a consistent validation architecture as described in the paper. Of course such an architecture could be easily added to JSP as user-level code (I offered to do as much for Tomcat but never heard back). The complaint is that JSP leaves this up to each user by implying that fields should be managed as Strings instead of taking active steps to help users realize that Strings (and nulls) should NEVER appear in higher-levels of an application, which is the very level that JSP addresses. For those who missed it, the article we're discussing is at http://virtualschool.edu/wap -- --- Dr. Brad Cox; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
At 11:23 AM -0500 01/26/2001, Brad Cox wrote: so the user's session will be lost if they ever browse to a hard-coded html pag I meant to say... for browsers that don't support cookies or if the user has disabled cookies. -- --- Dr. Brad Cox; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: String/StringBuffer (was Re: An alternative to JSP)
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string
concatentation operator
( + ), and for conversion of other objects to strings. String
concatenation is
implemented through the StringBuffer class and its append
method. String
conversions are implemented through the method toString,
defined by Object and
inherited by all classes in Java. For additional information
on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java
Language Specification.
And the Java Language Specification (Section 3.10.5: String Literals) says
this:
"Strings computed by constant expressions (15.27) are computed at compile
time and then treated as if they were literals"
http://java.sun.com/docs/books/jls/html/3.doc.html#101083
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer
("My").append("dog").append("has").append("fleas").toString();
If this is actually the case, Sun's JDK is not in compliance with the spec.
However, in my tests, this is not the case.
From this class:
public class StringTest {
static String blah = "My " + "dog " + "has " + "fleas.";
}
The following is the result from "javap -c StringTest" after compiling:
Compiled from StringTest.java
public class StringTest extends java.lang.Object {
static java.lang.String blah;
static {};
public StringTest();
}
Method static {}
0 ldc #1 String "My dog has fleas."
2 putstatic #5 Field java.lang.String blah
5 return
Method StringTest()
0 aload_0
1 invokespecial #4 Method java.lang.Object()
4 return
regards,
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
This list is for discussing issues related to developing the Tomcat servlet container, not design of web applications. Could this discussion get moved elsewhere? Thanks, Glenn Brad Cox wrote: At 11:23 AM -0500 01/26/2001, Brad Cox wrote: so the user's session will be lost if they ever browse to a hard-coded html pag I meant to say... for browsers that don't support cookies or if the user has disabled cookies. -- --- Dr. Brad Cox; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: String/StringBuffer (was Re: An alternative to JSP)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: String/StringBuffer (was Re: An alternative to JSP)
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
X-MIME-Autoconverted: from quoted-printable to 8bit by amon.Central.Sun.COM id
KAA15483
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string
concatentation operator
( + ), and for conversion of other objects to strings. String
concatenation is
implemented through the StringBuffer class and its append
method. String
conversions are implemented through the method toString,
defined by Object and
inherited by all classes in Java. For additional information
on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java
Language Specification.
And the Java Language Specification (Section 3.10.5: String Literals) says
this:
"Strings computed by constant expressions (15.27) are computed at compile
time and then treated as if they were literals"
http://java.sun.com/docs/books/jls/html/3.doc.html#101083
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer
("My").append("dog").append("has").append("fleas").toString();
If this is actually the case, Sun's JDK is not in compliance with the spec.
However, in my tests, this is not the case.
From this class:
public class StringTest {
static String blah = "My " + "dog " + "has " + "fleas.";
}
The following is the result from "javap -c StringTest" after compiling:
Compiled from StringTest.java
public class StringTest extends java.lang.Object {
static java.lang.String blah;
static {};
public StringTest();
}
Method static {}
0 ldc #1 String "My dog has fleas."
2 putstatic #5 Field java.lang.String blah
5 return
Method StringTest()
0 aload_0
1 invokespecial #4 Method java.lang.Object()
4 return
Michael,
thanks. I stand corrected.
Arieh
regards,
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Arieh Markel Sun Microsystems Inc.
Network Storage500 Eldorado Blvd. MS UBRM11-194
e-mail: [EMAIL PROTECTED] Broomfield, CO 80021
Let's go Panthers Phone: (303) 272-8547 x78547
(e-mail me with subject SEND PUBLIC KEY to get public key)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
Brad Cox [mailto:[EMAIL PROTECTED]] wrote:
At 11:03 AM -0800 01/25/2001, Mel Martinez wrote:
That presumes the line termination
character of choice for the output is a linefeed
character.
Good point. Will fix when I get a moment.
Another issue is that the example creates catenated
String literals. I would hope that the actual code
produced would use appropriately initialized
StringBuffers or performance could be a problem.
I've been assuming that concatenation of constants is collapsed
at compile time. I'm sure this is true for SOME compilers but
less sure this is true across the board. Could you elaborate
on this point?
Concatenation of non-constants is, of course, a different
matter. I do use StringBuffers for these.
Dangerous to put too much faith in compilers, eh? :-)
In general, for any code that is catenating strings, als
msg = "some string" + param + "some other string";
it is usually faster to use a StringBuffer like so:
msg = new StringBuffer();
msg.append("some string").append(param).append("some other string");
However, that in itself does not necessarily improve performance. The
StringBuffer class defaults to a size of only 16 chars. Thus, as soon as
the catenation result exceeds 16 chars, it has to reallocate the internal
buffer. If you then exceed the new size (it will double in size or go to
just large enough to hold the new data, whichever is larger) on a subsequent
append, it will have to reallocate again, and again. Adding 10 chars at a
time to a StringBuffer will cause 3 reallocations by the time
you get to a hundred characters. Actual performance impact will depend on
your particular application and the nature of the data.
So basically operations that add lots of small chunks adding up to a much
larger whole, will force numerous reallocations up until you've catenated
just over half the data at which point it will finally bump up to enough
room for the entire result.
Given this tidbit of knowledge, you should try to anticipate how large the
final StringBuffer needs to be to hold the entire result. You don't have to
hit it exact, and if you make it too large, you may run up against memory
constraints (depends on your application and runtime).
My suggestion is to try to guess the halfway mark. That way, you won't be
wasting too much memory, but will significantly reduce the number of buffer
reallocations (which cost a call the System.arraycopy() each time!).
So in the above example, suppose I can anticipate that the non-constant
Strings are going to be on the order of ~25 chars and that the constant
strings add up to about 75 so that my final String will be around ~100
chars. If I initialize the StringBuffer to about 64 chars, I can be sure
that it won't resize more than once. If memory is not a problem, then I
might go for the fastest situation and just do something like
msg = new StringBuffer(128);
so that I can be fairly sure I won't be reallocating.
I hope that this is helpful. Actual mileage may vary.
I'll defer for now on the relative merits of JSP versus other schemes. I've
got too many other things to worry about.
Cheers,
Dr. Mel Martinezmailto:[EMAIL PROTECTED]
Software Architect phone:410-423-3931
G1440, Inc. http://www.g1440.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
Mel Martinez wrote:
Without getting into the larger issue, one problem
that jumped out at me from your article is (at least
in your examples) the MLS precompile looks at the
expression inside the digraphs and replaces line
terminations in the *.j source with linefeed
characters ('\n'). That presumes the line termination
character of choice for the output is a linefeed
character. It may be a '\n' is fine for most cases,
but the truth is that it depends on the platform upon
which the output is to be used. In generall, it is
always best to use the line.separator property instead
or use a PrintWriter's println() method to insert the
correct line termination.
Another issue is that the example creates catenated
String literals. I would hope that the actual code
produced would use appropriately initialized
StringBuffers or performance could be a problem.
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
of literals it can be more efficient than StringBuffer as long as
they are grouped together as above. Since I haven't looked at the
code directly, I don't know how or if this affects your point.
-Paul Speed
Just some thoughts on the implementation. On the
larger issue of this thread, I don't really see the
benefit of something like MLS over JSP, which
potentially allows you to completely remove all Java
code from the html (by using jsp tags and taglibs),
but take that as an imho.
Dr. Mel Martinez
Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- Brad Cox [EMAIL PROTECTED] wrote:
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.
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/25/01 11:42 AM, "Paul Speed" [EMAIL PROTECTED] wrote:
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
of literals it can be more efficient than StringBuffer as long as
they are grouped together as above. Since I haven't looked at the
code directly, I don't know how or if this affects your point.
-Paul Speed
True, but not in a loop.
ie:
String foo = "";
for ( int i = 0; i NUMBER; i++ )
{
foo = foo + i;
}
That will produce a big mess. Best to use a StringBuffer.append in that
case.
-jon
--
Honk if you love peace and quiet.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP (REVISED)
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" [EMAIL PROTECTED] 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; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
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:[EMAIL PROTECTED]] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/14/01 3:11 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: "Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/14/01 3:11 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: "Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/14/01 5:34 PM, "Geoff Soutter" [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
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:[EMAIL PROTECTED]] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/12/01 11:49 AM, "Tomas Rokicki" [EMAIL PROTECTED] wrote: With the solution we're deploying in-house here, your dynamic row example is just tabletrtd%tr rundata%%key%/tdtd = %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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
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:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 11:54 AM To: [EMAIL PROTECTED] Subject: Re: An alternative to JSP on 1/12/01 11:49 AM, "Tomas Rokicki" [EMAIL PROTECTED] wrote: With the solution we're deploying in-house here, your dynamic row example is just tabletrtd%tr rundata%%key%/tdtd = %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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
I have used Excelon Stylus for creating xsl. Although you do a lot of stuff by hand, I found it to be useful for wysiwyg development. I only used it for a short time, so caveat emptor. Too bad it isn't integrated with Dreamweaver. Also too bad that you have to download their portal server to get the eval. $199 per license (blech)... luckily, we're all rich, right? Jef -Original Message- From: Kyle F. Downey [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 11, 2001 1:35 PM To: Paul Libbrecht Cc: [EMAIL PROTECTED] Subject: Re: An alternative to JSP On Thursday, January 11, 2001, at 06:38 PM, Kyle F. Downey wrote: 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 How did you solve this trouble then ?? We haven't. We're still writing XSL by hand, along with almost everyone else. Unless such a designer tool is EXTREMELY INTELLIGENT, meaning it makes some reasoning about the way xml elements are placed on an HTML page, or, of course, if your xml content is reasonably static (say two dimensional like an SQL database result-set) then you have the chance to see such a tool, otherwise, I don't view this as a possible thing... I think the solution will look a lot like Allaire Cold Fusion Studio when it comes: a mixture of a solid design tool with a "developer" copy of a rendering engine (Cold Fusion in Allaire's case; an XML app server in this case). That way the designer can get immediate feedback on what the data + view looks like. I agree with you that this is much thornier than simple HTML design, but I think it can be done. --kd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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" [EMAIL PROTECTED] 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; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- --- Dr. Brad Cox; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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; [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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; [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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" [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- --- Dr. Brad Cox; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/11/01 12:12 PM, "Brad Cox" [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
Geoff Soutter wrote: "Paul Speed" [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/11/01 4:53 PM, "Jon Stevens" [EMAIL PROTECTED] 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) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
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:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 6:32 PM, "Geoff Soutter" [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
An alternative to JSP
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; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/10/01 7:52 PM, "Brad Cox" [EMAIL PROTECTED] 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; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
