Finally something to replace JSP?

[p2006]

I had a dream since 1999 - a JSP page with Java and HTML, but without ... JSP. Did someone try "Hybrid Server Pages"? It is on downloads.com now. The modest thing has only four pages of description, so I'll paste it here (cut a bit) FYA.

My point is - does it really work?

Hybrid Server Pages

This proposal is a follow up to authors’ experience with JSP. We felt a clear need for a better than JSP language for dynamic web pages programming. Our aims were to:

 get rid of redundant syntax;
 provide more rigid syntax check;
 hinder generation of wrong-HTML pages;
 support code reuse;
 keep everything simple.

The language was finally named “Hybrid Java” where “Hybrid” stands for “Hybrid with HTML”. The HJ grammar was received by a merge of slightly modified formal grammars of Java and HTML.

Compilation Units and files

HJ reads files “*.hsp” (Hybrid Server Page) and files “*.hsw” (Hybrid Server Widget) defining reusable HJ code fragments.

Using XML syntax

In general HJ code is presented as an XML document containing both Java code and HTML document content. It may use all possible tags - those that correspond to HTML tags present HTML elements. Other tags (except for few reserved) present widget calls and their slots calls. Each opening tag must be closed by an appropriate closing tag (<p> … </p>). Single tag HTML elements must be presented in XML style too (<br/>);

Hybrid code

Reserved word “Hybrid” met in the attribute list of an element means that the text between tags is Hybrid code (Java code mixed with more elements). Otherwise the text is interpreted as page content. The following HTML elements my not have content inside and thus are “Hybrid” by default: COLGROUP, DIR, DL, FRAMESET, MAP, MENU, OL, OPTGROUP, SELECT, TABLE, TBODY, TFOOT, THEAD, TR, UL.

Variables

Basically HJ variables are Java variables. In addition HJ variable may be defined as an attribute of a widget and may be used in following HJ contexts:

 in widget call in position of attribute value;
 in HTML element in opposition of attribute value;
 in HTML page content.

In the first two cases variables are presented by plain identifiers (same as in plain Java). In the third case variable X is presented as “$X” or “$X;” (“in-text identifier”). The nature of a variable does not depend on the way it was created or used.

Semantics of variable usage in various positions is the following:

 “Hybrid” (~Java) code – as in plain Java;
 widget attribute value – as initial value of the widget attribute;
 HTML element attribute value - the value becomes that of HTML attribute;
 in page content (“$X”) - value of variable printed within the HTML page text.

Comments

