The new version of the JBlooming java web development framework, 3.4, is on line at www.jblooming.org. This is the first stable version. Complete downloads from Sourceforge are available under LGPL.

In particular, this version is fully documented with an extended tutorial and on line samples.

JBlooming is a set of tools for increasing the power of jsp based presentations. The primary aim of this framework is increasing productivity. It also happens that by using JBlooming you get beautiful, simple pages, but that is a side effect.

We want to use as much as possible java apis and OO modelling for designing interfaces, so we didn't use tags, but introduced an object oriented technique for using jsp templates.

This framework can be seen as a partial answer to the concerns expressed by Tate in "Beyond Java" (Bruce A. Tate, Beyond Java, O'Reilly, 2005).

Its basic nice features are:

• flexibility and power: the framework lets you preserve your java/jsp/html/js (AJAX included) skills, and use them in every circumstance
• a set of mature and beautiful html components and built in skins
• simplicity; and simple means scalable. Programmers energy is limited, hence must be spent focusing on the users requirements.
• self validating
• easy to skin
• xml free; all configuration in few strongly typed jsps
• low application server requirements for deployment (in fact, it can be deployed almost anywhere)
• free and open source (actually more, LGPL)

Positive feedback will be appreciated :-D.

Would you stop it with all of these damn frameworks!?!?

Sorry, I just had to vent.

jsps containing html interspersed with java code? no thanks.

I couldn't agree more. Haven't we visited this place before?

All the relevant problems are solved. That's why this site consists of nothing but announcements for yet-another-framework (like this), and commercial experiments.

Don't bring up AJAX - that ain't got nuthin to do with Java or the Server side necessarily. And this really shouldn't be the forum (try TheBrowserSide.COM).

Thuh, thuh, thuh, that's all folks!

http://www.jblooming.org/applications/blooming/samples/showHTMLSource.jsp?_VP_V_ID=11265097&_VP_POP=yes&PAGE_TO_SHOW=sampleBox%2ejsp

ouch, this stuff looks horrible

Looking at the code example and it's complexity and just plain ugliness doesn't surprise me. These days when I have to work with some junk like that I don't blame the sales guys. I blame myself for not having the sales and marketing skills to sell decent software solutions. Someone is buying that ..stuff .. I applaud the sales team.

http://www.jblooming.org/applications/blooming/samples/showHTMLSource.jsp?_VP_V_ID=11265097&_VP_POP=yes&PAGE_TO_SHOW=sampleBox%2ejspouch, this stuff looks horrible

Umm... the code is not especially beautiful, I would prefer less scriptlets for rendering phase. Anyway, this particular example does not mean that JSP and JSP scriptlets should always produce ugly pages. What do you think about this one?

"for example, configuration is shown in examples as a set of inner classes whose source is embedded in JSPs."
                --- Guess who?(This IDIOT is?)

What? Do you have your senses? Can you not make it more obscure? Why not make a faces context "for example" as a set of contexts whose INNER CLASSES' source is embeeded in JSP's without the JSP's having full knowledge, but the TAGS (based upon the simple tags) take care of this whole mess.. Hi.. hi.. hi...hi... (you wanted BUZZ, didn't you?)

Oh! me barely know?

Lovely, lovely Inner classes...That word is enough to put me off..

Learn to program in Java first! (May be a Java certified programmer could help you idiots). Then talk about frameworks.

Geee.... THUUUUUUU... spit..... Yaaaak.... Thuupchuk

The quoted text is from the server side editorial stuff, not from us.

I don't know this framework but source code example posted below is the perfect anti-pattern. It is not really a pattern but it is a perfect example of what I am asking developpers not to do : don't put java code in jsp!
It should be only presentation.

don't put java code in jsp!It should be only presentation.

Depends. In general, not true.

Why use XML and Tags when we can use excelent Java language ?

What is a framework ? For me, not something maybe elegant, but that forces you to write code in a certain way, declaring everything separately and first, or other punitive practices. For me a framework is a set of tools that work for me, not that get in my way. Moreover the usual frameworks are poor in components. A framework that doesn't have a powerful set of ready set components, encourages duplication of code. That a framework is "extensible" is not necessarily good: it should not need extensions, it should be easy to integrate; like we just did by integrating JBlooming with JBPM 3. It now requires to add one line to your JSP configuration. Oh so ugly!

