HJ incorporates Java and HTML operators into a single formal grammar. We may consider the language as consisting of three parts – subset of Java, subset of HTML and all the rest. The latter serves for code factorization and reuse as well as for ‘gluing’ Java and HTML. Widgets are the units of code reuse. The HJ code of an application is provided as a set of .page files (one per Web page) and a set of .widget files. A widget may define named attributes and/or named slots (or one anonymous slot). A slot is somewhat similar to the position between opening and closing a ‘library tag’. The code in HJ slots has Java context of the point of call of the widget, so widgets are transparent for Java context (same as HTML elements are by the way). The rest of the .widget file is just ARBITRARY HJ code – no other programming support or configuration is necessary to define a widget. Technology suggests a very natural framework that includes application, page and widget data persistent in the scope of HTTP session. Developer defines such data as members of ‘code-behind’ classes, which may contain handlers of those states called by the framework with a proper dispatching in case of widgets. Compiler resolves the identifiers used in widgets and pages against Java definitions in Java blocks, definitions of widget attributes, in instances of widgets and page state classes. Widgets may send signals to parent and page. FREE FOR NON-COMMERCIAL USE Home: http://www.hybridserverpages.com/ Detailed Language Definition (informal): http://www.hybridserverpages.com/HybridJava.doc Running Sample Application: http://hybridjava.com:8080/HJ_Sample Download: http://www.HybridServerPages.com/HybridJava_v0.94.zip The aim was to develop something more-more convenient than ... you name it. Please tell what you think, report bugs and advice missing features. It is just a beta. No question - ASK QUESTIONS!

I've read the (short) documentation, but I still fail to see how this framework could be better than, say, Wicket, with regards to ease of use, HTML/Java separation, or reusability/componentization. Not to mention that it's not even free/opensource. Did I miss some kind of secret feature that would make me think otherwise ?

Hi Olivier! Thank you for reading "short documentation". That is ALL the documentation HybridJava has and needs, so thank you for this compliment. I agree that you missed something. You suggest that the problem is in "HTML/Java separation" while we think that JSP was invented for combining HTML and Java in one source. Next you missed that the problem is in generation of dynamic content. Which is not only about filling well known positions in a form with varying data but also about varying structure of page. HybridJava cares about IDs of components even under loops and recursions. What I saw so far in Wicket is all around manual assigning IDs. Did I miss something?

Yes. But you would have to be looking to find it.

Hi! Suggesting that the problem to be solved is in "HTML/Java separation" is a fundamental (though common) misunderstanding. The promise of initial JSP was about interlaying (which means combining, not separating) HTML markup and Java within the presentation layer code. Respecting the boundary between the Presentation Layer and the Business Layer is a must, but note that the former has logic of its own too. The JSP way of doing things is in using Java to code presentation logic. To understand Wicket, I got the book “Pro Wicket” by Karthik Gurumurthy. What does this specific technology provide to express the component structure of the application? The book tells “You can liken Wicket development to Swing development” and also “the component hierarchy is specified explicitly through Java code” (p 9). In other words it is done the way it was some 15 years ago with Visual Basic and all the rest desktop UI development tools. There is nothing bad in such an approach, but alas, that is a pre-HTML presentation technology. Technically it is about manually coding endless “new” and “add” operations. Reading further one finds out that the “component hierarchy” (structure) is simultaneously depicted in a form of markup. This duplication of information is a step back even compared to the Visual Basic. See Listings 4.19 to 4.22 pages 129-130 – MyBorder is the most compact example I found. If you code the same example in HybridJava all will look indeed very similar … except that there will be NO listings 4.20 and 4.22 at all. Actually HybridJava has a similar example running over here: http://HybridJava.com:8080/HJ_Sample/?HJ_page=com.HybridJava.Sample.NiceFrame By the way, what is the need for MyBorder to be a component if it does have neither state nor beheavior? A simple answer is that the Wicket framework has nothing of lighter weight than a component. HybridJava has. HybridJava approach is that presentation components (in that they have place in the hierarchy) are nothing different from HTML elements and thus markup is sufficient. A clever enough framework may (and HybridJava does) figure out all the rest behind the scenes. In particular HybridJava framework performs all necessary “new” and “add” operations and assigns dynamic IDs. More on IDs: page 216 states “This feature demonstrates Wicket’s excellent support for dynamic templates.” Actually, they probably meant to say that Tabbed Panel example (NOT a feature!) demonstrates something. What it demonstrates in reality is that the Wicket framework has completely failed to solve the dynamic IDs puzzle. This specific example works, but only because in the book’s own words “At any given point in time, only one Panel can be active or visible”. HybridJava has solved the dynamic IDs puzzle. Another thing that the book shadows is the Wicket solution for loops. In the Wicket framework even a plain loop is a component, so the “Wicket way” of coding repetitions in presentation layer is (in ADDITION to markup!) something like: Loop loop = new Loop( new LoopItem( … // Lisp is immortal !!! HybridJava is not that “revolutionary” and sticks to using traditional Java “while” keyword. So what is the bottom line? Compare two things: 1) A compiler from some programming language 2) A printed instruction on how to manually “compile” from a similar language. That is exactly how HybridJava compares to Wicket. PS. HybridJava version 0.95 is available. Examples from the “Pro Wicket” Book: // 4.19 // 4.20 package com.apress.wicketbook.layout; import wicket.markup.html.border.Border; public class MyBorder extends Border { public MyBorder(String id) { super(id); } } // 4.21 Label content goes here Back to Index // 4.22 package com.apress.wicketbook.layout; import wicket.markup.html.WebPage; import wicket.markup.html.basic.Label; import wicket.markup.html.border.Border; import wicket.model.Model; public class MyPage extends WebPage { public MyPage() { Border border = new MyBorder("myborder"); add(border); border.add(new Label("label", new Model(" Wicket Rocks 8-) "))); } }

