WEB4J - A Minimalist Java Web App Framework

Discussions

News: WEB4J - A Minimalist Java Web App Framework

  1. WEB4J has been built slowly over several years. Lately, it has reached a maturity which makes it "ready for prime time", and worthy of wide consideration. The important things about WEB4J are: - it's a full stack Java web application framework - it has a philosophy of deep simplicity and minimalism - it has the smallest "surface area" of any tool in its class (only 82 classes in its API) - it has no custom xml files or annotations - it has no custom tags for form controls (forms are implemented in plain HTML) - it doesn't use object-relational mapping - it lets you place your SQL statements in plain text .sql files - it lets you implement your Model Objects as immutable objects - it lets you place validation logic in your Model Object (where it belongs) - if your app is multilingual, it lets your app assist in its own translation - it lets you use package-by-feature (placing all items related to a single feature in the same directory). If this sounds interesting, you may download and examine its example application. This will give you a good idea of what an app built with WEB4J looks like.

    Threaded Messages (135)

  2. John- What makes you think you should be developing code? Everyone knows that Spring is the ultimate and final solution to everything. If it doesn't do something you need, you are wrong to need it (unless and until it's added later) and if it doesn't do something the way you want, you are wrong to want that. This page is awesome, by the way: http://www.web4j.com/Criticisms_Drawbacks_Pitfalls_Spring_Rails_PHP.jsp
  3. Excellent![ Go to top ]

    I love your criticism of Spring et al. I'm glad someone's speaking truth to power on this.
  4. Oh! Yet another...[ Go to top ]

    Oh! Yet another...
  5. Concerning some of the Spring stuff, I don't think the page is awesome at all. I think it is lame. Case in point "choosing between XML coding and annotations" That's bad?!?! What if I *want* to use either XML or annotation and don't want to use convention(which is the only method left I can think of) because I don't want to code my app to your framework's method of operation. "Spring AOP and AspectJ have a lot of repetition between them" Well, Spring AOP came first in Spring. If I wanted to choose between AspectJ, AspectWerkz and Spring AOP and went with the my Spring AOP only to have Spring drop Spring AOP, I would be pretty pissed and you guys would be harping about "lock-in." "Spring translates checked exceptions into unchecked exceptions. Many would disagree strongly with that approach. " And *many* think this is a good thing. If you don't like it, don't use it. Checked exceptions suck. "Spring doesn't help you implement toString, equals, or hashCode. " You need help with this? I'll hate to use your framework. "the Spring API doesn't use JDK 5 generics" Spring preceeded Java 5. Some unfortunate souls still have to use Java 1.4 or earlier. I had several projects that benefited from my use of Spring long before Java 5. Raise of hands for everyone who has coverted all their existing code to Java 5 generics. Who does this? "No dependence on Spring APIs. Spring repeatedly vaunts its ability to allow your code to be independent of Spring APIs. But wait a minute - isn't the whole idea of using a framework is to depend on it, and depend on it heavily? When a dependence is moved from Java code to XML code, Spring docs righteously claim that the dependence on Spring has somehow magically disappeared. This phraseology rests on the above mentioned delusion that placing items in XML somehow makes coupling disappear. This is a fallacy." Nonsense. That depends on the framework. On our projects the core code required EXTREMELY SMALL AMOUNTS OF DIRECT SPRING KNOWLEDGE. Why is this good? People can ramp up and very quickly on the business logic and get the app out the door without having to spend overly long amounts of time ramping up on Spring. Some APIs require a lot of direct knowledge to get the benefits. Spring didn't and this is a good thing. "Lightweight. Very few programmers would characterize a tool with more than 2400 classes, 82 dependencies on external jars, and a distribution size of 150 Meg as "lightweight". Many would characterize this, on the other hand, as pure bullshit. " I would say it is lightweight because I've rarely had to use all 2400 classes. You say in one breath that one should want to be dependent on a framework and then attack dependencies in the next. Who cares if it is 150megs. What are calling from 1993? And here is the biggest offender... "But wait a minute: Spring apps use extends and implements all over the place. This is easily verified by examining the Spring example applications. The Controllers use them, the DAOs use them, and the Validators use them. Many would assert that the above marketing blurb is a a manifestly false claim. " I've written spring apps and have almost no direct use of Spring APIs. You would never see them in any application, only very select base classes. You example is the same has those nuts from back in the day who based their knowledge of J2EE performance and LOC on Suns Petstore. Perhaps you lacked the wherewithal to write a Spring app correctly. Don't blame the tool. By your logic Java must suck because you could write Spring in it. ********************** James, find one single example where anyone who uses Spring said it was the ultimate and final solution. You guys who spend so much time hammering something, and not putting code out for the world to see, make up these nonsensical statements that no one utters, so you can then can prove the statements false. Why is that?
  6. "No dependence on Spring APIs. Spring repeatedly vaunts its ability to allow your code to be independent of Spring APIs. But wait a minute - isn't the whole idea of using a framework is to depend on it, and depend on it heavily? When a dependence is moved from Java code to XML code, Spring docs righteously claim that the dependence on Spring has somehow magically disappeared. This phraseology rests on the above mentioned delusion that placing items in XML somehow makes coupling disappear. This is a fallacy."

    Nonsense. That depends on the framework. On our projects the core code required EXTREMELY SMALL AMOUNTS OF DIRECT SPRING KNOWLEDGE. Why is this good? People can ramp up and very quickly on the business logic and get the app out the door without having to spend overly long amounts of time ramping up on Spring. Some APIs require a lot of direct knowledge to get the benefits. Spring didn't and this is a good thing.
    I agree that for testing reasons that IoC and DI are the best approach to manage dependancie, but I know for a fact that the Spring applications Ive written wouldnt work at all if I removed the spring libraries from the stack. To manually implement the service providers and underlying IoC system from scratch to replace the spring framework is not feasible in the slightest in the context of a project. But I don't see this dependancy on Spring as a bad thing. Its a framework that solves problems people have. Nothing comes for free. It made unit testing a reality for J2EE application and abstracted other annoying things and the price is dependancy on the underlying spring runtime contexr. I like Spring abnd recommend it for some projects I have control over, but this argument has always bothered me.
  7. "No dependence on Spring APIs. Spring repeatedly vaunts its ability to allow your code to be independent of Spring APIs. But wait a minute - isn't the whole idea of using a framework is to depend on it, and depend on it heavily? When a dependence is moved from Java code to XML code, Spring docs righteously claim that the dependence on Spring has somehow magically disappeared. This phraseology rests on the above mentioned delusion that placing items in XML somehow makes coupling disappear. This is a fallacy."

    Nonsense. That depends on the framework. On our projects the core code required EXTREMELY SMALL AMOUNTS OF DIRECT SPRING KNOWLEDGE. Why is this good? People can ramp up and very quickly on the business logic and get the app out the door without having to spend overly long amounts of time ramping up on Spring. Some APIs require a lot of direct knowledge to get the benefits. Spring didn't and this is a good thing.


    I agree that for testing reasons that IoC and DI are the best approach to manage dependancie, but I know for a fact that the Spring applications Ive written wouldnt work at all if I removed the spring libraries from the stack. To manually implement the service providers and underlying IoC system from scratch to replace the spring framework is not feasible in the slightest in the context of a project. But I don't see this dependancy on Spring as a bad thing. Its a framework that solves problems people have. Nothing comes for free. It made unit testing a reality for J2EE application and abstracted other annoying things and the price is dependancy on the underlying spring runtime contexr.

    I like Spring abnd recommend it for some projects I have control over, but this argument has always bothered me.
    As I said, I have extremely small amounts. For example, AOP and my base DAOs. However, in my projects, you won't see any imports to any Spring classes. Of course, you have to have the libs to compile. I just think web4j's statement is the true fallacy, IMO.
  8. "No dependence on Spring APIs. Spring repeatedly vaunts its ability to allow your code to be independent of Spring APIs. But wait a minute - isn't the whole idea of using a framework is to depend on it, and depend on it heavily? When a dependence is moved from Java code to XML code, Spring docs righteously claim that the dependence on Spring has somehow magically disappeared. This phraseology rests on the above mentioned delusion that placing items in XML somehow makes coupling disappear. This is a fallacy."

    Nonsense. That depends on the framework. On our projects the core code required EXTREMELY SMALL AMOUNTS OF DIRECT SPRING KNOWLEDGE. Why is this good? People can ramp up and very quickly on the business logic and get the app out the door without having to spend overly long amounts of time ramping up on Spring. Some APIs require a lot of direct knowledge to get the benefits. Spring didn't and this is a good thing.


    I agree that for testing reasons that IoC and DI are the best approach to manage dependancie, but I know for a fact that the Spring applications Ive written wouldnt work at all if I removed the spring libraries from the stack. To manually implement the service providers and underlying IoC system from scratch to replace the spring framework is not feasible in the slightest in the context of a project. But I don't see this dependancy on Spring as a bad thing. Its a framework that solves problems people have. Nothing comes for free. It made unit testing a reality for J2EE application and abstracted other annoying things and the price is dependancy on the underlying spring runtime contexr.

    I like Spring abnd recommend it for some projects I have control over, but this argument has always bothered me.


    As I said, I have extremely small amounts. For example, AOP and my base DAOs. However, in my projects, you won't see any imports to any Spring classes.

    Of course, you have to have the libs to compile.

    I just think web4j's statement is the true fallacy, IMO.
    Just out curiosity, do you use spring for Web MVC, transations, security or remoting?
  9. "No dependence on Spring APIs. Spring repeatedly vaunts its ability to allow your code to be independent of Spring APIs. But wait a minute - isn't the whole idea of using a framework is to depend on it, and depend on it heavily? When a dependence is moved from Java code to XML code, Spring docs righteously claim that the dependence on Spring has somehow magically disappeared. This phraseology rests on the above mentioned delusion that placing items in XML somehow makes coupling disappear. This is a fallacy."

    Nonsense. That depends on the framework. On our projects the core code required EXTREMELY SMALL AMOUNTS OF DIRECT SPRING KNOWLEDGE. Why is this good? People can ramp up and very quickly on the business logic and get the app out the door without having to spend overly long amounts of time ramping up on Spring. Some APIs require a lot of direct knowledge to get the benefits. Spring didn't and this is a good thing.


    I agree that for testing reasons that IoC and DI are the best approach to manage dependancie, but I know for a fact that the Spring applications Ive written wouldnt work at all if I removed the spring libraries from the stack. To manually implement the service providers and underlying IoC system from scratch to replace the spring framework is not feasible in the slightest in the context of a project. But I don't see this dependancy on Spring as a bad thing. Its a framework that solves problems people have. Nothing comes for free. It made unit testing a reality for J2EE application and abstracted other annoying things and the price is dependancy on the underlying spring runtime contexr.

    I like Spring abnd recommend it for some projects I have control over, but this argument has always bothered me.


    As I said, I have extremely small amounts. For example, AOP and my base DAOs. However, in my projects, you won't see any imports to any Spring classes.

    Of course, you have to have the libs to compile.

    I just think web4j's statement is the true fallacy, IMO.


    Just out curiosity, do you use spring for Web MVC, transations, security or remoting?
    I've used Spring for transactions and AOP. The AOP provided my security, caching, exception handling translations, some operational retry/recovery/notification items. For the web side, I've moved to GWT(or did before my current task). I've only just started looking at the Spring Security, but haven't used remoting yet.
  10. Couldn't agree more...[ Go to top ]

    The whole rant against Spring is full of holes; in fact, I would be hard pressed to find a single valid argument. When one has to resort to criticizing the framework based on the number of classes, that begins to stink (BTW, spring can be deployed in pieces: i.e. by using spring-aop.jar, spring-mvc.jar, etc.) Indeed, I am sure the JDK also has thousands of classes. That doesn't make it slower or faster. One badly designed class can slow down an application to a crawl; and a thousand well designed classes can make it fly. (A graph on the number of classes to promote Web4j? Give me a break!) Yes, spring IS lightweight. It's because the lightness comes in the number of layers and logic that needs to be traversed to get to what you want to do; Spring makes those layers very thin and that makes it lightweight. So what about XML? XML is not inherently evil or good. The question is whether it is expressive enough for what it's used. "Wiring" spring application in XML worked well for me; but if you don't want that, you can wire the whole ApplicationContext in java (or properties files, or groovy). Personally, XML has never been a show-stopper for me with Spring. The xml format is very human-readable and can be broken into any number of small component pieces for easier management. I think what is important to realize is that spring is not just a framework: it's a way to do things. And it's a pretty good way to do things.
  11. Re: Couldn't agree more...[ Go to top ]

    When one has to resort to criticizing the framework based on the number of classes, that begins to stink (BTW, spring can be deployed in pieces: i.e. by using spring-aop.jar, spring-mvc.jar, etc.) Indeed, I am sure the JDK also has thousands of classes. That doesn't make it slower or faster. One badly designed class can slow down an application to a crawl; and a thousand well designed classes can make it fly.
    +1 Good design often results in many (small) classes and interfaces.
  12. Sorry...[ Go to top ]

    I'm sorry, but I just can't even read past your delusional criticism of Spring. I really shouldn't even comment on your feeble marketing attempt at stirring things up for your project which will eventually will be long forgotten. "The Spring Framework is popular. It has also met with a disturbing lack of criticism. (Curiously, this combination was also true of early versions of Struts and EJB, now widely regarded as mediocre.)" Yeah, OK. So Spring has been around for how many years? And still a disturbing lack of criticism? Doesn't that tell you something? "it can boost your productivity by 300% - 400% over other tools" Hmmm, seems like April 1st has already past. How exactly did you come up with these numbers? Oh, wait, are you measuring productivity based on the number of classes and jar files? One measure of complexity is size. OK, great. One measure of success is user base. Let's talk in a year and see where things stand. Use: $500/feature [2.5 days/feature] $140/feature [0.7 days/feature] Learn: Spring: $4,080 [2 books + 4 weeks] WEB4J: $1,000 [1 week] Again -- where the hell did you get these BS numbers? OK, I normally don't go on like this. But was this written by developers or by marketing folks? Wait, so you have used the "package-by-feature technique". OK, so this was not written by developers. Thanks for the confirmation. That is so damn innovative, I'm just blown away.
  13. What made you think IBatis/Hibernate is tedious? For any one that knows basic JDBC, it takes him at most one day to learn IBatis. All SQL statements are stored in a xml file which is much better than in a plain text file. Do you actually know how important it is to use ORMs for a lot of java developers today? You should should remove that line in your marketing. Spring does have a learning curve. But once you have learned it, it is very productive. For me I use Flex for any front end work. Adobe has a very good IDE and I am much more productive using Flex than writing JSP/HTML. FLex is so much like Swing. If I could I would choose Flex over HTML anytime. In addition to ease of Flex coding, I can make visual stunning screens. Spring is perfect for my middle tier. IBatis/Hibernate is solid for my back end. I admire you courage to push yet another Java web framework and it is not free/not open source. You obviously believe that people would actaully buy it. You may be a good programmer. But you are not a good business man for sure.
  14. See Real world Flex apps[ Go to top ]

    http://flex.org/showcase/ RIAs are the future.
  15. Re: objections regarding ORM[ Go to top ]

    I stand by my objections to ORM. It is tedious, and somewhat invasive. That's my opinion, and I built web4j to reflect that. iBatis is indeed somewhat similar to web4j's data layer, with its focus on ResultSets, as opposed to table mapping. But it's no where near as simple as web4j.
  16. Re: objections regarding ORM[ Go to top ]

    I stand by my objections to ORM It is tedious, and somewhat invasive. That's my opinion
    You're very welcome to your opinion, and others have theirs. We on DataNucleus don't have such a black or white mentality. Persistence of flat object structures has its place. Persistence of large object graphs has its place. Persistence tools provide the mechanism and it isn't for us to preach what is or isn't the rule (and I personally have worked on more projects using large object graphs, unlike your experience). All projects are different. So at the end of the day use the right tool for the right job; having some general "rule" makes no sense. iBatis-style facilities add good value to the problem space and should be used where they fit the problem. You have some list of reasons why ORM is "invasive", and to be honest JDO meets none of your list, so you really ought to clarify in that list which ORM requires those features. Serializable? ... no. Non-final class? ... no. SetXXX methods ? ... no. No-arg constructor? ... no (added automatically if not provided). Annotations required? ... no. But then JDO is not just for ORM situations but also OO. --Andy DataNucleus
  17. Reply to Mark Helmstetter[ Go to top ]

    @Mark Helmstetter "So Spring has been around for how many years? And still a disturbing lack of criticism? Doesn't that tell you something?" Yes, it does: it tells me that many people aren't thinking critically about the tool. Just like in the early days of Struts and EJB. All tools have drawbacks. (Here are the drawbacks of web4j.) Do the creators of Spring state the drawbacks of their tool clearly in their docs? Where? "Again -- where the hell did you get these BS numbers?" They aren't BS. They are 'nominal' figures, taken as a simple example. Now that I look at it again, perhaps the word 'nominal' is not forceful enough to communicate this clearly to people scanning the text. I will amend...
  18. So Misguided[ Go to top ]

    Oh dear. This really is just wrong on so many levels.
    Yes, it does: it tells me that many people aren't thinking critically about the tool. Just like in the early days of Struts and EJB.
    Funny, I cannot remember a time when people weren't vocally critical of both Struts and EJB. And I love the galileo complex that is frequently in evidence here - that "followers of Spring" are misguided, and waiting for some enlightened soul to show them the light. Get this - *it is just a tool*. Some people find it far more productive to work with than without. Are you really arrogant enough to insist that you are right and everybody who is happily bumping along being highly productive with Spring as one of many tools in their arsenal is just flat out wrong because they don't see it your way? I have yet to see anyone loudly proclaim "Anyone not using Spring is just stupid", but I have seen the exact opposite time and again. Personally, I could not care less if you don't use Spring. You on the other hand seem te be on a crusade, with lots of misrepresentation and flat-out wrong statements.
    They aren't BS.
    They are. You've pulled them out of thin air to back up a point you wanted to make. This hilarious "feature" comparison cannot ever be meaningful, given the huge variation in what consitutes a feature. Lets say, for example, that the feature you want is that two given pages, sharing the same data access layer and DAO calls, should only fetch the columns from the database that are actually used in each case. Or that you need to add a write-through data cache that works in a cluster. In a Spring/Hibernate combo, these basically boil down to configuration. Are you seriously going to tell me that this is configuration that takes 2.5 days to implement? That this is even possible to do in WEB4j, let alone achievable in 0.7 days? And what is included in that time - test cases? Documentation? Aside from the fact that Spring/Hibernate are established technologies (If you're hiring someone who already knows the tools, then this supposed learning cost goes away), I think your learning numbers are both too high and too low. I take serious issue with the notion that it takes 4 weeks before you can even start writing code in Spring/Hibernate - that said, I think that the tools are so deep that 4 weeks is completely insufficient to know them inside and out. So what do your numbers represent? Barrier to entry or TCO? Either way the example is too simplistic to justify the incendiary conclusion you desperately want to make. Some other points: If you wanted to hand crank your SQL, what exactly is wrong with iBatis? Commons.Lang has helpers for reflective building of equals/hashcode/tostring. What's wrong with those? If I wanted a webapp that could do no more than simple CRUD operations, why would I not just knock it out in Grails in an afternoon? You seem deeply offended about Spring's enormous bundle size (including all the optional 3rd party libraries and integrations it offers for ease of use and consistency) and then suggest you might want to *add* a bunch of third party tools to your WEB4J application. So let me get this straight - it is fine to download iText and code a bunch of stuff by hand so I can get that functionality in WEB4J, but it is *not* fine to do exactly the same thing in Spring, but with less code due to the existence of a mature framework that works well with this library? What if I want to keep configuration external to the WAR bundle? What if I want to map multiple form values to the same model property? What if I want to run minimal unit tests against HSQLDB (using identity columns), and integration tests/production code against Oracle (using sequences)? How do your "fine-grained" security constraints deal with data ownership restrictions? Spring doesn't require custom tags for form elements. Some are provided, for simplicity's sake, but I've never used anything apart from spring:bind, which is broadly similar to (and much more powerful and flexible than) How do I deal with conversational state? "WEB4J has the smallest surface area of any tool in its class." - And also the lightest, most immature feature set. And frankly, if you're doing a spring comparison, comparing your tool to the *whole* of spring is laughable - at least restrict it to just the JSP-specific aspects of Spring MVC! There are some pretty funny criticisms of class naming, that display a shallow understanding of Spring, for example: "RequestContext | web | This refers to request parameters. In web apps, context refers to the application context, not request params." This is represents the context of the current request - what exactly is so hard to understand about that? Th "prototype | scoping | Refers to single-use objects. This name is bizarre." Really? Makes sense to me. It is a prototype bean definition, and every time it is requested from the bean factory, a new instance is returned. What was the criticism again? "ThrowawayController | web | Refers to the fact that the object can be garbage collected after use. From the point of view of the caller, this detail is completely irrelevant." The whole point of the ThrowawayController is to support the (fundamentally different) approach of having stateful-per-request controllers that are constructed on demand. The Javadoc makes this perfectly clear. What was the criticism again? "Spring doesn't let you avoid ResourceBundle and its defects. / it has no services for using a database to store translations, instead of properties files" Spring uses MessageSource extensively, and while there are three default implementatios, if you subclass AbstractMessageSource you can easily JDBC-enable locale-specific messages. The reason for *not* doing this out of the box is that such a class would be dependent on exactly how you map these things to the database - what your table is called, whether you have a table per locale, whether you subdivide tables depending on category of message, whether you use hibernate. There are far too many concerns here for Spring to provide an implementation that does not leak into your application design - and once again the flexibility and non-intrusiveness of the framework wins out. It is not only possible to do so, it is easy and the framework will work seamlessly regardless of the implementation you provide. Funnily enough, that's more than what you do, no? You basically say you have to implement implement a Translator yourself (no default implementation)? Doesn't yours not allow you to pass arguments when retrieving the message? Doesn't that then mean you have to worry about supplying message arguments elsewhere? You rant about the term "POJO" while completely missing the point. The drive to remove external dependencies from as much of our application as possible has been driven by frustrations with tightly coupled systems like EJB, and the resulting application fragility. This leads to an architecture that is better able to support testing in isolation, and flexibility that is more reusable across domains. "Object" is insufficient to describe the intent since everything, including tightly coupled, externally dependant services, can be described as an object (that's basic OO surely?), while POJOs are a specific subset. You call this "bullshit" - I call you wrong. "Hibernate's central idea is that database schemas should be configured in the application, such that SQL statements can usually be avoided, and replaced by object graph navigation" Utterly wrong. Hibernate is specifically designed to be as flexible as possible, and accomodate externally designed schemas as necessary. Yes, starting from scratch, it is nice to let Hibernate control this - but the reason for Hibernate's massive adoption and mindshare is that they do not impose this restriction, thus allowing legacy applications to be retrofitted with Hibernate. Given that Spring imposes no restrictions on how you organise your code, and we developed a Spring based application where features were organised logically by package over four and a half years ago, what exactly is so revolutionary about your vaunted "package-by-feature" technique that, frankly, is pretty old-hat and not suitable in all cases? Once again, you just don't seem to know what you are talking about. Your framework makes simple things arguably no simpler than doing exactly the same thing with Spring, and hard things impossible. That, and it smells of "Not Invented Here". We need another half-baked web framework like we need a hole in the head. Applying my critical thinking skills to this situation, I find your tool woefully inadequate, and your approach misguided and confrontational.
  19. Re: lack of crticism[ Go to top ]

    @Dave Hewitt "Funny, I cannot remember a time when people weren't vocally critical of both Struts and EJB." I certainly can.
  20. Re: So Misguided[ Go to top ]

    "Your framework makes simple things arguably no simpler than doing exactly the same thing with Spring, and hard things impossible." Well said!
  21. Re: iBatis[ Go to top ]

    @Dave Hewitt "If you wanted to hand crank your SQL, what exactly is wrong with iBatis?" iBatis isn't bad at all. But WEB4J is even more compact and minimalistic. - John
  22. Re: Translations[ Go to top ]

    @David Hewitt Regarding : "Spring doesn't let you avoid ResourceBundle and its defects." (my words here, not yours) You are right. This language is too strong. I will rephrase it... "Doesn't yours not allow you to pass arguments when retrieving the message? Doesn't that then mean you have to worry about supplying message arguments elsewhere?" Here is an example of a parameterized message. Note that such items are not hard-coded, in the sense that they are translated (if desired) by a translation tag in the JSP. - John
  23. Spring form tags.[ Go to top ]

    @Dave Hewitt: "Spring doesn't require custom tags for form elements." Sure it does - these are custom form tags. - John
  24. Re: Spring form tags.[ Go to top ]

    It absolutely doesn't require them. You can post directly with html elements with params of the form "model.propertyName", and I have done this many times. Hence, you can use any view layer technology, - freemarker, velocity etc. Form taglibs are provided as a convenience for those who like to use them. In fact, spring provided them in Spring 2.0 due to people asking for them.
  25. Spring forms with no tags[ Go to top ]

    @AlRo "You can post directly with html elements with params of the form "model.propertyName", and I have done this many times." That's interesting. Can you show me an example? How does the form get populated from a model object? Are absolutely no custon tags involved with the form in any way? - John
  26. @AlRo
    "You can post directly with html elements with params of the form "model.propertyName", and I have done this many times."

    That's interesting. Can you show me an example? How does the form get populated from a model object? Are absolutely no custon tags involved with the form in any way?

    - John
    Java code from tags almost always could be used on JSP pages directly (if you hate tags). Marina The only tags suite :-)
  27. Re: Spring forms with no tags[ Go to top ]

    @AlRo
    "You can post directly with html elements with params of the form "model.propertyName", and I have done this many times."

    That's interesting. Can you show me an example? How does the form get populated from a model object? Are absolutely no custon tags involved with the form in any way?

    - John
    You can use JSTL ${model.property} if you like Freemarker and Velocity are similar. It's all quite simple really.
  28. Re: Spring forms with no tags[ Go to top ]

    @AlRo Hmmmm. Correct me if I'm wrong, but the model.property style doesn't seem capable of two essential things : - repopulating the form when an input error occurs - populating the form with an existing model object, passed from the controller Those are the kinds of operations I'm interested in. Not just the simple task of POSTing a form... - John
  29. Let me clarify a bit with an example: Here is a JSP containing a form (in the WEB4J style): - link. The point is that this form handles: - posting - redisplay of posted data - display of an existing Model Object It does all that by wrapping a plain vanilla HTML form in a single tag. No JSTL. No scripting. No coding. No custom tags for each form control. Is that possible in Spring MVC (or any other tool)? I don't think it is...but please correct me if I'm wrong. - John
  30. Re: Spring forms with no tags[ Go to top ]

    If you want to completely do it without any tags, you would simply make the model available as a request attribute and use JSTL to initialize the text box etc. Alternatively, you could use spring.bind doing " ... As for "No custom tags for each form control." Yes, you do need to do it on a field by field basis,but I'm curious as to how a developer would go about formatting specific form fields with WEB4J, - eg. a money field to N decimal places, escaping Javascript in a comment text box to prevent cross site scripting. I would hope there is an override on a field by field basis...
  31. Re: Spring forms with no tags[ Go to top ]

    @AlRo Excellent point about the formatting. With forms, the data has 3 sources : - user input - re-displaying user input upon error - an existing Model Object In the first two cases, the formatting is determined, of course, solely by the user. In the last case, the formatting is determined by the tool. Currently, the tool uses fixed settings per application (defined in web.xml), with no override. The reason? Simply that, in my experience, that's exactly what the end users and their managers want. They love uniformity and standard ways of presenting data. That said, I understand your desire for an override. It's a good point, and I will consider it. For the moment, I will note it in the drawbacks. - John
  32. Re: Spring forms with no tags[ Go to top ]

    In real life applications you usually have a form that needs to populate data from muliple tables. How does web4j handle that? Also, I did not see any hint of business layer in your framework.. just dao/action/model??
  33. Re: data from N tables[ Go to top ]

    @Olonga Henry Extracting data from 1 table or N tables is the same. Similar to iBatis, the web4j data layer is not focused on tables. It's focused on ResultSets. - John
  34. Re: Spring form tags.[ Go to top ]

    They (tags) are optional. The usage is up to developer.
    @Dave Hewitt:
    "Spring doesn't require custom tags for form elements."

    Sure it does - these are custom form tags.

    - John
    P.S. nice thread. Where can I put link to our stuff? ;-)
  35. Re: Spring form tags.[ Go to top ]

    Not required. Seriously, been using it for years, never touched the form tags. There is a difference between "helpful, there if you want them" and "required".
  36. Re: package-by-feature[ Go to top ]

    @Dave Hewitt "Given that Spring imposes no restrictions on how you organise your code, and we developed a Spring based application where features were organised logically by package over four and a half years ago, what exactly is so revolutionary about your vaunted "package-by-feature" technique that, frankly, is pretty old-hat and not suitable in all cases? Once again, you just don't seem to know what you are talking about." Is package-by-feature really old hat? It's certainly the case that the idea of doing this has been around forever. My point is the following: other frameworks either lock you into using the (inferior) package-by-layer style, or are unaware that it is an issue. In practice, one is not very likely at all to see an app using package-by-feature. But maybe I'm wrong. Can you point to an example of a web application that stores all of the following items in the same directory, in a natural manner: - action class - DAO class - Model Object class (domain object) - JSP for the user interface - plain text .sql file containing the related SQL statements and has NO other items related specifically to that feature located elsewhere in the code? Even if you can, the point is that a tool should explicitly prod people in the direction of better design. And package-by-feature is better design. - John
  37. Re: package-by-feature[ Go to top ]

    My point is the following: other frameworks either lock you into using the (inferior) package-by-layer style, or are unaware that it is an issue.
    See, it is blanket statements of the inferiority of a given approach that just don't do you any favours. I've done it - and I've used lots of other approaches too, always trying to use a structure that best fits the problem at hand. Touting it as superior makes you sound as if you haven't thought it through. But then - benefit of the doubt - you are pimping this as a simple web frmaework, so yes, in simplistic cases, organising everything in one place does make the most sense. Having a separation between model/view/controller and service layer is just silly if you only have one of each.

    Can you point to an example of a web application that stores all of the following items in the same directory, in a natural manner:
    - action class
    - DAO class
    - Model Object class (domain object)
    - JSP for the user interface
    - plain text .sql file containing the related SQL statements

    and has NO other items related specifically to that feature located elsewhere in the code?

    Even if you can, the point is that a tool should explicitly prod people in the direction of better design. And package-by-feature is better design.


    - John
    Of course, I can't point to any from my own experience seeing as they're all proprietary ;) But in general terms - yes I've structured applications such that the domain class, controller, hibernate mapping file (including named queries), spring config and JSP are all contained in the same package. Also I have done the same with Wicket, which by default keeps its HTML views in the same package as the page classes (although you can change this). However, it is not my preferred approach for a project of any size/complexity. Personally I find the interdependence between any non-trivial domain object model will just lead to farily complex package interdependencies unless you separate out your layers as well. Similarily, service classes. Then when you get to pages that are general, but can work with domain objects of different types, or that have to deal with multiple, interdependent objects as part of the same flow, or if you want to split out your objects and use them in multiple applications, or expose them over web services - it just gets really messy if you blindly follow this supposedly "superior" style. Package-by-feature is not always better design. Nothing is.
  38. Re: package-by-feature[ Go to top ]

    You're absolutely right. I did make a statement which should have been justified. Thanks for pointing that out. Here are my justifications. "Package-by-feature is not always better design." I disagree, for the reasons stated in the above link. - John
  39. Re: package-by-feature[ Go to top ]

    You have two examples, trimmed for brevity here: # com.app.doctor # com.app.drug ... and # com.app.model # com.app.dao ... Which then leads on to a number of fallacious arguments about the ease with which one may be understood over the other, maintainability and internal consistency. Of course, I have yet to see a reasonably sized project that is not expressed something more akin to: # com.app.model.doctor # com.app.model.drug # com.app.dao.doctor # com.app.dao.drug Which is what you tend to do if you separate the layers package wise. If you have a lot of inter-dependent objects in your model this kind of thing *really* helps reduce afferant coupling, which is A Good Thing(tm). Your argument fails to address the points I made about splitting the object model out for use by a separate application. Or even, splitting part of it out to be used as public entities for a set of public web services. And here is a counter example. Lets say you have 30 features in your web-app. Lets say a subset of those (5?) are exposed via JSP forms and also REST. Lets say the approach you use has no confguration from the web.xml. Lets say you want to know which services have a rest interface - you are looking at searching all 30 feature packages to find which controllers have a parallel REST implementation. A problem you wouldn't have if you had split things up like: #com.app.web.[...] #com.app.web.rest.[...] This is a pretty fascile example - but don't you see there is no magic bullet? Not all applications are monolithic single use web applications with a JSP front-end. Package-by-feature is always better design, except when it isn't.
  40. Re: package-by-feature[ Go to top ]

    @Dave Hewitt "Which then leads on to a number of fallacious arguments about the ease with which one may be understood over the other, maintainability and internal consistency." The arguments aren't fallacious. They are quite reasonable. Anyone else think they have weight, I wonder? Re: The Scope of Model Objects In designing web4j, I tried to have Model Objects use package-private if possible, with only limited success. The only case is a Model Object which is *not* rendered anywhere in a JSP (which is not that common, in my experience). The problem is visibility in JSPs. JSPs are, as you know, implemented as servlets behind the scenes. The *class* of the JSP is determined by the container, and is not specified by the servlet/jsp spec. Thus, when a Model Object is rendered in a JSP, it needs to be visible to the JSP's package. Hence, any Model Object rendered in a JSP *must be *public*. Conclusion: this forces most (but not all) Model Objects in such apps to be *public* instead of package-private (preferred, since smaller scope). But even so, using package-by-feature is still useful, for what you might call its "navigational" benefits. In addition, I would imagine most data layers require public model objects as well (though I cannot confirm that offhand). Would you agree with that? Are you able to design package-private Model Objects in your apps? How? Are there not requirements made by the data layer to have them public? Do these questions make sense? Just want to understand where you are coming from... - John
  41. Re: package-by-feature[ Go to top ]

    I'll add some detail:
    * "These directories tell me nothing. How many features in this app? Beats me. It looks exactly the same as all the others. No difference at all. Great. Here we go again..."
    Already, the description of the thing you don't like is negative. You don't even pretend to put forth an objective opinion, merely imply that any sensible developer would be disheartened by encountering a package structure you view as deficient (but I view as perfectly acceptable). Then, you have this limited view of what constitutes a feature. Is it actions that can be performed by the user? Is it service classes? Is it domain objects? In any case what exactly prevents eg. a web-focused package from being subdivided by functional area? Nothing, that's what. This is an appeal to ridicule.
    * "Hmm. I wonder where this item is located....I guess its parts are all over the app, spread around in all these directories. Do I really have all the items I need? I guess we'll find out later."
    Come on - exactly the same is true if you have any dependencies between features. Or are all areas of your application completely isolated with no shared domain classes at all (and consequently with lots of repetition)? And exactly how hard is it to ctrl+click on a classname in Eclipse?
    * "I wonder if that naming convention is still being followed. If not, I will have to look it up in that other directory."
    So, people that follow package organisation schemes you don't like are also sloppy inconsistent developers? Nice. Fallacious argument.
    * "Oh my God, would you look at the size of this single directory....Good thing they are paying me to do this."
    Again, you are drawing the conclusion that there will be no further subdivision within a package. This is based on... what? Who imposes that restriction? Nobody, that's who. If you have five services, put them in the same package, fine. If you have fifty, split them up into subpackages, fine. You are railing against *code organisation*, rather than any fundamental design principle. Fallacious argument. The most important thing has to be consistency, and ensuring you don't violate the principle of least surprise. You are (intentionally or otherwise) implying that any structure other than the one you like leads to sloppy and inconsistent code. That is an unsupportable assertion, and offensive. I have never, ever entertained the idea of making model objects anything other than public. Final - sometimes. Immutable - sometimes. Package-protected? Never. Generally, my object model is the thing that actually expresses the problem domain - why would I care about it being public? I mean, I don't doubt you have your reasons - I just don't see how they actually help me, and it's a bit of an impractical ideal. I have in the past split out a set of interfaces from the object model, that expresses publicly available parts as a separate API (which is a subset of the behavior of the full object model). Perhaps you are solving a problem that I don't care about, or don't believe exists. Maybe you feel I should care, but I just don't see how it can be an issue.
  42. Re: package-by-feature[ Go to top ]

    "But in general terms - yes I've structured applications such that the domain class, controller, hibernate mapping file (including named queries), spring config and JSP are all contained in the same package." That's good. But from your comments, I wonder if we are really speaking of the same thing here. By package-by-feature, I don't mean that a single package is used for the whole app. I mean multiple packages are used, one for each feature, containing all items related to that feature (classes, JSP, sql/orm mapping). Each directory/package contains all items related to that feature. If any item can remain package-private, it does so. If it needs to be public, then it can be made public, as befitting whatever design seems appropriate. Please note as well that package-by-feature does *not* mean that separation of layers is abandonded - it is not. The separation of layers remains, but is implemented by separating items into different classes - as opposed to separating into *both* different classes *and* packages. Do we really agree on what package-by-feature is, I wonder? - John
  43. Re: package-by-feature[ Go to top ]

    @Dave Hewitt

    "Given that Spring imposes no restrictions on how you organise your code, and we developed a Spring based application where features were organised logically by package over four and a half years ago, what exactly is so revolutionary about your vaunted "package-by-feature" technique that, frankly, is pretty old-hat and not suitable in all cases? Once again, you just don't seem to know what you are talking about."

    Is package-by-feature really old hat?

    It's certainly the case that the idea of doing this has been around forever. My point is the following: other frameworks either lock you into using the (inferior) package-by-layer style, or are unaware that it is an issue. In practice, one is not very likely at all to see an app using package-by-feature.

    But maybe I'm wrong.

    Can you point to an example of a web application that stores all of the following items in the same directory, in a natural manner:
    - action class
    - DAO class
    - Model Object class (domain object)
    - JSP for the user interface
    - plain text .sql file containing the related SQL statements

    and has NO other items related specifically to that feature located elsewhere in the code?

    Even if you can, the point is that a tool should explicitly prod people in the direction of better design. And package-by-feature is better design.


    - John
    Here is the biggest flaw in web4j; and take no offense, but is is you. I detest tools that think they know better than I do and tool should not "prod" you into "better" design. That last thing I want from any tool is one that fights me. I've been successful for years without tools forcing me into its convention. I hate that. No one who is that certain that he is correct and everything opposing him is wrong. You seem a little...restricted in your thinking. I found a half-dozen flaws in your thinking in your Spring section alone. I shudder to think how rigid your code is and what would happen if someone did something you didn't anticipate. According to you, you've already changed what four or five items *today*. This is what happens when you don't entertain different points of view. In addition, how do I know that your design is better. We don't see your code. It's what I mentioned before. If I don't fundamentally agree with the philosophy, I don't trust the tool and wouldn't bet my job on it.
  44. Re: package-by-feature[ Go to top ]

    @David McCoy "No one who is that certain that he is correct and everything opposing him is wrong. You seem a little...restricted in your thinking." I prefer opinionated :-). Some people like opinionated tools, some don't. This is understandable and natural. "According to you, you've already changed what four or five items *today*. " Aren't your two statements contradictory? If you are referring to the several recent edits I've made to the content of web4j.com, then please note that I did so in response to valid criticisms made in this thread. When people's arguments make sense to me, I react to them. I correct my errors, and quickly. Isn't that proper dharma? Maybe you're right. I promise to be less categorical in future....mea culpa.... - John
  45. Re: package-by-feature[ Go to top ]

    @David McCoy
    "No one who is that certain that he is correct and everything opposing him is wrong. You seem a little...restricted in your thinking."

    I prefer opinionated :-). Some people like opinionated tools, some don't. This is understandable and natural.

    "According to you, you've already changed what four or five items *today*. "

    Aren't your two statements contradictory? If you are referring to the several recent edits I've made to the content of web4j.com, then please note that I did so in response to valid criticisms made in this thread. When people's arguments make sense to me, I react to them. I correct my errors, and quickly. Isn't that proper dharma?

    Maybe you're right. I promise to be less categorical in future....mea culpa....

    - John
    I never said you were stubborn. I'll like to think that anyone, when reasonably confronted with error will correct them. My point is that you were sure when you posted them. Certain, I'd suspect. You just seem a bit too certain. It doesn't really matter, I wish you luck on your tool.
  46. Re: Hibernate's central idea[ Go to top ]

    @Dave Hewitt You respond to my "Hibernate's central idea is that database schemas should be configured in the application, such that SQL statements can usually be avoided, and replaced by object graph navigation" with Utterly wrong. Hibernate is specifically designed to be as flexible as possible, and accomodate externally designed schemas as necessary. Yes, starting from scratch, it is nice to let Hibernate control this - but the reason for Hibernate's massive adoption and mindshare is that they do not impose this restriction, thus allowing legacy applications to be retrofitted with Hibernate." You are right. I mispoke, and my intent was ambiguous. I have amended the text to : "Hibernate's central idea is that database schemas should be repeated in the application layer, such that SQL statements can usually be avoided, and replaced by object graph navigation." And I stand by that statement. - John
  47. Re: Hibernate's central idea[ Go to top ]

    @Dave Hewitt

    You respond to my
    "Hibernate's central idea is that database schemas should be configured in the application, such that SQL statements can usually be avoided, and replaced by object graph navigation"

    with
    Utterly wrong. Hibernate is specifically designed to be as flexible as possible, and accomodate externally designed schemas as necessary. Yes, starting from scratch, it is nice to let Hibernate control this - but the reason for Hibernate's massive adoption and mindshare is that they do not impose this restriction, thus allowing legacy applications to be retrofitted with Hibernate."

    You are right. I mispoke, and my intent was ambiguous. I have amended the text to :

    "Hibernate's central idea is that database schemas should be repeated in the application layer, such that SQL statements can usually be avoided, and replaced by object graph navigation."

    And I stand by that statement.

    - John
    What's wrong with graph navigation. I had customer's dba hand me a paragraph size piece of unrequested SQL when I did the same thing in a far easier to understand, PORTABLE HQL/graph nav combo. In this case, Hibernate won out. I don't follow your database schema in the app layer. Could you elaborate? And what's wrong with not writing SQL? Why write it if I don't have to? If I need to optimize, you can easily have Hibernate replace its SQL with your own. Why not let Hibernate do its thing, and optimize later?
  48. @David McCoy What I mean by "repeating the database schema in the application layer" is simply that Hibernate config files (for example) repeat information that is part of the database schema - 'null-ness' of a field, uniqueness constraints, key info, and so on. It requires this info in order to work. But I argue that this since such *detailed* schema information is never present in SQL statements, that this violates encapsulation. Yes, yes, I know that SQL statements need to know about tables - but why do they need to know *everything* about them? Is this a practical issue, or theoretical? Well, it's clear that when the db schema details change, the mapping has to change as well, in order to remain synchronized. And that just gives me bad feelings... The database no longer carries any secrets. Its implementation details become public property... - John
  49. @David McCoy

    What I mean by "repeating the database schema in the application layer" is simply that Hibernate config files (for example) repeat information that is part of the database schema - 'null-ness' of a field, uniqueness constraints, key info, and so on. It requires this info in order to work.

    But I argue that this since such *detailed* schema information is never present in SQL statements, that this violates encapsulation. Yes, yes, I know that SQL statements need to know about tables - but why do they need to know *everything* about them?

    Is this a practical issue, or theoretical? Well, it's clear that when the db schema details change, the mapping has to change as well, in order to remain synchronized. And that just gives me bad feelings...

    The database no longer carries any secrets. Its implementation details become public property...

    - John
    Hmmm...I don't know. Even before Hibernate in the days of raw JDBC, I needed to know that a field was not-null. You usually found out when it failed. Why not be able to look at a xdoclet or Hibernate annotation to see this. And I'm someone who doesn't like a lot of annotation for reasons that are very similar to what you seem to think about Hibernate info. If the db changes in the right way, your SQL still needs to be sync. What's easier? Adding a field attribute setter/getter to a pojo or modifying every sql statement accessing that table. I don't believe that you can segment developers or development into "front-end guy, db guy, middle tier guy." Instead, a person will work on all tiers. That stuff you mention, IMO, cannot affect or be affected by its presence. An annotation in a pojo marked as not-null doesn't hurt anything. If the DB changed inteh right way, someone has to change something. I think this is a purist item and non-issue.
  50. @David McCoy

    What I mean by "repeating the database schema in the application layer" is simply that Hibernate config files (for example) repeat information that is part of the database schema - 'null-ness' of a field, uniqueness constraints, key info, and so on. It requires this info in order to work.

    But I argue that this since such *detailed* schema information is never present in SQL statements, that this violates encapsulation. Yes, yes, I know that SQL statements need to know about tables - but why do they need to know *everything* about them?

    Is this a practical issue, or theoretical? Well, it's clear that when the db schema details change, the mapping has to change as well, in order to remain synchronized. And that just gives me bad feelings...

    The database no longer carries any secrets. Its implementation details become public property...

    - John
    +1. Well said John,could'nt agree more.
  51. Re: Hibernate's central idea[ Go to top ]

    "Hibernate's central idea is that database schemas should be repeated in the application layer, such that SQL statements can usually be avoided, and replaced by object graph navigation." And I stand by that statement.
    And again I'd disagree ;) What hibernate (and any decent ORM tool) tries to do is overcome that tired old object-relational impedence mismatch. It tries to let you design an object model that best expresses the problem domain, and map that to a table structure that can most efficiently store the data. Naively replicating the table structure as objects in a one-to-one fashion is missing the point. Hibernate is a *mapping* layer - it by necessity has to know about both your objects and your table so that you can work on either end pretty much in isolation and let hibernate worry about keeping the two consistent. Of course, in practice, it is a road to ruin to design an object model with no thought for how the data will be persisted, but it removes a lot of the obstacles. Later on in this thread you mentioned that hibernate needs to know about nullability and constraints - and in most cases that's not true. It has to know about keys (primary and foreign), but that's about it. You *can* put database details in hibernate mapping files (index names, column widths) - but if you do that its generally because you intend to let hibernate manage your schema for you. In that sense, hibernate can totally move ownership of your schema into the application layer, letting it make changes as necessary. If you do this there is no repetition of database schema - it is maintained in one place, by hibernate. So, wandering back to my point (eventually...) - I disagree with your use of the word repeated with reference to the database structure. It doesn't repeat it - it abstracts it.
  52. Reading this thread I'm reminded of one thing regardig posting at TSS - never, ever, criticize Spring. It's sacrilege! After all, Spring is absolutely perfect, right?. Anyone who does not realize this completely obvious truth is flammed to eternity, and considered an complete and total moron. EJB 3.0? - fair game. The intelligista of TSS consider EJB 3.0 a shallow pretender to Spring's absolute perfection. JSP? - fair game. Everyone knows that using JSP in any form is "so 1998". C'mon you guys, lighten up. Spring, the fine tool that it is, has it's own set of warts, just like everything else in the Java Web/Enterprise space. And I rather enjoyed this guy's Spring criticisms on the web4j website. Some stuff is a stretch, but a lot rings true. He's right in the amount of XML, and the fact that it isn't really "configuration", but coding (in a really ugly, error prone, tedious syntax), and also eliminates compile time error checking. He's also right in that this was not the way XML was intended to be used. XML excels as a thin data transfer and RPC mechanism between disperate systems. It sucks for providing "wiring" or "configuration" or "actual functionality" within one system. But Spring makes you do this. I don't know how good the new annotation support is (which is very much a step in the right direction, and a year later than EJB3 ;) ).
  53. Here is my point. XML. It's always about that and as I've said, the XML doesn't bother me. Never did. In fact, I think it is an advantage that has paid off time and time again. I'll John credit, while I don't agree with his assessment, at least he was creative in his thinking as opposed to a true parrot. "XML Squawk!!"
  54. No, the lesson is, if you're going to make any kind of criticism, don't dress up personal preference as immutable fact. I can (and do) readily criticise Spring in lots of areas. For example, I've always felt that Spring MVC relied too much on inheritence over composition, and left you with a confusing lifecycle and instances where you wanted one set of controller behaviour that wasn't available because of the baseclass you'd inherited from. This is something that's been addressed a lot in later releases, mind, but I tend to go with Wicket more and more these days. I agree that finding out errors at run-time, rather than build time due to unchecked external configuration is A Bad Thing. However, Spring IDE helps a lot, and in my case I found this was yet another incentive to have great test coverage ;) It's one of those things where I've found the trade-off to be well worth it, and you haven't. I personally don't have a problem with expressing my dependencies external to my code. It just lends itself to having lightweight, reusable components that can be reused in a different context with some minor changes to their configuration. I personally dislike annotation-based configuration, but I would never criticise someone for using it because I can see the strengths also. An awful lot of commenters seem to have a persecution complex that seems to convince them of the rightness of their position, and I always view that stance with deep suspicion - that smacks far more of entrenched beliefs than someone defending Spring because they find it useful. Basically, if you write a good framework, it should be utterly irrelevant whether someone also uses Spring alongside it - setting yourself up in opposition to that seems like a waste of time and energy, and in many cases a blatent attempt to grab publicity.
  55. Answers to some questions[ Go to top ]

    @Dave Hewitt Commons.Lang has helpers for reflective building of equals/hashcode/tostring. What's wrong with those? There's lots with commons lang. Magic strings can be used when implementing toString (not good). The equals method is not necessarily consistent with hashCode. These facts alone are enough to render commons lang mediocre. When using the reflection style, the commons lang docs state : Because these fields are usually private, the method, reflectionToString, uses AccessibleObject.setAccessible to change the visibility of the fields. This will fail under a security manager, unless the appropriate permissions are set up correctly. Web4j apps do not suffer from the above defects. What if I want to keep configuration external to the WAR bundle? The web.xml items must currently be placed in web.xml. Of course, any items specific to your app can be placed anywhere you want. I considered providing alternate ways of specifying config other than web.xml, but it doesn't seem quite compelling enough. What if I want to map multiple form values to the same model property? Not a problem. What if I want to run minimal unit tests against HSQLDB (using identity columns), and integration tests/production code against Oracle (using sequences)? If you use ANSI standard SQL statements in your .sql files, then they can usually be used against N databases. You can configure a 'test double' database by defining an alternate implementation of the ConnectionSource interface (not a lot of work). There are possibly some differences if the target db does not return the id of INSERTed items, but these should be minor. How do your "fine-grained" security constraints deal with data ownership restrictions? They don't. To implement ownership of records per person, you would need to implement that using WHERE criteria in the underlying SQL statement, as in WHERE ID=?. The ID becomes just another parameter. In this case, the id can usually be taken from a user id stored in the session. If the ownership restrictions are by role, not user id, then some ad hoc mechanism would need to be created to handle that. Maybe I could look at that further. It might not be common enough to warrant being in a minimalist framework. I will chew on it... How do I deal with conversational state? By using sessions. - John
  56. Typo in previous post[ Go to top ]

    Previous post should read: There's lots wrong with commons lang.
  57. Now open source[ Go to top ]

    The WEB4J tool is now open source. It has been released under the BSD License.
  58. Re: Reply to Mark Helmstetter[ Go to top ]

    @Mark Helmstetter

    "So Spring has been around for how many years? And still a disturbing lack of criticism? Doesn't that tell you something?"

    Yes, it does: it tells me that many people aren't thinking critically about the tool. Just like in the early days of Struts and EJB. All tools have drawbacks. (Here are the drawbacks of web4j.) Do the creators of Spring state the drawbacks of their tool clearly in their docs? Where?


    "Again -- where the hell did you get these BS numbers?"

    They aren't BS. They are 'nominal' figures, taken as a simple example. Now that I look at it again, perhaps the word 'nominal' is not forceful enough to communicate this clearly to people scanning the text. I will amend...
    Come on. Do you seriously think many people haven't done critical thinking? Back in 05, I had to convince both management and customers that things like Spring and Hibernate were worth using. You don't like it. Fine. But don't act like the rest of us were tricked somehow. Perhaps the Spring guys feel that their market can analyze for weaknesses on thier own. While Struts 1's time has passed, in 2000, it set a standard that frankly, no one has duplicated in the web app framework realm. Why is it that no one has acheived the ubiquity of the technically inferior Struts?
  59. Re: Reply to Mark Helmstetter[ Go to top ]

    Ditto Java badly needs to successor (in terms of mindshare, not Struts 2..) to Struts 1.x to emerge. Struts despite its faults did a lot for the adoption of Java generally for a number of years. Perhaps it could be GWT? - looking at amazon there's already a half dozen books out there so it seems to be getting a bit if traction.
  60. Re: Reply to Mark Helmstetter[ Go to top ]

    Ditto

    Java badly needs to successor (in terms of mindshare, not Struts 2..) to Struts 1.x to emerge. Struts despite its faults did a lot for the adoption of Java generally for a number of years.

    Perhaps it could be GWT? - looking at amazon there's already a half dozen books out there so it seems to be getting a bit if traction.
    IMO, GWT is awesome. Creating components,especially from existing components is as clean as it can get. It was easy to pick up(I did far more MFC than Swing/AWT) and still got the gist. It's major weakness, IMO, is how to handle persistence properly...oh and huge tables. And no core Drag and Drop. What's the problem?!?!? And more components, ExtJS-like stuff. But writing, debugging, and refactoring in Java, very sweet. My current job requires JS for the front-end and even with Idea's JS support, it is a beast.
  61. Here's an example of the problem: The Google result for spring framework criticism doesn't come up with a heck of a lot. The only thing of real interest are some remarks by Bob Lee. That's it, really. Another point: the wikipedia article for Spring reads like an advertisement. Where is the balance? Any trade-offs? Any pitfalls? Apparently it doesn't have any. Do you know of any collected, coherent criticisms of Spring? I don't. I can't find any. And I think that its important to point that out. - John
  62. Here's an example of the problem:

    The Google result for spring framework criticism doesn't come up with a heck of a lot. The only thing of real interest are some remarks by Bob Lee. That's it, really.

    Another point: the wikipedia article for Spring reads like an advertisement. Where is the balance? Any trade-offs? Any pitfalls? Apparently it doesn't have any.

    Do you know of any collected, coherent criticisms of Spring? I don't. I can't find any. And I think that its important to point that out.

    - John
    Well, Guice was created as pretty much the anti-Spring. And look out if you need pre-Java 5. Second, Spring battled Hivemind,whatever was put in Tapestry 4, and picocontainer and emerged victorious. Perhaps it is better. Third, why is that important to point out? You can download Spring, source and all, and see all the warts for yourself. Also, some of the things you've listed on your site like multiple methods of doing certain things is a direct result of complaints. People said they wanted less XML(I don't agree,but there you go) and more annotations, autowiring, and custom tags and Spring put it in. And then gets hit for bloat. Which is it?
  63. Re: Importance of criticism[ Go to top ]

    @David McCoy "Third, why is that important to point out?" Criticism is important since if it's absent, then there's a grave danger of wide adoption of mediocre tools. For example, in my opinion (and in the opinion of others) early versions of both Struts and EJB were mediocre. And yet, they became widely used. How is that possible? One main reason: a lack of critical thinking. That's why I think its important to point that out, and I stand by it. - John
  64. Re: Importance of criticism[ Go to top ]

    @David McCoy
    "Third, why is that important to point out?"

    Criticism is important since if it's absent, then there's a grave danger of wide adoption of mediocre tools.

    For example, in my opinion (and in the opinion of others) early versions of both Struts and EJB were mediocre. And yet, they became widely used.

    How is that possible? One main reason: a lack of critical thinking.

    That's why I think its important to point that out, and I stand by it.

    - John
    You are not looking for criticism. You are looking for articles criticizing. I stand with the other guy: Perhaps the reason is that people don't find much fault. There may be things it does't do as well technically possible, and certainly isn't perfect, but that is a far cry from finding it faulty That's what you want. Your premise, I think is flawed. Struts was not medicore. Struts did what it did better than any other tool at the time, namely combining ease of use, flexibility, and functionality. You seem to assume that people someone missed its flaws. Clearly, what Struts has done is hard considering all of the supposedly superior alternatives probably still don't equal Struts usage. It was a great tool, for the time. When I first tried using EJB, its faults were immediate evident. Hard, inflexible, intrusive APIs, not very portable, perhaps Spring isn't as faulty. Technology does improve and should get less faulty as time goes on. Windows XP, while not perfect, is an order of magnitude better than Windows 95 which was better than Win3.1 and was better than WinNT 4 and WinNT 3.51. Why don't you release your source so we can see its warts?
  65. Re: importance of criticism[ Go to top ]

    "You are not looking for criticism. You are looking for articles criticizing." That's right. The whole point of criticism is to find fault, is it not? The philosopher of science, Paul Feyerabend, once said (paraphrasing here) "Scientists should disagree unless forced not to." "[Struts] was a great tool, for the time." I disagree. I think it is, and always was, mediocre. "When I first tried using EJB, its faults were immediate evident." I agree. The point is there doesn't seem to have been any significant criticism of EJB in its early days. And to me a marked lack of criticism is a symptom of groupthink, to which I am constitutionally allergic :-)... - John
  66. "[Struts] was a great tool, for the time."

    I disagree. I think it is, and always was, mediocre.
    Finally, we agree :-) In fact, at the time it came out I thought Struts was pretty cool, but that was because I was still very inexperienced and because Struts was almost the same as an in-house framework I created a few months before I learned about Struts, so I figured that if more people came to the same conclusion, there must be something in that idea. Now I realize the most obvious idea isn't always the greatest, and I regularly day dream about how much better the world of Java would look today if Apple had open sourced WebObjects and it had become mainstream. That would have been a much better alternative (as it still is).
  67. Re: importance of criticism[ Go to top ]

    "You are not looking for criticism. You are looking for articles criticizing."

    That's right. The whole point of criticism is to find fault, is it not? The philosopher of science, Paul Feyerabend, once said (paraphrasing here) "Scientists should disagree unless forced not to."

    "[Struts] was a great tool, for the time."

    I disagree. I think it is, and always was, mediocre.

    "When I first tried using EJB, its faults were immediate evident."

    I agree. The point is there doesn't seem to have been any significant criticism of EJB in its early days. And to me a marked lack of criticism is a symptom of groupthink, to which I am constitutionally allergic :-)...

    - John
    I think the point of criticism is to understand. Is it good or bad? Is is useful or not? Finding fault and agreement are not mutually exclusive. We agree that EJBs are faulty, for instance. I guess we'll disagree about Struts. It was better than raw JSP, in my opinion, and succeeded and standardizing the market. As opposed to trying everyone's in-house, custom framework. No one else has acheived this. "It sucks, but people just didn't see it." isn't a reasonable explanation. For EJB's early days, when I used it, the faults were evident to me and to other developers. As soon as we used it. Spring is, IMO, a different experience. And years later, I think it stands the test of time.
  68. Re: getting sidetrack[ Go to top ]

    It would be nice to get back to the character of web4j, if possible. The first poster pointed to a criticism of Spring, so it seems things have gotten a bit sidetracked....I created that criticism only because there seemed to be lack of such remarks elsewhere, that's all... Any further comments about web4j itself? You can be as critical as you like :-).... - John
  69. Wht abt hibernate?[ Go to top ]

    I am always looking simpler MVC framework which uses jsp+jstl for UI. But deal breaker is proprietary dao layer. I am already using Hibernate and just looking for simple mvc framework. 1. Is hibernate pluggable? 2. How you compare your MVC to Struts2 "2"?
  70. Wht abt hibernate?[ Go to top ]

    Hibernate The web4j data layer is optional. You can implement your data layer using Hibernate, JPA, or any other tool. Struts2 Sorry, I'm not very familiar with Struts2. From a cursory examination of their docs, it would seem that : - it uses many more custom tags - its forms are implemented with various custom tags for each control (web4j has only the single 'populate' tag) - it uses custom xml config (web4j uses only web.xml) - it's not a full-stack tool (web4j is full stack) - it use Java Beans, not immutable objects (web4j loves immutables) - its validation is external to the model Object (not in web4j) - it uses properties files (no properties files in web4j) - can localization be done with db, not properties? (web4j allows db to be used) - the examples don't put all items related to a feature in a single directory - including JSPs and .sql files (web4j allows this) This is only from a cursory examination of their docs...(I will look at this more closely.) Thanks for your interest. It was a good question. - John
  71. Versus Struts2[ Go to top ]

    My comments above on Struts2 should likely be ignored. It seems like a good tool. Since I don't know much about it, I should just shut up. In general, it's safe to stick to these simple generalities : - Struts2 is for the UI, while web4j is full stack if you need it. - they are both MVC - they differ markedly in styles of validation - their HTML forms are also markedly different - Struts2 has much more flexibility and complexity than web4j. Web4j is bare bones - it's a dwarf in comparison. I think those comments are on safe territory.... - John
  72. spring?[ Go to top ]

    It's an entertaining read but to me this article tells me that you may missing the historical context spring was born and perhaps not fully understanding some of the key concepts of spring. let me start by saying this: Spring is not web framework. yours sounds like is. I'll also admit that i am biased - having used spring since 0.5 days and having referred to its source code many many times in the past 5 years. I treat spring source code as a bible for java code - best practices and learned so much. i'll also say this - spring completely killed ejb market (except for a few special cases where ejb made/makes sense) and made the pendulum swung back to java after some years of .net movement. now some of the details - and i am not disagreeing with everything you stated. singleton: The whole idea of spring bean being "spring singleton" vs real singleton is because of the traditional issue with true singleton model in J2EE context where in theory you have no control over it's lifecyle. One of the most important feature of spring to me is that it manages the lifecycle of your beans. just do me a favor and open up a profiler, shutdown your webapp and see how many garbage objects/static variables/singleton objects are hanging around. spring tries to address that for you. Spring MVC: MVC itself clearly indicates it's a web application framework. Spring MVC wasn't even part of the spring core framework until later (1.2 maybe?). but it's a part of spring that I dislike the most because of its complex hierarchy object model. Prototype: it means exactly what it means. " the name is bizarre" - any technical explanation you can provide on this statement? bean: it doesn't say javabean does it? spring doesn't say it is a java bean framework. it's a pojo framework. javabean obviously is a better practice to adopt, but spring is not forcing you to write your pojo in certain ways. XML config: Spring supports annotation based configurations but it's up to you decide whether you want xml or annotation. Again spring gives you an option how you want to develop your app. I happen to think overused annotation is worse than xml config file and still prefer some of the configs to be in my xml file. I wouldn't want to define my session factory/datasource/connection pool/email server/jndi/jms stuff in my source code. do you? POJO: The term was born because of all the rules you need to conform to implement J2EE apps - most specifically ejbs and mdbs. Spring guys didn't come up with the term. Generics,Annotations etc: Someone already mentioned it but spring is a framework and it was born way before java 5 was released. You don't really think spring should have just dropped support for 1.4 users just because java 5 is out. They will remove 1.4 support when Sun stops supporting 1.4 which should be pretty close. # of classes/jars : You don't need the full spring jar. You can selectively include spring jars (spring-aop, spring-core, spring-hibernate3 etc) individually to fit your project need. Same goes with the dependencies - you don't need to include hibernate if you are not using it, you don't need jdo if you are not using it. spring actually has two distribution - one without all the dependencies, one with all the dependencies. maybe you can redo your analysis and see for yourself how much valid your arguements are. I agree with some of the things - but I have to say for most part I don't see any valid objective arguments. I think most of your criticism is based on either your lack of understanding or your preferences on certain things and your subjective views. just the fact you are comparing application framework to your web framework tells me that you don't fully understand the scope of the problems spring is trying to solve?
  73. Re: spring or Web4J?[ Go to top ]

    Factual Arguments:-- There are number of problems in the arguments put forth by Web4J. 1. Spring related have already been thrashed! For God's sake, please do not show ignorance (alarming levels of it) by comparing it to any application fwk like Spring/EJB/etc. 2. You cannot compare the number of APIs to Servlet because that is a dependency. You will have to calculate your total weight as Servlets+Web4J, i.e. 82+92 = 174. Yeap, that is your total weight in runtime. 3. You are talking pet store application. I am working on applications involving more than 40 people and 8 modules. So I need at least 8 config files. Now, tell me how Web4J eases out. Struts can do that. Web4J is good, but the fact is that the world does not need it in the form it is. All in all, it does not save my development time without me spending more time/resources on writing a fwk on top of this. So, I'd rather go with anything between XWork (or Struts 2) and Struts 1 (if nothing else suits, i.e.). There are many far between to choose from. And Web4J looks like another low level addition to it. The idea looks OK, but it's usability is not very high. Personal opinions:--- Also, it looks like a Pet Store kind of framework to me. It will scale well, but at what cost (people/time/...etc.)is the question.
  74. in my opinion, this framework is totally crap. And I have been reading so many awful things ... "WEB4J Forms Use Plain HTML" .. THAT'S FALSE !!! wicket can for example claim that, not web4j how can you call "" plain html ? so can we consider that also JSP+JSTL is plain HTML ? "no custom xmls ... The only XML file required by WEB4J is the deployment descriptor, web.xml" Are you joking ????? web.xml is a "DEPLOYMENT DESCRIPTOR" ! it is supposed to keep deployment configuration: there i want to put resource refs, not implementation details. and what is the point in not having a separate xml file but putting all the application stuff in deployment descriptor ? are we saving one file in the jar ? do you really think it is ok having HasAutoGeneratedKeys true Value : (true | false), ignores case. Indicates if the database and driver support the method Connection.prepareStatement(SqlText, Statement.RETURN_GENERATED_KEYS). in the web.xml file ? and the criticism to spring are pathetic: - "it has no clear focus": ahahahahahah, it is a framework, it must not have any focus; if it had any focus, it would be an application - "it is complex": well, if you think so, please go for another job. - "Spring has too many parallel mechanisms": and so ? use the one which is better suited for you - "its javadoc has over 2400 classes" and so ? the jdk has many more javadocs .. do not use the jdk then ! and so on ... too time lost to check this stuff
  75. Forms in plain HTML[ Go to top ]

    @Paolo Denti "WEB4J Forms Use Plain HTML .. THAT'S FALSE !!! wicket can for example claim that, not web4j how can you call '' plain html ?" Hi Paolo, thanks for your comment. My reaction: No, the form is plain HTML. The w:populate simply wraps the form. It doesn't alter it from its normal, bland, vanilla appearance, with the single exception of the form's action attribute. I stand by this technique for form population. To let people can judge for themselves, here is an example of such a form. The important point is that in web4j one's markup is minimally different from bland, boring, vanilla HTML. It's roughly similar to Wicket (interesting tool), which also takes a minimalist, non-invasive approach. - John
  76. Package by feature[ Go to top ]

    FYI - Like web4j, Wicket allows/encourages placing HTML files next to code. I like that... - John
  77. @Paolo Denti "Are you joking ????? web.xml is a "DEPLOYMENT DESCRIPTOR" ! it is supposed to keep deployment configuration: there i want to put resource refs, not implementation details. and what is the point in not having a separate xml file but putting all the application stuff in deployment descriptor ? are we saving one file in the jar ?" That's an interesting question. Here's how the servlet spec describes web.xml: "The deployment descriptor conveys the elements and configuration information of a Web application between Application Developers, Application Assemblers, and Deployers." And here is the list of items web4j apps place in web.xml. Is it reasonable to consider these items as config? I think so. They mostly deal with high level items: - logging levels - logging directories - email settings - limits on request sizes - default locale, time zone - and so on. I understand your objection to the item you mention. But is creating a second config file just for 2 or 3 settings really in the greater interest? Would it be consistent with a minimalist approach? Would most people want the extra file? My feeling is "no, just go with the web.xml". - John
  78. I took a quick look. web.xml has TONS of config stuff in it. No XML config? Yeah right. FAIL.
  79. Xml config[ Go to top ]

    As stated, web4j has no custom xml files. It does indeed use the web.xml deployment descriptor, however. Most tools have at least some configuration. This tool places its config in web.xml. There are about 30 such settings, that allow you to tune your deployment. Going through the list of settings, they seem reasonable to me. I think many would agree. - John
  80. Re: Xml config[ Go to top ]

    As stated, web4j has no custom xml files. It does indeed use the web.xml deployment descriptor, however.

    Most tools have at least some configuration. This tool places its config in web.xml. There are about 30 such settings, that allow you to tune your deployment.

    Going through the list of settings, they seem reasonable to me. I think many would agree.

    - John
    Maybe. But you have ranted on and on elsewhere about loads and loads of XML configuration in other frameworks so in that context the above becomes weasel words to me. Anyway I did look at WEb4J with an open mind. The points that are a no-go for me personally is that it is stuck in the JSP world along with JSP-EL, custom tags etc. and there is no support for Ajax. Another complaint: from your overview page you have this screaming headline "WEB4J Forms Use Plain HTML" but in the small print you find: WTF?
  81. Forms use plain HTML[ Go to top ]

    The w:populate tag simply wraps the form, as in : ..form goes here... ..no custom tags for form controls... The form itself is implemented in plain HTML. The point is that no custom input controls are used. See docs for more information. If you can find a tool that has a simpler method of populating forms with data, I would be pleasantly surprised. - John
  82. Re: Forms use plain HTML[ Go to top ]

    Okay, no custom input controls is indeed a good thing. Thanks for the responses, and appreciate your effort, it takes guts to release yet another web framework in Java - that too one that is *not* open source :)
    If you can find a tool that has a simpler method of populating forms with data, I would be pleasantly surprised.
    :)
  83. Re: Forms use plain HTML[ Go to top ]

    If you can find a tool that has a simpler method of populating forms with data, I would be pleasantly surprised.
    I mean I have found one and am happily using it but I'm not telling ya :P
  84. Aww, c'mon...fess up.... - John
  85. Re: Forms use plain HTML[ Go to top ]

    If you can find a tool that has a simpler method of populating forms with data, I would be pleasantly surprised.
    How about RSF? No additional tags, just one additional attribute.
  86. Hi John, I don't know if you'll be 'pleasantly surprised', but you may want to take a look at Metawidget (http://www.metawidget.org). It simplifies... ..form goes here... ..no custom tags for form controls... ...to... That is to say, it generates the form for you - and without using custom input controls either. If you get time to look at it, I would appreciate any feedback you may have. It may make a good companion for WEB4J. Regards, Richard.
  87. Xml Config[ Go to top ]

    Of the 30 or so config settings in web.xml, only about 5-6 are important when getting started. Most settings can be ignored most of the time, since they take reasonable default values. I think this is a reasonable approach. It wouldn't seem to be an unnecessary burden on the developer. - John
  88. The application should follow the user with it's presence at "Desktop browser", "Offline smart clients", "Mobile devices". This requires display ends just responsible for UI and server provides necessary information. Looking at the latest trend of "Flex + XML" , "AIR", "XSLT + XML" , "AJAX", "support of AJAX in even Windows Mobile 2003 onwards", clients are becoming powerful. Server just provides XML output for the request and screen builds the UI. This architecture helps on leveraging the power of desktops, less computational need at server front, easy on supporting new devices. Architecture for developing world
  89. The application should follow the user with it's presence at "Desktop browser", "Offline smart clients", "Mobile devices". This requires display ends just responsible for UI and server provides necessary information.

    Looking at the latest trend of "Flex + XML" , "AIR", "XSLT + XML" , "AJAX", "support of AJAX in even Windows Mobile 2003 onwards", clients are becoming powerful. Server just provides XML output for the request and screen builds the UI. This architecture helps on leveraging the power of desktops, less computational need at server front, easy on supporting new devices.

    Architecture for developing world
    Lets not overhype RIA. I get very frustrated with the hype in this industry and the additude of "For my last app I used xxx technology and yyyy approach and thus all applications should be built this way". As an industry why are we so closed minded and so lemming like? The world has need for both traditional web apps AND RIA. Look at google. Their search app is traditional and their mail client is RIA. Most apps of the future will probablly be mostly "traditional" with some AJAX mixed in. Can we all just agree to use the right tools for the right needs? Sure, RIA is "sexy", but just because a framework isnt RIA based doesnt mean it doesnt have any relevancy.
  90. Lets not overhype RIA.
    I agree. There's a lot to be said for simplicity in web pages.
  91. eh..[ Go to top ]

    Sorry but when my stakeholders insist on a slick, non-1990s looking UI, - the simplicity argument just doesn't turn them. RIA is a reality that we simply have to cater for nowadays, like it or lump it...
  92. You're right, it's not that "classic" web development, as I call it, isn't relevant... it still is. However, I think if you're objective about it you have to admit there is clearly a trend *away* from that. I have no problem with a framework catering to the non-RIA needs, none whatsoever. At the same time though, it's valid to look at any new development through the lens of what the trends are. You call it Lemming-like, but I view it as seeing an alternative that is, in my opinion anyway, clearly superior. A horse can still get the job done sometimes, it's still relevant in some cases, but I'll take my car most of the time, thank you very much :) I don't believe anyone is over-hyping RIAs, it's simply a question of a realization of what the trend is and an understanding that the trend is a trend for good reasons. I strongly disagree that "Most apps of the future will probablly be mostly 'traditional' with some AJAX mixed in". In fact, that's roughly where we are *today*. But, many people are starting to move beyond that. Some of us have frankly been beyond that for a few years: you can look at a few of the apps I did in the '98-'00 timeframe and I bet you'd think you were looking at something developed with the latest-and-greatest a week ago... and I'm not the only one that can say that! RIAs, more advanced that what we see today, are the future. That's not to the exclusion of non-RIAs, but it *does* minimize their importance. That's not an opinion, that's a demonstratable trend in the industry today. I would agree that we're not yet at the point where any of us should be closed-minded and say "I'm not going to develop anything but an RIA", but I *DO* think we are at the point where we should be asking the hard "What's the justification for NOT building an RIA?" questions. Over time, you'll find the justifications get harder and harder to find. You can call it hype if you wish, but it's not: it's simply the direction the industry in general is going.
  93. but I view it as seeing an alternative that is, in my opinion anyway, clearly superior. A horse can still get the job done sometimes, it's still relevant in some cases, but I'll take my car most of the time, thank you very much :)....I strongly disagree that "Most apps of the future will probablly be mostly 'traditional' with some AJAX mixed in".
    You have to look at the big pictrure. There are many types of web applications/websites. Most are like TSS.com where they are mostly involve managing content and presenting information. Even my bank's website is mostly about displaying data to me with a few simple transactional and data-input functions available. The more websites learn towards "content-based" in nature, the less RIA-like they need to be. My bank's website falls somewhere in between. A few RIA elements would make it incrementally better, but fundamentally there is nothing about the crys out for pur RIA. One the other hand, many business database-centric and workflow applications that have lots of input/output controls and these would bennifit more from RIA-style development. Even here, if it is simple enough you still might not need to go the RIA route. And finally becase of ADA requirements, some applications can not have and RIA. So the picture is way more nuanced and complex than you are presenting it.
    I don't believe anyone is over-hyping RIAs, it's simply a question of a realization of what the trend is and an understanding that the trend is a trend for good reasons.
    Man, this industry overhypes EVERYTHING. 4GL,Client/Server,Web-enbaled,Portals, XML/XSLT, J2EE, EJBS, SOAP, EIA, Spring, AJAX, Rails, BEPL, Web 2.0, SOA.....all these start off as solutions to a class of problems and then the marketing people get involved and proclaim, "XXX is the wave of the future and the solution to all your problems!". The excitement usually last for two years until it becomes obvious what was true all along: that its a good tool to implement a certain class of applications and not a universal panacea a must-have technology applications. So maybe just this once we can be sober as a community, and recognize RIA for what it is: A sensible evolution of browser based application technologies that will improve the usability for a particular class of applications.
  94. Same post, but in english:
    but I view it as seeing an alternative that is, in my opinion anyway, clearly superior. A horse can still get the job done sometimes, it's still relevant in some cases, but I'll take my car most of the time, thank you very much :)....I strongly disagree that "Most apps of the future will probablly be mostly 'traditional' with some AJAX mixed in".


    You have to look at the big pictrure. There are many types of web applications/websites. Most are like TSS.com where they are mostly involve managing content and presenting information. Even my bank's website is mostly about displaying data to me with a few simple transactional and data-input functions available. The more websites learn towards "content-based" in nature, the less RIA-like they need to be. My bank's website falls somewhere in between. A few RIA elements would make it incrementally better, but fundamentally there is nothing about it that cries out for pure RIA.

    One the other hand, many business database-centric and workflow applications that have lots of input/output controls and these would bennifit more from RIA-style development. Even here, if it is simple enough you still might not need to go the RIA route. Its always good to be simple when its an option

    And finally becase of ADA requirements, some applications can not have RIA because bling people cant use it.

    So the picture is way more nuanced and complex than you are presenting it.

    I don't believe anyone is over-hyping RIAs, it's simply a question of a realization of what the trend is and an understanding that the trend is a trend for good reasons.


    Man, this industry overhypes EVERYTHING. 4GL,Client/Server,Web-enbaled,Portals, XML/XSLT, J2EE, EJBS, SOAP, EIA, Spring, AJAX, Rails, BEPL, Web 2.0, dynamic languages, SOA.....all these start off as solutions to a class of problems and then the marketing people get involved and proclaim, "XXX is the wave of the future and the solution to all your problems!". The excitement usually last for two years until it becomes obvious what was true all along: that its a good tool to implement a certain class of applications and not a universal panacea ot must-have technology for all applications.

    So maybe just this once we can be sober as a community, and recognize RIA for what it is: A sensible evolution of browser based application technologies that will improve the usability for a particular class of applications.
  95. Man! finally somebody who speaks my language. EJB was the trend, so were Entity Beans, MDA, AOP, SOAP, XML... Each one of them was supposed to be the solution to all of our software problems. The truth is IT consulting companies small and big like IBM need an excuse to make their clients buy another one of their "next wave of the future technology" for an additional two hundred million dollars. The real trends are defined the the customers of the IT industry, not the industry itself. The customers are not demanding more slick interfaces of the RIA apps, but more reliable systems that are secure, consistent, easily adaptable to requirement changes and don't cost more the maintain than it does to create. If we solve these problems first, then our customers will probably be happier spending more money on slicker interfaces.
  96. Can we all just agree to use the right tools for the >right needs?
    Hear Hear!
  97. I love, Love, LOVE the idea of simplicity here... I could argue some of the specifics perhaps, but the underlying philosophy I'm in total agreement, and it looks like WEB4J succeeds pretty well in fulfilling that philosophy. I also happen to agree with a large portion of the criticisms of the other alternatives put forth. Not all of them, some seem a little spurious and debatable, but a large part of them I do think have some validity to them. Here's my one problem though... How does WEB4J help me build **MODERN** webapps? And if the answer is that it doesn't get in my way, that counts for something to be sure, but I don't think it's enough. And when I say "modern" webapps, I'm talking RIA's here. I can't remember the last time I wrote a webapp that had simple fillout forms that could map to simple domain objects, that didn't use AJAX and didn't have a fancy-pants UI that rivals a typical "fat-client" app. I've personally yet to see a better alternative to building this type of app than DWR, a minimal set of plain JSPs and a little Spring JDBC (straight SQL, but just with some of the JDBC details taken care of for me). It seems like WEB4J has some real good ideas, but I kind of get a similar feeling about it that I get about Struts these days: what's the point of the framework at all? I'm happy that WEB4J apparently won't outright get in my way, like Struts does, but if it's not really helping me do anything, why would I use it to build an RIA instead of just DWR (FYI, I'm a big fan of the DWR/single-JSP architecture I talk about here: www.zammetti.com/blog)
  98. You are right.[ Go to top ]

    You are right. This tool is *not* appropriate for Rich Internet Apps. - John
  99. Re: You are right.[ Go to top ]

    Oh. Err... umm... hrmph... here I thought I was going to be able to kick off a good argument :) HAHA. Thanks John, I appreciate your forthrightness (is that a word??)... I think it's great that your answer was as simple and straight-to-the-point as WEB4J itself :) Although... :) I'm not sure you're giving WEB4J quite enough credit in terms of RIAs actually! While it may not give you anything specifically in terms of RIA development, the simple fact that it doesn't get in your way actually makes it, IMO, a lot more desirable than many other options. I stand by my statement that if any given framework doesn't outright help you develop that kind of app then no framework is probably the right approach (I don't consider DWR a framework per se)... but on the other hand... if the framework isn't going to give you anything specifically in that regard than the least it can do is be simple, elegant and not be a burden, and maybe save you some time anyway simply by not being a burden and removing some grunt work. WEB4J seems to me to be very much on the right track in that regard, so while you say it isn't geared towards RIAs and doesn't help you build them specifically, I actually think it's simplicity could wind up lending itself well to that kind of development. Put it another way: I believe the best approach to RIAs is to find the thinnest possible layer between the client-side code and the server-side code... ideally just a plain old RPC mechanism (which is why I like DWR so much). Something as simple as WEB4J can actually I think be that, if you treat your URLs as simple remote procedure invocations, which seems pretty natural from the little bit I've looked at the examples. So maybe you should add a bullet somewhere on the site: "WEB4J helps you build RIAs by NOT trying to think for you, NOT trying to take care of every last detail for you, simply NOT getting in your way!"
  100. Hmm....[ Go to top ]

    You are right. This tool is *not* appropriate for Rich Internet Apps.

    - John
    I think that will really kill any chance of the framework gaining wide acceptance. Maybe you don't care :-| I'm currently supporting a medium sized application that our team wrote on Struts 1.x with a hybrid DAO & sql file pattern. While it's easy to use and develop on it runs into problems when you try to port it to other RDBMS's. It can be done but you end up maintaining multiple file sets which is why I really like the Cayenne ORM. Simple to learn and use and not anywhere near as complex as Hibernate. re: Spring - I've used Spring (and Spring MVC) for a couple of years now and really like it b/c your business objects and DAO's are much more portable than they typically are w/o an IOC container. I can live (happily) w/ a little XML if it makes the app more refactorable which I believe it does especially when your talking about swapping out complete layers (e.g. GUI). I also don't buy your argument that you need to know something about all of Spring to be effictive - that is simply not the case ... (I'm living proof) and you can strip out the unused jars in Spring if you wish. I salute your desire to make web apps easier build. I've felt your pain many times since I started building web apps in '97. But I think there is value in using industry standard frameworks (I use that term loosely I know) b/c alot of developers have experience w/ them and the learning curve to ramping one up on your project is much less. Food for thought.
  101. Re: Hmm...[ Go to top ]

    Re : "I think that will really kill any chance of the framework gaining wide acceptance. Maybe you don't care :-| " To be honest, it's likely more appropriate for WEB4J to go for "niche acceptance" instead of "wide acceptance", in the sense that for building apps in a simple, non-RIA style, then WEB4J would be the best tool for the job. To do one simple thing, and do it really well, is more attractive to me than trying to satisfy conflicting styles....
  102. WEB4J < GWT FAIL.
  103. Looks like an interesting framework. I could not find download for your (WEB4J) source code with a build.xml that creates all the jars and JavaDoc. Where I can download it? It is open source... right?
  104. No. This isn't an open source tool. (The tool is rather contrarian in many respects, and this is one of them.) - John
  105. No. This isn't an open source tool.

    (The tool is rather contrarian in many respects, and this is one of them.)

    - John
    I like this tool already.
  106. Not Open Source[ Go to top ]

    No. This isn't an open source tool.
    Wrong decision. From a business point of view.
  107. Re: Not Open Source[ Go to top ]

    Many would agree with you. But other than that, what do you think of the tool itself? Does it look interesting? Does it seem compelling in any way? - John
  108. Re: Not Open Source[ Go to top ]

    But other than that, what do you think of the tool itself? Does it look interesting? Does it seem compelling in any way?
    Overall I am sympathetic to your "philosophy of deep simplicity and minimalism" which counters the ubiquitous bloat in popular Java frameworks. I am not entirely convinced by some of your design decision, e.g. that all validation logic belongs to model objects (some validations need context) and that model objects should be immutable (conceptually, values should be immutable, not objects).
  109. Validations[ Go to top ]

    Ok. Interesting. I don't follow what you mean by 'some validations need context', however. Could you give a quick example? - John
  110. Re: Validations[ Go to top ]

    Could you give a quick example?
    Ok
    @param aPrice of the fish and chips meal (optional) $0.00..$100.00
    If you want the upper and lower limit flexible you need to provide that information from the outside, maybe by passing an appropriate Validator object to the Model in the constructor.
  111. No Dependence on Spring APIs[ Go to top ]

    @David McCoy - Re: "No dependence on Spring APIs". You are right. That paragraph wasn't a very good criticism. I have removed it from web4j.com. I think my other criticisms of Spring are valid, however, and they remain as is. Do you have any criticisms of web4j itself, perhaps? - John
  112. The fact that it's closed source makes me extremely weary of using it. When it comes to Java web frameworks, being open source almost seems like a convention. What if I use this and discover a bug a year later. You may not care enough about it to fix it at that time. Say something to put me at ease :P
  113. If you find a bug, I will fix it. And sooner rather than later. Bug fixes will always receive priority before any new features. I have worked on WEB4J steadily, since about 2002. It's not about to drop into oblivion any time soon. It's a quality tool, and believe me, I will care enough about it to fix the occasional bugs that arise. Bad customer service isn't in my interest. Receiving payment makes me deeply interested in making you happy. - John
  114. @David McCoy - Re: "No dependence on Spring APIs".

    You are right. That paragraph wasn't a very good criticism. I have removed it from web4j.com.

    I think my other criticisms of Spring are valid, however, and they remain as is.

    Do you have any criticisms of web4j itself, perhaps?

    - John
    It depends on how you are doing web dev, I guess. I hate html. It's boring and tedious. I like GWT, but had crafting a front-end with Java. That's tedious and error-prone, at least it was to me. And slow. However, GWT Designer helped me do the guis and after using GWT, I found it better, for me, than templating(html, jsf,etc). So the HTML portion, isn't a good fit for me. Also, I think web4j and Spring do two different things. That thread saftey issue...I don't know. That seems like less a Struts issue and more a servlet issue. I'm not sure I buy your cost. I orignally used Spring back in 05 to replace my custom factories. This was so easy, I also added Spring's transaction support, Hibernate support, and replaced my custom Dynamic proxies with Spring AOP. The last took 1 day. I don't buy your argument that web4j is cheaper considering you don't do DI, AOP, or declarative transactions. Also, I was able to standardized all our custom app XML and config files into Spring's XML format. I'll give it a deeper look. Usually, I check the philosophy of the tool, "Do I agree with their basic premise?" I did with things like Hibernate, Spring, Joda-time, that sort of thing, but I don't quite agree with your assessments. Just a difference in opinion, no more. :-)
  115. Fair enough, David :-) - John
  116. Well, I'm gonna come right out and blow Stripes ( http://stripesframework.org ) horn for those looking for an established, low impact, action framework. We have simple today. We've actually had it for quite some time. It's key difference vs WEB4J is that it's validation is done in the ActionBean, but not in the model. I appreciate the desire to push validation in to the model, but there are enough edge cases where it belongs in the action as well. Of course, there is nothing stopping someone from putting validation code within their model beans, and having a validation method that returns errors appropriate for the Stripes framework. Trivial, just a matter of taste. Stripes isn't "full stack", it has no persistence layer. I think for the 80-90% case of persistence, default mapping via JPA is painless, but you can do whatever you want (JDBC, iBatis, whatever). Stripes focuses solely on the client <-> HTTP <-> Logic relationship. Stripes relies on annotations, but to be really frank, almost none of my ActionBeans really have much of anything in terms of Stripes annotations (save @DefaultHandler, I think). What it annotates are things that are action specific, and tightly bound, so it's not like there's a big need to have the configuration details specified via annotations externalized for tweaking by some mythical "application-deployer-who-is-not-the-developer". It leverages custom tags for form elements, but doesn't require them. If you want to use pure HTML for you forms, knock yourself out. The Stripes form tags work particularly hand in hand with validation, and offer some nice functionality (notably presentation artifacts). Stripes also integrates seamlessly with JSP, especially with EL. Stripes, in essence, shines brightest on the binding of requests to the action bean and internal model beans. This is painless. If you can type a JSP-EL expression, you can bind in Stripes. It's obvious, "does the right thing" (like Date are Dates, Numbers are Numbers, building up your object graph as you go, etc.), and provides an exemplary "Out Of The Box" experience. If your framework can't handle this, for free, out of the box, zero config, you're doing far too much work: (Yes, the dateValue property is a java.util.Date, thank you Tim Fennell) This make Stripes a perfect companion for Ajax applications. Since it's basically a powerful HTTP request binding processor, it'll eat most any kind of request your Ajax object can throw at it. It focuses on standard multipart requests, vs deconstructing and automagically binding XML or JSON payloads, but that suits the 80-90% crowd today handily. If you want to work more natively with XML or JSON for input, it could be done (since Stripes guts are all exposed like a Frog in biology -- stich in an extra kidney if you like), but it's a little work. It'll happily spit back JSON and XML, of course. You get all this and good documentation in one core jar plus two utility jars (commons-logging, and cos.jar for file uploads). You get all this with 30 lines of XML in the web.xml, configuring a single filter and servlet, which can be cut-and-pasted from the example with no change, and 3 property files (2 of which are for commons-logging and log4j). I've never changed the default Stripes properties file, but I don't do a lot of I18N. With 1.5 (Real Soon Now -- Download the beta!), we get pretty URLs for more REST/SEO friendly web services, as well as other yummy internal infrastructure stuff I won't use. When EJB 3.1 launches later this year with EJB Lite, we're going to be able to create a web app with a web.xml (boiler plate, copy and pasted), a small persistence.xml (boiler plate, copy and pasted with perhaps a name change), the minimal Stripes jars, your Stripes Action Bean Classes (with one required annotation, implementing a trivial interface), some model classes, some entity classes (again, with one required annotation -- these will likely be your model classes) and a Session Bean class (with one annotation). With that you get painless HTTP binding, a smart action framework, transaction management (for "free", no config, no filters, no manual demarcation) and ORM with JPA. All bundled in to a trivial WAR file. No deployment descriptors, no XML hell, just a few simple annotations. You'll need an EJB 3.1 EJB Lite capable container, GFv3 out the gate, but I can guarantee that the OpenEJB and other folks will have Tomcat bundles that will do all of this and eat these WARs out of the box forthwith as the spec stabilizes. Is that more complicated than a PHP page pumping SQL in to MySQL? Yes, it is. But you can do that today with JSP if you want. For many, specifically in the Java camp, PHP is TOO simple, too minimalistic. We can do that, we choose not to. What this gives you is a spectacularly powerful and capable platform with no BS crap standing in your way to get stuff done, yet all sorts of flexibility, extensibility, and configuration tweaking if you need it. You won't be backed in to a corner. This platform will take you a LONG way, which means a simple start that doesn't have to be abandoned later. When you run out of paint, you won't find yourself in a corner. It also comes, save for adding Stripes, configured and working out of the box. Those folks who built and packaged the server did all the work for you. Add a JDBC driver, configure a DB pool, and the minimal Stripes stuff within your WAR and you're on a freakin rocket. And, of course, this is all free, and OSS for those who like that as well. I'm sure WEB4J makes things "simple", but my point is that it's already simple. We're already at that point. The nittiest part right now, IMHO, is the transaction details which folks manage with a Filter, or perhaps using Spring, etc. By end of year, that will be history, and that last piece of the puzzle shows up making the entire whole just horribly capable, yet easy to get out at the gate. And, mind, there's no tooling involved here. No IDE needed, no guis and crap. VI and Ant will handle the need handily. POJOs, some annotations, a couple of XML files that'll you'll steal from a web page and never look at again. Combine this kind of backing infrastructure with the "Browser as PowerBuilder for the new millenium" meme playing with nothing but whizzy JavaScript components and Ajax artifacts flying back and forth to the HTTP tier. The Stripes and EJB 3.1 EJB Lite profile combination I think are really a perfect storm for Java Web Development, both conventional and Ajax. Spring might be able to offer something close to what EJB Lite is going to offer, I just don't know how trivial it is to configure, and you need to do some configuration stuff with Stripes to work with Spring (it works, I think it's another annotation, I'm just not familiar with it). While Spring is certainly capable, I don't think it's quite there yet on "out of the box" simplicity that EJB Lite + Stripes will be. It would not surprise me to see Spring infrastructure that you can readily plug in to a servlet container and then deploy an EJB Lite WAR as is. Pretty sure their new app frame work will support it at a minimum. It's not a component system, ala Wicket, JSF, etc. But if you're using JS components, that's kind of moot anyway. The rise of JS Rich applications are making the component frameworks kind of a transitional technology, IMHO. Stripes is simple. The modern JPA ORMs, for many cases, are simple. It's straightforward to write a generic DAO using JPA. Transaction management is mostly formalized, with a lot of Best Practices on how to do it. EJB Lite will "fix" that for most use cases by offering a solid "out of the box" solution, but today users can adopt a common idiom and cut and paste their way to glory. The practical effect is slowing down project start up the first time, the concepts are straightforward. With these current, off the shelf technologies, we get a "simple as possible, but no simpler" solution that doesn't hamstring the developers looking out across the field. IMHO, the heavy lifting of the simplicity is done by Stripes, with JPA offering great support, but it's not required (many folks are quite happy with solutions like iBatis, using SQL -- Stripes doesn't care). Stripes is the shy kid in the corner. It is simple, without being minimalistic. It can appear that way (and I use it that way), but others make it dance and sing songs. In truth that kid in the corners real name is Clark Kent, so be careful of what you may find behind the glasses.
  117. Biggest plug so far :)[ Go to top ]

    This is really probably the biggest framework plug (or a hijack) that I've seen so far on TSS :) Some guts... Nikita Ivanov. GridGain Systems.
  118. So maybe just this once we can be sober as a community, and recognize RIA for what it is: A sensible evolution of browser based application technologies that will improve the usability for a particular class of applications.
    Well said. First I attribute the multitude of frameworks for the lack of tools' support in Java world for UI, I still remember the first time I had to code a JSP page with Struts and realized this is not my cup of tea. Coming to RIA I see the real leverage on the server, not the client. It makes a stateless architecture possible pushing the UI responsibility completely onto the client. This gives near linear scalability and with clustering taken care of on the client there is no SPOF on the server. Proof is in our product in production. Details are at http://sunilabinash.vox.com/library/post/is-flex-yet-another-mvc-framework.html Sunil & Abinash
  119. I think this kind of framework is a great idea. Keep it simple. I especially agree with his many criticisms of ORM. Why do they keep inventing these bastard query languages that typically have a lifespan of a few years? (i.e. toplink query api, jdo, hql, ejb-ql, jpa-ql, etc.) It is my experience that in most development shops NOBODY truly understands ORM. The DBA's hate it because they can't fix the queries. Managers hate it because it's complicated. Developers hate it because it adds significant time to application development. Network folks hate it because you have to add in all of this extra network infrastructure and configuration to enable cache synchronization, etc. I've seen my fair share of ORM apps that failed and had to be re-written in SQL stored procedures because of reasons like those. My only complaint is that it is not open source. That alone is enough to stop most Java folks from using it. Mike
  120. "prototype scoping Refers to single-use objects. This name is bizarre." - I suggest you go and buy a book on object oriented design patterns, you might learn what a "prototype" is then. Thankfully, the spring folks have actually read said books. You could purchase the "Design Patterns for Dummies" book, - I see from the index that it explains what a prototype is. http://www.amazon.com/Design-Patterns-Dummies-Computer-Tech/dp/0471798541/ref=sr_1_2?ie=UTF8&s=books&qid=1210843412&sr=8-2
  121. Sorry, but I fail to see how this framework brings anything new to the table. It seems to be yet another implementation of that dreaded web mvc/ model 2 pattern, and from a quick glance, the example code looks quite horrible to me (manually passing request parameters etc). I think minimalist can be read as lacking abstraction here.
  122. Minimalistic I think unfortunality means simplistic in this case. Fair enough, its a good objective to produce as simple as possible a framework. However, I can't see how this would have any chance of scaling in terms of managing complexity. I think generally, we have to put the model 2 frameworks behind us; component based is definitely the way forward for the webapps of today. Unfortunately it is taking a long time for "the" component framework to win through and become a defacto standard, - similar to Spring in the application framework space or Struts (in the past).
  123. I think generally, we have to put the model 2 frameworks behind us; component based is definitely the way forward for the webapps of today.
    Says who? Certainly the majority of web development is still being done using action-based frameworks. What is your basis for making such a strong proclomation?
  124. A personal opinion of course...sorry if I came across as overly dogmatic. I am speaking with the particular focus of RIAs here. Obviously it is very possible to build rich applications with say spring MVC and jQuery, scriptaculous etc. However, MVC appeared a number of years ago with "webpage" development in mind. ie. The focus is on "requests" and "pages". If we intend to build slick pages easily(and I think that is the "general" objective), the component based model is much more natural IMO. ie. Generally thick client frameworks (be it Swing, Qt etc. etc.) have gone down the component route. I think its generally something that is well represented with good OO principals. Also, this is one of the major reason why ASP.net etc. is giving java a good trouncing (in terms of take up) in this space. Component frameworks lend themselves well to gui builders etc. ie. Components that encapsulate behaviour and data can literally be drag/dropped from palettes. While I don't go for builders myself, they are attractive to many out there. Regardless, we need to get on the back of a framework that has a good selection of out of the box widgets. They are emerging in java world, and many seem technically far superior to the MSFT offerings, - its just that mindshare is needed.
  125. I think generally, we have to put the model 2 frameworks behind us; component based is definitely the way forward for the webapps of today.


    Says who? Certainly the majority of web development is still being done using action-based frameworks. What is your basis for making such a strong proclomation?
    I think Struts 1 is still the most widely used Java framework today, but that hardly makes it a great framework. My take on things is put down in the first chapter of Wicket In Action, which you can download for free.
  126. I think generally, we have to put the model 2 frameworks behind us; component based is definitely the way forward for the webapps of today.


    Says who? Certainly the majority of web development is still being done using action-based frameworks. What is your basis for making such a strong proclomation?


    I think Struts 1 is still the most widely used Java framework today, but that hardly makes it a great framework. My take on things is put down in the first chapter of Wicket In Action, which you can download for free.
    I am not avocating for Struts, Ive never liked it. But the statement that "model 2 frameworks are behind us" isnt factually accurate. For one, plenty of new projects are being started with Struts (unfortunatly), and two, not everyone would agree that a component approach is always better than an action approach. Personally I think the world has room for both action and component based approaches.
  127. But the statement that "model 2 frameworks are behind us" isnt factually accurate.
    True. Though I think he meant to say that we should leave them behind us, not that we already did.
    not everyone would agree that a component approach is always better than an action approach.

    Personally I think the world has room for both action and component based approaches.
    Obviously, people have a right to stick to their own suboptimal choices ;-). Personally, I see no reason at all for choosing any model 2 framework. Component oriented frameworks, whether they run on the client like GWT does, or follow a mixed model, like Wicket, Tapestry, and JSF do, give you better abstractions (you'll think about widgets, like panels, forms, lists, etc rather than pages and flows between them), more means for scaling complexity (working with self contained components, which makes it easier to refactor, avoid code duplication and partition work) and provide a cleaner programming model (where you focus on objects/ widgets instead of request parameters, and where you don't have to come up with hacks whenever you try to implement something more complex like nested tabs or pageable lists). Of course, there can be plenty of things people don't like about specific implementations of component oriented frameworks (I don't like them all myself), but it is a good starting point. The unfortunate thing about model 2 still being around in my mind is that it makes the case for ASP.NET (which is component oriented) stronger. Plenty of developers 'switched' because they thought web app development with Java is just too painful and that they are more productive with ASP.NET. Well, if you're using Struts, that certainly is true in my experience. With EJB 2 at least the Java community realized it wasn't the way to go and adopted alternatives like Spring, Hibernate, iBatis, etc. I wish the community as a whole would make a similar switch to component oriented frameworks. Though there has been a dramatic increase in the adoption of such frameworks the last 2 years, we're not there yet.
  128. I see no reason at all for choosing any model 2 framework. Component oriented frameworks, whether they run on the client like GWT does, or follow a mixed model, like Wicket, Tapestry, and JSF do, give you better abstractions (you'll think about widgets, like panels, forms, lists, etc rather than pages and flows between them),
    I think you are looking at web development from a fairly narrow perspective. There are many use cases in web development where the page the user is using is not focused on UI elements. In those situations, an abstracted widgit paradigm doesnt fit very well. For example, a site like tss.com, yahoo.com or amazon.com is mostly about presenting information in an orangized manner, not about manipulating alot of page controls. In my subjective opinion, I prefer an action approach in those senerios. of coarse, one could argue that Java has never had a great solution towards this end, but again thats subjective. By contrast if a page is a buisness type application with lots of input and output controls, then a component based approach is usually (but not always) the cleaner solution. Sweeping generalizations are generally not very helpful or accurate.
  129. There are many use cases in web development where the page the user is using is not focused on UI elements. In those situations, an abstracted widgit paradigm doesnt fit very well. For example, a site like tss.com, yahoo.com or amazon.com is mostly about presenting information in an orangized manner, not about manipulating alot of page controls.
    I agree that there are document oriented sites that have little benefit from using component oriented frameworks. Though personally I believe that model 1 (JSP + beans for instance) might even be a better idea in that case (because it is simpler/ less distraction). But I would actually still use a component oriented framework for a site like TSS (and certainly for Amazon), just because I would be able to scale up in complexity if the need would arise, and because even if the page is simple like TSS's, I still prefer to think in widgets rather than actions and request parameters.
    Sweeping generalizations are generally not very helpful or accurate.
    Yeah, YMMV and stuff.
  130. Though personally I believe that model 1 (JSP + beans for instance) might even be a better idea in that case (because it is simpler/ less distraction)
    I cant beleive you admited that in public! ;) Just kidding.
    But I would actually still use a component oriented framework for a site like TSS (and certainly for Amazon), just because I would be able to scale up in complexity if the need would arise, and because even if the page is simple like TSS's,
    Im not sure the variable that seperates storefronts and content management systems from business producticity systems is complexity. I think the differeces are in usage patterns and resultant data organization.
    I still prefer to think in widgets rather than actions and request parameters
    I think this is what it comes down to often. When you are talking about things like what search algorithm to use, the arguments can usually be substantiated with objective data. But often with tools and languages, personal preferences and comfort level come much more into play.
    Yeah, YMMV and stuff.
    Hammers...nails :)
  131. I did qualify my earler post by articulating that component frameworks are better suited for RIAs. If you're still building 1990s looking sites, then using a older style framework like mvc might make sense ;) As I say, increasingly stakeholders have the expectation that they want snazzier looking websites and we need to cater for them. http://www.theserverside.com/news/thread.tss?thread_id=49372#252669 I agree to some extent that mvc frameworks "may" have a value proposition for content oriented or document oriented sites. To be honest, I still think they can benefit from a component oriented approach. However, even such sites are becoming rich in this day and age. eg. dynamic tagging, and updating of navigations, dynamic controls, ajax list views etc. eg. Have a look at http://reader.google.com So, I think if you want to build a cutting edge content or document oriented site, you would be well served to take a good look at the component framework offerings. Also, there is no reason why you can't have a reusable "freemarker" or "velocity" component within say Wicket or Echo2/3 and gain benefits thereof. (As a sidenote, - would be interested to hear from anyone if it would be possible integrate say a freemarker/velocity "component" with GWT, or how you might go about doing this ?? ) If you don't need such a rich UI, or don't aspire towards it, then fair enough, - but we're talking about a framework for the future here, and a framework for the future needs to cleanly, manageably support rich UIs, which MVC doesn't. Personally, I've only recently started looking closely at the component framework offerings (I'm currently doing a web framework evaluation). I have been using MVC for many years. Yes, I could pretty much achieve any requirement my stakeholders throw at me with MVC. However, when all you have is a hammer everything looks like a nail. I am now beginning to get convinced of the benefits of the component approach, and am looking forward to putting it to the test in real life projects.
  132. Re: Passing parameters[ Go to top ]

    @Eelco Hellenius "from a quick glance, the example code looks quite horrible to me (manually passing request parameters etc)." Be more specific. Why is this action class horrible, for instance? The request parameter fields have a double purpose: - security: they establish the valid, acceptable request parameter names (and sometimes values). Any request with an unknown name is automatically rejected as a likely hack request, or a bad bug. - rapidly building a Model Object out of the request, as in the example : ModelFromRequest builder = new ModelFromRequest(getRequestParser()); fResto = builder.build(Resto.class, RESTO_ID, NAME, LOCATION, PRICE, COMMENT); The level of abstraction here seems reasonable. It builds a Model Object in two lines. You aren't dealing with raw underlying request parameters at all. It's not low level. No parsing of String into Integer or BigDecimal, for instance. - John
  133. Re: Passing parameters[ Go to top ]

    Why is this action class horrible, for instance?
    Totally procedural.
    The request parameter fields have a double purpose:
    - security: they establish the valid, acceptable request parameter names (and sometimes values). Any request with an unknown name is automatically rejected as a likely hack request, or a bad bug.
    - rapidly building a Model Object out of the request, as in the example :

    ModelFromRequest builder = new ModelFromRequest(getRequestParser());
    fResto = builder.build(Resto.class, RESTO_ID, NAME, LOCATION, PRICE, COMMENT);

    The level of abstraction here seems reasonable. It builds a Model Object in two lines. You aren't dealing with raw underlying request parameters at all. It's not low level. No parsing of String into Integer or BigDecimal, for instance.

    - John
    It's trivial to write a similar utility class for any old web mvc framework out there. It's not the kind of abstraction that helps you structure the problem(s) at hand better. And it's just tweaking a programming model that isn't great to start with. Anyway, my 2c, different opinions exist. I don't agree with your rejection of ORM either; though I've had my own share of problems with such frameworks, I think the idea behind it is viable and courageous.
  134. Re: Passing parameters[ Go to top ]

    @Eelco Hellenius "Totally procedural." Please explain further. "It's trivial to write a similar utility class for any old web mvc framework out there." Well, you don't have to write such a utility class in web4j. - John
  135. Re: Passing parameters[ Go to top ]

    @Eelco Hellenius
    "Totally procedural."

    Please explain further.
    That's just it, the code looks very procedural.
  136. Re: Passing parameters[ Go to top ]

    @"It's trivial to write a similar utility class for any old web mvc framework out there."

    Well, you don't have to write such a utility class in web4j.

    - John
    Right, I guess that's great then for people who'd like to avoid writing that themselves (or for those who simply didn't think of it).