There are other gems of our "ugly" framework: for example, a complete scheduling and agenda model. We had to rebuild it in the framework as Quartz, using cron expressions, has some modeling limitations, like non supporting any kind of schedules like "every 5 minutes", "Mon and Wed every 2 weeks".

For any technical questions on the framework, see you on http://www.twproject.org .

Ops... wrong link

For any technical questions on the framework, see you on http://www.twproject.org .

For any technical questions on the framework, see you on http://www.twproject.net.

I can do it....

For any technical questions on the framework, see you on http://www.twproject.net.

You see ? Using tags, no validation, no feedback, mistakes all the time. :-D

After viewing the example code, what I really want to know is : why do you feel that wiriting more code in JSPs is somehow an improvement ?

I'm completely confused.

yes.. you'd be much better served if you included that code in tags and have your users use the tags.. There's no sense in mixing Java w/JSP.. that is what most of us have been trying to move away from.

yes.. you'd be much better served if you included that code in tags and have your users use the tags.. There's no sense in mixing Java w/JSP.. that is what most of us have been trying to move away from.

I don't see how writing well-observable structured chunk of Java code in a JSP page is necessarily a bad thing. JSP are easy to develop and [re]deploy, and there is no need in special configuration options and config files, just change the code right in front of you.

Scriptlets go bad when they are mixed with HTML producing spaghetti code. Hey, the guy is Italian ;)

yes.. you'd be much better served if you included that code in tags and have your users use the tags.. There's no sense in mixing Java w/JSP.. that is what most of us have been trying to move away from.

I don't see how writing well-observable structured chunk of Java code in a JSP page is necessarily a bad thing. JSP are easy to develop and [re]deploy, and there is no need in special configuration options and config files, just change the code right in front of you.Scriptlets go bad when they are mixed with HTML producing spaghetti code.