I apologize for late reply. Sorry did not see your notice before. Same is not true regarding "One of it major aims" of Wicket. That is a too known concern to be overlooked. And unfortunately that is a widely misinterpreted concern. The right formula is a clear separation of presentation layer from all the rest. And as long as we seek to have a dynamic presentation layer the latter is doomed to have at least some logic of its own. All who tell you otherwise are kidding you. You understand that nothing essential changes if you use <if syntax instead of plain if. Adding conditional generation into markup language IS adding logic. (Side note - I wonder if cpp was ever used for conditional generation of HTML).

I would not agree that the discussed is the major aim for anybody, but HybridJava address this concern better. The question is how and at what cost. In HybridJava there are no predefined widgets, but you can easily define what you like at no cost. In the Sample Application with the current (1.01) version you can find examples of that. In the Wicket the cost is redundant java programming and redundant instances as each loop is a component there (ha ha ha).

1. To see how this framework could be better please try to program any of examples from our sample application (http://www/hybridjava.com:8080/Sample) using Wicket. I doubt that is  possible at all. If possible then how much effort will that take and how slow will that work?

2. Verson 1.02 is currently (for promotional period) available for free.

3. The source code run-time of version 1.02 is provided as open source.

He he. You said HJ

He he. You said HJ

Well, doesn't this technology relieves us from the Hand Job of crafting our JSP pages manually? *lol*

When I submitted the article I defined HJ as HybridJava in the summary. I did not see that summary any more. Sorry for inconvenience.

i used hybrid server pages with the jt framework great succes!

http://www.HybridServerPages.com/HybridJava_v0.96.zip

http://www.hybridserverpages.com/HybridJava_v0.97.zip

This version supports multilingual web development http://www.hybridserverpages.comHybridJava_v0.98.zip

1. The MVC paradigm Web application components are reusable presentation layer modules that follow the MVC paradigm. So, each component may have its own View, Controller, and may be connected to a relevant part of the Model. 2. The One Touch principle Using a component to build a page or another component must be as simple as using an HTML tag, and must not require any programming or configuration. 3. Independence A page (or a containing component) doesn’t need to know anything about the contained component, and vice versa. 4. Session Scope Persistence The framework has to keep the state of each component until the session expires. This behavior should not depend on the current page shown or on component’s actual visibility on its page. 5. In-page Reusability A component may be used in a page (or containing component) more than once. For each use the framework must support an independent state. 6. Inter-page Sharing A component may be declared as shared between several pages. Then, only one instance should be created by the framework for all the Views of that component. 7. Dispatching of Information Framework should pass information about user actions (in particular about submit) to appropriate component instances. This should not require any additional programming, configuration or assigning of IDs to the components. 8. Inter-Component Communication At the View phase a component/page should be able to pass information to contained components via widget parameters. At the Controller phase the framework API should support communication between a component and containing component/page. QUESTION to the READERS: What is a meaning of the word "component" as it used in the context of JSF, Wicket, Struts and other frameworks. In which of those frameworks the component model is in fact a model of MVC components?

Now all the run-time code available as Open Source.

With embedded comonent-oriented support for Ajax. And more.