HJ code may contain Java line comments (starting with “//”), Java multi-line comments (/* */) and HTML comments (<!-- -- >). The fires two are retained in the retained in the generated Java code. The latter makes it to the generated HTML page.

Escape Symbol

HJ has one and only escape symbol - dollar (“$”). Here is a full list of escapes:

 “$<” is an escape sequence for start of a tag. Any “<” not preceded with “$” and followed by a letter is interpreted as a beginning of a tag.
 “$//” and “$/*” are escapes sequences for comment starts;
 “$$X” is an escape for “in-text identifier” (“$X”).

HTML attribute values

In HJ values of attributes of HTML elements may be strings in single quotes or in double quotes. Those string values may be generated dynamically using concatenation operator “+” that joins string values and Java variables current values into one quoted string.

int n = 101;
<P id=”pref_” + n >

This HJ code generates such a Java code that when it is executed it generates the following HTML:

<P id=”pref_101”>

Character entities

The following signs when met in the page content text are substituted to proper form by the implementation: < , > , “ and &.



Widgets

Widgets contain Hybrid code that may be reused in multiple pages. Widgets may have attributes and “slots”. A slot is a reserved position in the widget body code that may be filled with external HJ code. Widget definition looks like below:

<widget name=widget1 Hybrid>
<attr name=attr1 type=String default=”default”>
// More attribute definitions
// some HJ code – note Hybrid keyword above
<slot name=sn1>
<p> This is a “page content” which means
that one may see it in a browser </p>
</slot>
// some HJ code – note Hybrid keyword above
<slot name=sn2 Hybrid>
// some Default Hybrid code
</slot>
</widget>

Default value of an attribute is optional. The attribute type may be any Java type – literal or class (as String is). Default attribute type is “String”. Widget usage looks like below:

// some Hybrid code
int k = 77;
<widget1 attr1=”non-default”>
<sn1> // not Hybrid!
This is a Very Important Document! <br>
Read carefully!
</sn1>
</sn2 Hybrid>
// some Hybrid (Java) code
int m = 0;
k += 1; param1 = “\”non-default \”is bad as an example”;
</sn2>
</widget1>

Variable “k” is accessible from the insertion into slot “sn2”. Widget may have zero slots and/or zero attributes. You do not have to use every slot – default code located in the widget itself will be used. If a widget has only one slot it may be used as anonymous slot:

<widget name=widget2>
…
<slot/> // or <slot> some default </slot>
…
</widget2>
Usage:
… <widget2> … this is inserted into anonymous slot … </widget2> …

Implementation

A full-blown HJ implementation might provide full Java check and even produce byte-code (.class files). However it is sufficient (and that is about the current implementation) to stop at the point where the Java source code is generated, leaving most of the rest of the work to Java compiler. Thus the generated Java code may not compile depending on what y the user wrote in details.

For each “.hsp” file HJ compiler generates a “.java” class with the same name and the code “.hsp file” specifically translates into java code of method “void render()” in that class; when iniciated with “PrintOutput” and executed this method produces HTML page.

The code of widgets and the content of slots are compiled (maybe more than once) into the code of method “render” as well, wrapped into blocks. So that is an “open substitution” and that is what makes names from base class and the page itself seen everywhere.

HJ compiler has two command line options. Option –p defines the package of generated class. Option –b defines a common base class for the generated Java pages classes. Typically the base class may be some class derived from “Servlet”.

Conclusion

Authors strongly hope that Hybrid Java may be a good alternative to JSP. Please address you comments, requests and advice to HybridServerPages@yahoo.com.

[Waylander]

What a crock lol.

There is an alternative to JSP, the alternative is nothing. JSP is a useless layer of unrequired technology and servlet applications simply do not require it.

"hybrid server pages" must be a joke, yahoo email accounts and unstyled godaddy web sites....


didnt these terrible posts used to get deleted??

[p2006]

Hi Super-Brutal!

"There is an alternative to JSP, the alternative is nothing. JSP is a useless layer of unrequired technology and servlet applications simply do not require it."

I absolutly agree with you. JSP is aufull. And JSP is unnecessary. However there is a lot of engineers that still use JSP. Why? - Because it's better than nothing. With your nothing you apparently write something like out.print("<table>"), don't you? Why don't you try to program pages with Turing macine?

Jsp is unnecessary and, by the way, have you read carefully Hybrid Server Pages what it does - exactly it eliminates JSP suggeting a more direct way to use HTML and Java together.

By doing so it also eliminates ANY need for PHP, JSF and all other things like that, including all "temlpate engines". Because with HTML, widget presented as XML and Java all in one file we may the best way present our knowledge of future page. With less typing to start with.

It is not a joke but for real because it also more or less works. I tried it and you probably did not even care to look into *.hsp samles, which are great.

P

[Waylander]

If you agree with me why are you trying to re-write jsp?

If I dont like jsp why would I want to use something that directly replaces it?? Something that is two thirds the way to being exactly the same as it.

With my nothing I write something like out.print(<valid xhtml strict>), what is a more direct method than directly outputing html from java??

Also why would I want to use something that "more or less works" on the valuable systems I work on??

No I didnt look into the samples, the poorly worded descriptions were enough to put me off downloading anything from that domain.

Waylander.

[p2006]

Hi!

What I said is exactly: "I absolutely agree with you. JSP is awful. And JSP is unnecessary." You suggest that I am trying to rewrite JSP. First - that is not me. Second - that is not about "rewriting JSP" which literary means: write another JSP with the same functionality?

Look at the problem from another point of view. The general idea of JSP was not bad. Really it was good. The idea was to have both control over page dynamic content and over presentation details packed into one file, so that you have a privilege of using plain Java in one line and plain HTML in another. The implementation of this good idea was awful. Those who invented JSP probably did not understand the whole might of modern computers when ... when those computers are lucky to meet with strong mathematics - in particular with the theory of programming languages.

You write "out.print(<valid xhtml strict>)" in your Servlet and do not use JSP - and you are right. Simply because the syntax overhead in writing this way is approximately same as with endless %>-s and <%-s.
I worked myself with JSP since 1998 till 2004 in two companies on three Huge projects and delivered quite a flooding of JSP pages. I hate JSP. Finally I was advocating going to Servlets in front of my bosses. No way though.

Besides all JSP is not a language at all. It will "compile" whatever you write in "Java" part and whatever you write in "HTML" part. It gives very very limited control over syntax. Finally you get Java error massages bound to quite a different file. And what about the HTML correctness? For specific HTML files generated you may use validator. But what about proving the HTML correctness for the whole set of pages potentially generated by this single dynamic page? All the information necessary is there, but never used.

Rolling back to Servlets is not an answer to this challenge. If you write out.print(<p>); out.print(</table>) - who will catch your hand? Servlet will compile.

The answer of Hybrid Server Pages is the ANSWER to the challenge, not running away from the challenge.

"Something that is two thirds the way to being exactly the same as it." - Replace means total replace. After all HSP has zero in common with JSP. I trust you - you did not read their doc.

"Also why would I want to use something that "more or less works" on the valuable systems I work on??" I do not now why, probably just because you do not value your valuable systems enough. At least think about those who will come after you to support your "print"-s. And there may be no damage to you systems - the thing is 100% open as it generates a very clear and transparent Java code.

"the poorly worded descriptions" - I understand you. When I happen to be in a bookstore I each time feel guilty for that many killed trees when I see shelves and shelves packed with PHP wisdom. Probably you were brought up on reading those 800 pages items. Probably you start to understand something not before you get to the page N 699. My congratulations. My generation was brought up on reading formal definitions of languages. HSPs guys gave a poorly worded description? That is a language of math. I think that they tried to underscore the contrast with PHP shelves. Indeed, they have managed to explain everything on five pages. That is a phenomenal result, by the way. No question not everybody is able to read that FEW.

So: HSP solves the problem that JSP promised to solve but did not.

With my sincere respect,
p

[Waylander]

This is ridiculus over two thirds of what you have written there has no correlation to what I said at all. None what so ever.

"Look at the problem from another point of view."
- Few can. Just like myself they all have specific requirements that they must work to.

"what about proving the HTML correctness"
- html is a scripting language, it does not compile and therefore it does not matter where you put your script validity will always be a problem and should be solved by writing good script, again regardless of where or at what layer the script is located.

'HSP has zero in common with JSP"
- After everything that you have posted so far this doesnt seem like a very smart thing to say to me. Im sure any search engine crawler would correlate your "HSP" with "JSP as you mention it every single time, and its un-acronymed name is two thirds the same.

"you do not value your valuable systems enough"
- I will be the Judge of that. I would rather use JSP than HSP simply because the user base and the support base is ridiculously larger. I value my systems enough not to use a green, un-tried technology.

"those who will come after you to support your "print"-s"
- Modularity and Encapsulation can be written into any system, you dont need to implement a technology or layer every time you want maintainable code.

"I understand you"
- No. No you dont. I was not refering to documentation, trees, php, or anything of the sort. My comments were based on "internet common sense" which has a general inderlying rule of "dont download stuff that looks like a scam or is dodgy enough to inadvertantly break my stuff"

Waylander.