I hope you're hironic. Look at what there's in some of the demos. For example: sampleSelector.jsp. The beginning of the code is:


  PageState pageState = PageState.getCurrentPageState(request);
  if(!pageState.screenRunning) {
    // if this is the first time the page is loaded
    // the screen is set up
    pageState.screenRunning = true;
    final ScreenArea body = new ScreenArea(request);
    BloomingSiteHBFScreen lw = new BloomingSiteHBFScreen(body);
    lw.register(pageState);
    pageState.perform(request, response).toHtml(pageContext);
  } else {


this means one has to deal by himself with the current aspects of the lifecycle of the page state objects. In my opinion this is what a "real" framework should do for a page designer. Instead it seems JBlooming asks the developer to directly do it by himself (probably because there is no mvc, and as such no "common" part that could be implemented by a centralized front controller. You may think that asking a developer to include such kind of information is not bad, but is exactly this kind of practice that will go bad in the short run. Trying to avoid xml or separate configuration does not mean you have to put your entire lifecycle in the hands of your programmers, and ask them to manage it in the header part of every jsp: look at what Wicket does, it is much better (and not less redeployable, provided you don't change the method structure of the page class you're changing).

Hey, the guy is Italian ;)

Hell, we can do much better than that (even with spaghetti).

yes.. you'd be much better served if you included that code in tags and have your users use the tags.. There's no sense in mixing Java w/JSP.. that is what most of us have been trying to move away from.

I don't see how writing well-observable structured chunk of Java code in a JSP page is necessarily a bad thing. JSP are easy to develop and [re]deploy, and there is no need in special configuration options and config files, just change the code right in front of you.

Scriptlets go bad when they are mixed with HTML producing spaghetti code.

I hope you're hironic. Look at what there's in some of the demos. For example: sampleSelector.jsp. The beginning of the code is:

  PageState pageState = PageState.getCurrentPageState(request);
  if(!pageState.screenRunning) {
    // if this is the first time the page is loaded
    // the screen is set up
    pageState.screenRunning = true;
    final ScreenArea body = new ScreenArea(request);
    BloomingSiteHBFScreen lw = new BloomingSiteHBFScreen(body);
    lw.register(pageState);
    pageState.perform(request, response).toHtml(pageContext);
  } else {


this means one has to deal by himself with the current aspects of the lifecycle of the page state objects. In my opinion this is what a "real" framework should do for a page designer.

In this case ASP.NET is not a real framework. It has the same notion of page load/unload events as well as postback event. Not exactly the same as shown in the snipped above but similar.

Instead it seems JBlooming asks the developer to directly do it by himself (probably because there is no mvc, and as such no "common" part that could be implemented by a centralized front controller.

ASP.NET 1.0 did not have centralized front controller, it implemented this pattern only in 2.0. Seems that this guy prefers page controller to front controller.

When I talked about spaghetti code I meant something like this:

...
<tr><td><%
  cf = new CheckField("CF_RADIO", "</td><td>", true);
  cf.label = "radio buttons";
  cf.toHtml(pageContext);
%></td></tr><tr><td><%
  cf = new CheckField("CF_CHECK", "</td><td>", true);
  cf.label = "check boxes";
  cf.toHtml(pageContext);
%></td></tr>
...

I am ok with scriptlets if they do not intersperse with HTML like this.

You may think that asking a developer to include such kind of information is not bad, but is exactly this kind of practice that will go bad in the short run. Trying to avoid xml or separate configuration does not mean you have to put your entire lifecycle in the hands of your programmers, and ask them to manage it in the header part of every jsp: look at what Wicket does, it is much better (and not less redeployable, provided you don't change the method structure of the page class you're changing).

Until a new web protocol released, we have to use HTTP. It is nearly impossible to build a robust web application with good usability without dealing with HTTP features. These are *web* applications we are talking about, I don't see a point of abstracting fully from the underlying protocol that affects applicaion's usability, searchability, presentation, navigation and other aspects.

ASP.NET 1.0 did not have centralized front controller, it implemented this pattern only in 2.0.

Well, I imagine that even the first java web application ever written didn't have one, but this is not necessarily a reason to value this model.

ASP.NET 1.0 did not have centralized front controller, it implemented this pattern only in 2.0.

Well, I imagine that even the first java web application ever written didn't have one, but this is not necessarily a reason to value this model.

This model works for ASP.NET crowd quite well. While accusing others in technological illiteracy, you at the same time consider the Front Controller a holy grail of web dev (isn't Struts a Front Controller-type framework, by the way?) Craig McLanahan explained one of the reasons to shift from Struts to JSF: for many people Front Controller model is hard to grasp, especially for those who have Visual Basic background. JSF and visual IDEs makes it easy: create a page, drop a control on it, wire an event handler. Microsoft was not being stupid when it made Page Controller a standard model in ASP.NET, because this model caters to former VB programmers quite well.

Microsoft is actually doing very smart. First they made the product that made it simple for VB guys to start web dev. Now with ASP.NET 2.0 they added features and support for Front Controller. So, they made starting with web dev easy, they kept their developers and now they attract more. Baby steps + dangling carrot => success among masses. Whereas de-facto standard Java framework Struts makes it hard to shift from desktop dev to web dev. Not only the concept is different, the implementation is not as clean and complete as it could (should?) be. Check out Struts mailing list, the same questions and issues for three of four years in the row. People chew on the same stuff instead of moving forward.

Pure JSP and JSF are on the different sides of spectrum considering such services as application lifecycle, I/O conversion, I/O data buffering, input validation, error handling, etc. Well, JSP does not have most of these features. But a bird's eye view on these technologies reveals that both of them are Page Controller models. JSF has more to offer, but requires larger investments, not only intellectual. JSP, on the other hand, allows to build application step by step without need to explicitly recompile/reconfig/redeploy an application. Frameworks like Struts downgraded JSP to dumb data-aware HTML. Well, JSP is capable of much more.

The bottom line: JSP is not dead, Front Controller is not *the* answer.

This model works for ASP.NET crowd quite well. While accusing others in technological illiteracy, you at the same time consider the Front Controller a holy grail of web dev

It's a pity you didn't read what I wrote, you could have learnt that I didn't speak about holy grails, remarking the following, instead:
"[Jblooming]deliberately ignored all the work done on mvc, custom tags, new jsp specifications, frameworks for component-oriented web development, improvements due to sensible defaults, ajax features, simplification", which is, in my view, pretty undiscussable (except if you are able to find custom tags, use of jsp 2.0 features, ajax features and so on in JBlooming...).

And I only mildly asked myself if the demo source, which I didn't like at all, could be made less ugly by factoring the boilerplate code in a centralized controller:
"could it be simplified if used with an mvc framework and some kind of common interceptor that performs the global actions needed to set up the page state?". In a previous answer, Pietro Polsinelli says that they use a common filter in order to set up the page state, so a certain amount of "central" set up is actually done.

Microsoft was not being stupid when it made Page Controller a standard model in ASP.NET, because this model caters to former VB programmers quite well.Microsoft is actually doing very smart.

Well, I thank you for your opinions, even if I don't see how they relate to the fact that I don't like a technology that asks me to put code like the one I pasted in the beginning of a jsp. ;)

[...........]Well, JSP is capable of much more.The bottom line: JSP is not dead, Front Controller is not *the* answer.

Holy god, all this because I asked if JBlooming could maybe "be simplified if used with an mvc framework and some kind of common interceptor that performs the global actions needed to set up the page state?"??? I find your considerations pretty much reasonable, anyway.

Again JSF is FRONT CONTROLLER ORIENTED. What is the FacesServlet then?

Some proofs :
http://www-128.ibm.com/developerworks/web/library/wa-dsgnpatjsf.html
Search google and you'll find a lot of other sites reitering this statement.

JSF offer a lot of Page Controller advantages but it still sticking to the front controller model.

I know you hate this framework and you rather stick with Struts but stop spreading FUD all-around.

Again JSF is FRONT CONTROLLER ORIENTED. What is the FacesServlet then?

Some proofs :http://www-128.ibm.com/developerworks/web/library/wa-dsgnpatjsf.htmlSearch google and you'll find a lot of other sites reitering this statement.

JSF offer a lot of Page Controller advantages but it still sticking to the front controller model.

http://websphere.sys-con.com/read/46516.htm
"JSF uses the Page Controller Pattern. Although there is a single servlet every faces request goes through, the job of the servlet is to receive a faces page with components. It will then fire off events for each component and render the components using a render toolkit. ... JSF ... adds many benefits of a front controller, but at the same time gives you the flexibility of the Page Controller."

On another hand, let's check ASP.NET page lifecycle:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/ImpPageController.asp
"Assume the user is interacting with a Web Forms page that contains one button server control. When the user clicks the button control, an event is transmitted as an HTTP post to the server, where the ASP.NET page framework interprets the posted information and associates the raised event with an appropriate event handler. The framework automatically calls the appropriate event handler for the button as part of the framework's normal processing." Therefore in ASP.NET request does not go directly to a user-defined page class, it is processed by a framework first. How this is different from processing a request by FacesServlet? Yet Microsoft openly calls ASP.NET model a Page Controller.

I don't want to downplay the value and complexity of JSF. Page Controller is what a regular JSF user sees on the surface, but it is indeed possible to use Front Controller features if one wants to dig deeper. You are right that JSF is a combination of Front Controller and Page Controller patterns, I stand corrected, thank you.

Argh, I must admit that from a cursory view this thing looks awful (from a programming standpoint). It seems that whoever built this deliberately ignored all the work done on mvc, custom tags, new jsp specifications, frameworks for component-oriented web development, improvements due to sensible defaults, ajax features, simplification, etc.etc.

It's a set of tools that blatantly ignores what Tapestry, Wicket, JSF or even Struts and WebWork did for years (what is surprising is that this framework is being proposed to theserverside, in my opinion).

It is much more disapponting as far as the company who built this is italian, and it seems to confirm our worrying cultural backwardness with regards to this kind of technological evolution: much of the consulting companies here still tout Struts as the best thing since sliced bread.

I wonder if maybe the ugly result is due to the demos being developed with the rough components without any other technology such as an mvc framework? Maybe the goal is showing the object model: could it be simplified if used with an mvc framework and some kind of common interceptor that performs the global actions needed to set up the page state?

What I think is important in this kind of efforts is the fact they focus mainly on the production of rich components with an appealing look and usability (although I find it's questionable, if JBlooming components are really appealing from both points of view). I think that the java development world should value more the final result of the work (i.e.: what is built, what it is needed for, how pleasing/easy/quick it is to use/learn/teach, ... that said, I really believe this thing is a failed effort.

What I think is important in this kind of efforts is the fact they focus mainly on the production of rich components with an appealing look and usability (although I find it's questionable, if JBlooming components are really appealing from both points of view). I think that the java development world should value more the final result of the work (i.e.: what is built, what it is needed for, how pleasing/easy/quick it is to use/learn/teach, ... that said, I really believe this thing is a failed effort.

A sidenote: the company who built this stuff produces a project tracking software called teamwork (demo here: http://twdemo.open-lab.com/ , login: demo, psw: demo), apparently not bad and built with those components. So maybe they want to drive attention to their software by means of exposing the technlogies it is built on: not a winning move, in my view, but this does not mean their product must be bad.

It is much more disapponting as far as the company who built this is italian, and it seems to confirm our worrying cultural backwardness with regards to this kind of technological evolution: much of the consulting companies here still tout Struts as the best thing since sliced bread.

Besides being completely out of scope, I think this comment is largely untrue and biased. Patterns here are quite accepted and part of any decent developer resume. Probably it is your customer base to suffer a technology gap.

It is much more disapponting as far as the company who built this is italian, and it seems to confirm our worrying cultural backwardness with regards to this kind of technological evolution: much of the consulting companies here still tout Struts as the best thing since sliced bread.

Besides being completely out of scope,

(since we're buried in a sub-thread I will continue here: if you want to go on with the discussion in an italian forum somewhere I'd be glad to move it there)

I think this comment is largely untrue and biased. Patterns here are quite accepted and part of any decent developer resume. Probably it is your customer base to suffer a technology gap.

Well, my customers aren't technologists (and a number of them are pretty old aged persons), so I imagine it's normal for them to suffer a technology gap. ;) Anyway, since you say that my statement is "largely untrue" I will quote from my direct experience:

1) it was november 2003, and it was already clear that there were pretty serious design flaws in Struts, when I heard the business manager of the (big) consulting firm that was helping my company build its next generation e-commerce system state that they would build as a "Service Oriented Architecture based on Struts, the new J2EE standard for web development". I hoped it only was a marketing statement due to the fact it was not a technical person who was speaking, but when I talked to the technical leader of the team who would build our system he told me pretty much the same stuff. When I told them I saw no smart way they could use Struts as a service framework and I thought Spring was a far better choice, they told me that no one in their company had ever heard about Spring or Hibernate, and their contact in a big analyst firm told them there were "no projects in the whole world which went into production on those technologies". When I pointed them to theserverside... they told me "that is a dictatorial community where open source leaders pay people for writing good things about their projects"... We set on a "Struts + Spring" compromise, and unfortunately today Struts is still limiting in various ways our system. As far as I know that company is still building on Struts today.

2) three weeks ago I talked to the project leader of one of the biggest italian companies, in charge with the project of rebuilding a number of internet portals and applications of the group, originally on ATG Dynamo. He told me they were defining the common architecture for the applications with the help of another (bigger) consulting company. Guess what the consulting company had suggested for the java web layer of their new applications, with a project starting in 2006?

3) An important web bank I know has recently re-built its web layer. They originally wanted to evaluate newer technologies such as JSF, but had to revert to Struts when the (big) consulting firm they asked to provide expertise and technical people contributing the project sent them a number of young consultants with Struts skills.

4) 5 minutes ago I went visiting the web site of another (medium sized, pretty well known in the italian java community) consulting company I have worked with in the past. They have a "success stories" on their front page: guess what is the only technology for the web layer they mention?

Of course the list could go on, and this is only related to Struts. The fact that the whole italian contribution to the open source java world, or the general java community in the large is far inferior to other so-called industrial countries is in my opinion absolutely evident to anyone. I know this hurts, and I'm the first one that would love a much greater involvement (and much more opportunities for technical passionates), but it doesn't help closing our eyes towards the reality.

Anyway, I really don't understand how my comment can be considered "largely untrue" or "biased": it may be questionable, but if it is, well... provide arguments against it.

FRAMEWORKS

It's not that we don't know the frameworks: it's that we progressively abandoned them, being unsatisfied. Our old applications used all the principles you mentioned, we started from Sun's Pet Store to Struts and onwards; we progressively felt that the burden of those frameworks was higher than the advantage, and the focus on matters secondary for us. We progressively discarded these principles as wrong or irrelevant. That MVC is a not apt to web frameworks is not only my personal opinion, it's been extensively discussed, also on TSS. I guess that it is also a question of personal taste: we are interested in spending our (limited) energies on the user interface, not in application architecture.

We went back to page centered web applications; I wonder if we are the only ones. We are quite happy with it: it lets us focus on building tools to make the pages as simple as possible, and completely componentized. We did not carefully enquire Spring, as we had already gone quite a way with our own, but from what I read (only in articles, not in practice) it seems much less cumbersome, but still has a different focus.

I hesitated before posting to TSS, as I knew that our framework is quite particular. But the TSS kindly published the news anyway. I believe that our problems are the problems of many, maybe a minority, maybe not, and I wanted to raise a different voice, and hear reactions (there are no bizarre commercial ends to this: Teamwork is a well known application by itself). Non dogmatic minds should always be ready to confront themselves with people contesting current beliefs.

JSP and HTML

JBlooming uses jsp for display and, contrary to what said in one of the first post, minimizes eventually reducing to zero the amount of hand written html in the page. You just instantiate and print your components. What's nice of these, and nobody noticed yet, is that they rely on JSP templates, where the dirty job is done, fighting with javascript, css, and so on, totally transparently to the developer who is building the application, and can be comfortably managed by the javascript and css/html experts. What you call "spaghetti code" to me looks quite clear and readable to all, just as spaghetti is a dish appreciated by all. Again I contest the assumption that use of JSPs implies bad code writing.

Interspersing HTML in JBlooming is still done only for tables, as up to now it seemed that building a table component would not make us gain much; the HTML table element is quite powerful, hence hard to emulate.

We never adopted tags, (actually we did for a while and then dropped them) as at least in classical usages a lot of effort results in a poor and rigid component. Moreover there is no standard for tags, so they don't speak for themselves. Direct usage of Java APIs on the JSPs is quite comfortable, they are strongly typed, and again I don't see anything intrinsically wrong with that. Why should I introduce yet another language, where I can use Java?

VALUE

I'd like to point out that in building the components quite some energy has been spent: in reducing the weight of javascripts, checking cross browser compatibility, keeping the overall weight of pages low and the HTML simple. These are important values for us. Try out for example the SmartCombo, or the Folio x-y layout.

With JBlooming you build light and pretty pages, querying on your Hibernate model and producing nice and fast applications in very short time. I ask no more from a framework. The fact that the pages are so simple makes them easy to maintain. I can grant you that if you agree with its premises, it makes web programming a real pleasure.

There is more in JBlooming than html components: a few examples:
- through the web interface you can turn on and do in place editing of all labels of the application in any utf-8 language; no programming, no opening files is needed for i18n management, which is done through the browser
- if you want a delete preview of an object, add a single line to your editor jsp, and on delete preview request, the framework inspects the hibernate and relational configuration, cascades included, and presents you (it takes care also of the layout, based on your current skin) a detailed preview of the deletion effect
- there is a configurable web based generic object editor which permits to create a search-edit-add-delete page in a few lines of code

And several others.

WEAK POINTS

There is no way to separate the components from the rest of the framework.
Friends that used the framework pointed out that there is so much freedom that you can easily end up doing a mess, if you are not an expert developer. Maybe it should be meant for developers who want some freedom after over-engineered experiences, not for beginners.

DISCUSSION

Last but not least, we at Open Lab are quite sensitive guys, and we are not used neither to insult or being insulted in discussing technical matters, nor in receiving gratuitous accuses of ignorance. We may be wrong, a bunch of reactionaries, our framework may be outdated and/or full of bugs, but to judge it you should get to know it at least in outline.

So be well, and think different!

Our old applications used all the principles you mentioned, we started from Sun's Pet Store to Struts and onwards;

Sigh...

we progressively felt that the burden of those frameworks was higher than the advantage, and the focus on matters secondary for us. We progressively discarded these principles as wrong or irrelevant. That MVC is a not apt to web frameworks is not only my personal opinion, it's been extensively discussed, also on TSS.

Isn't a form of model view controller what you're doing with your components? My surface skim of your code gave me the impression that what is missing in your design is the front controller. Moreover I think that when people argues against action-based frameworks (à la Struts) it is in general in favor of component-based frameworks (à la Tapestry), and very rarely in favor of JSP model-1: am I wrong?

Anyway: I find your design choices not particularly compelling, but your product an interesting one (what is funny is the fact that my boss asked me if I knew any time-tracking product, three weeks ago, and I suggested him to take a look at yours ;) ). I personally think Teamwork would be a better choice for a Theserverside post, and this for a reason that is not in contrast with what you say: we need more focus on "what matters" (the resulting application) and less framework talk.

I guess that it is also a question of personal taste: we are interested in spending our (limited) energies on the user interface, not in application architecture. We went back to page centered web applications; I wonder if we are the only ones.

Ok, but then is java the right technology for that approach?

minimizes eventually reducing to zero the amount of hand written html in the page. You just instantiate and print your components. What's nice of these, and nobody noticed yet, is that they rely on JSP templates, where the dirty job is done, fighting with javascript, css, and so on, totally transparently to the developer who is building the application, and can be comfortably managed by the javascript and css/html experts.

Ok, but this is exactly the focus of ALL the modern component oriented frameworks! Look at Tapestry, look at wicket, look at jsflets, they all allow you to embed a component in your pages with exactly one line of html code plus a custom attribute (be it jwcid or what else). These are pretty mature solutions: I'm not questioning your choice to develop a (probably good) product on an in-house technology, I'm arguing against the proliferation of frameworks, and your solution doesn't seem to provide anything valuable if compared to the mainstream one, that's all.

few examples:- through the web interface you can turn on and do in place editing of all labels of the application in any utf-8 language; no programming, no opening files is needed for i18n management, which is done through the browser

Uh. This sounds nice. I must correct the statement about the "anything valuable".

framework.Friends that used the framework pointed out that there is so much freedom that you can easily end up doing a mess, if you are not an expert developer.

I'm afraid this is why a lot of people moved away from that model a lot ago, even if of course not moving away is not a sufficient reason for a project to fail or the resulting product to be an unmaintainable mess.

Maybe it should be meant for developers who want some freedom after over-engineered experiences, not for beginners.

I'm afraid I would try ROR, instead.

receiving gratuitous accuses of ignorance.

Uh. I hope you didn't take offense at what I wrote: I stated that your framework "deliberately ignores" a lot of stuff, which is a pretty different statement than a gratuitos accuse of ignorance, in my view. The rant about italian technological backwardness was more induced by other facts, I admit: you probably didn't deserve it (but I hope you do understand its general reasons). Again: I don't like your framework at all, but you make an interesting product, which is more important, to me.

Consider the folio component: with it, first you can create the elements, using the object hierarchy, then you can refer to them and rearrange. Very hard to do cleanly with tags.
You don't make a cake by first and separately putting the ingredients on the table: and then at once put them all together. You use the first, mix it up, then add another, mix it up, and so on. Tags have no "command execute": they are pure state. This ambiguity ever present in code is one of its strengths. A further problem with tags is that they are the expression of a linear logic; but objects do more and better than that.

Back to our framework, then you display your folio, and add an Ajax external control to it (in a post it is wrongly stated that we ignore Ajax: on the contrary, we use it in full, here too without using tags for data exchange, but making it generate the html directly, that is the aim of the visualization), and are happy. See as examples the agenda and the joystick control, the Gantt diagrams, the dependency diagrams of Teamwork.

First aside: yes, we know that Canvas exists, when and if will be mature, we may integrate it. This will require, in our ugly framework, to change a single jsp and without even restarting the server, Canvas will be integrated. Oh so ugly!

Second aside: to understand the framework it would help to take even a cursory look at the tutorial pdf on the JBlooming site.

Very hard to do cleanly with tags.

I don't find the source code of that model-1 jsp to be clean at all, indeed. And not only because it starts with the same exact code that there was at the beginning of the other example:

<%
  PageState pageState = PageState.getCurrentPageState(request);
  if(!pageState.screenRunning) {
    // if this is the first time the page is loaded
    // the screen is set up
    pageState.screenRunning = true;
    final ScreenArea body = new ScreenArea(request);
    BloomingSiteHBFScreen lw = new BloomingSiteHBFScreen(body);
    lw.register(pageState);
    pageState.perform(request, response).toHtml(pageContext);
  } else {


making me think there is no answer to templating and general factoring needs in your framework.

You don't make a cake by first and separately putting the ingredients on the table: and then at once put them all together. You use the first, mix it up, then add another, mix it up, and so on. Tags have no "command execute": they are pure state.

This is why they are more often used in model-2 or component oriented architectures with actions or page-behind classes.

This ambiguity ever present in code is one of its strengths. A further problem with tags is that they are the expression of a linear logic; but objects do more and better than that.

Of course they do!! I'm not saying you should replace your model-1 JSP with some model-1 tag-based analogy, or stuff like velocity templates used as a general purpose programming model (I've seen it in the past, it was far worse than your JSP source). What I'm saying is something like: what if you have to provide different views for the same content and controller? Copy and paste. What if you have a common part that is used by most of the pages as in your demo? Copy and paste.

Your model is not the only one that exploits the advantages of object orientation, nor is it the only one that allows development by components. What I'm saying is that it seems to me that better alternatives exist for the same component oriented approach, which more clearly allow to separate code and graphic layout, and seem to offer more neat tools to manage the complexity of the web layer. Period: I'm not saying one has to only use procedural logic to develop a view.

This will require, in our ugly framework, to change a single jsp and without even restarting the server, Canvas will be integrated. Oh so ugly!Second aside: to understand the framework it would help to take even a cursory look at the tutorial pdf on the JBlooming site.

You may find it beautiful, but I still find things like this pretty ugly:


<td width="20%" align="center" valign="top" rowspan="2"><%
      // the properties container is set up
      Container properties = new Container(pageState);
      properties.title = "properties";
      properties.tableHeight = "100%";
      properties.start(pageContext);
      %><table border="0"><tr><td><%
      // every text field is instantiated and is given a default value
      TextField tf = new TextField("TF_WIDTH", "</td><td>");
      tf.label = "width";
      tf.fieldSize = 3;
      if(pageState.getEntry("TF_WIDTH").stringValueNullIfEmpty() == null)
        pageState.addClientEntry("TF_WIDTH", 300);
      tf.toHtml(pageContext);
      %></td></tr><tr><td><%


I'm not saying that a powerful object model and rich component framework isn't interesting: I do feel a very strong need for componentized web development. What is ugly in your code is not the Folio object. It is everything else in the same demo page: but the Folio object is not "a framework" in itself, it is an interesting component but I do not find it to be in any way an argument in favor of your model-1 approach.

I find the idea of creating components which, once simply configured and put on the page, layout themselves neatly a very good idea: this is the idea behing Tapestry, Wicket and JSF. Only, I find their approach to organization of the view templates far more compelling than yours: are you really sure you wouldn't have had a stronger architectural base for your same components and could anyway use the same design approach, if you provided for example a Folio component for Tapestry or Wicket?

Anyway, if you want to know what qualities I find JBlooming is missing, take a look at the sources behind these examples: http://www.wicket-library.com/wicket-examples/.

>What if you have a common part that is used by most of the >pages as in your demo? Copy and paste. No no no: you should develop the corresponding component, which is very easy, exactly because you can rely on a JSP template. You are missing some key features of the model, and you'll keep missing them, until you read the tutorial and try to use it. Limiting knowledge just to the components sample pages does not give you any idea on how to develop components, only on how to use the existing ones.

I downloaded the distribution, I will take a look at the source (not before the next week: we're approaching Christmas...). I would also like to try and port your Folio component to wicket or Tapestry. ;)

We took a first look at wicket (I always enjoyed cricket, being half British), and at first is seemed quite nice, going in a sensible direction. The components do very little compared to those of JBlooming, but this is their philosophy. Then we downloaded the sources, and.. oh my god.You have to keep in synch in two separate files tens of strings maintained by hand.. and this is "clean" code? No way to link them in a general Java IDE.. . At least ugly Jsp's are supported everywhere. No thanks.

I agree maintaining hand-code strings in 2 source files is a pain. But if tool support were the best criterium for choosing a framework, we'd all be using VB by now, wouldn't we? ;)