component based web frameworks still not a proven concept

Discussions

News: component based web frameworks still not a proven concept

  1. I'm trying to analyze how request based frameworks can be designed to be better than any component based web frameworks : http://javawebframeworks.blogspot.com/2009/08/pssservlet-mimics-component-oriented.html Following is a prototype code snippet: http://javawebframeworks.blogspot.com/2009/08/pssservlet-codebase.html Most people seems to agree you waste lot of time in coding component based framework, while simpler solutions can be achieved by extending servlets. [Editor: What do you think?]

    Threaded Messages (27)

  2. Component oriented frameworks have "too much impact" and "too much magic"? I suggest you back up with examples, or you could be accused of not understanding the frameworks you are talking about. Does Rails have too much magic? "This will create big problem if similar userId is generated across pages and some javascript submits requests across pages. Javascripting becomes a nightmare." It sounds like you are trying to do things the hard way instead of letting the framework help you. "There is a need to synchronize javascript events with server component event." Calling the server from javascript is easy in wicket, don't know about other frameworks. "complete access to HTTP Servlet request" Certainly available in wicket (but rarely needed), don't know about other frameworks. "end user has to know internals of these component based frameworks like tapestry, wicket, JSF very well before using any of these frameworks" The end user must understand the architecture of any framework they are using, same as with any 3rd party library, but not the internals...
  3. At this point, I think building a web framework is just a rite of passage for Java developers. I know I've done it. Is that just because none of the existing frameworks are good enough, or because Java developers have more time on their hands than Ruby developers?
  4. I've really tried to take it seriously. But I failed. Looks like a student who came across Java about 5 weeks ago and wrote his homework for 3rd class
  5. Have you looked at SCA, Apache Tuscany
  6. In the Java world there are many technological perspectives that have their strong points, whereas none of them could be considered as best for all cases. One perspective that would serve well is the concentration on what business solution we are trying to build first, and then worry about the framework that could deliver this solution. One way available to achieve this, is by capturing the specification with dWebSpec. Once the requirement is captured, one could then evaluate how it translates to various platforms using a dictionary. The problem domain should direct the decision of platform to use. First, there are some features that are difficult to achieve on some platforms. For instance if you want a lot of client side validations and scripting; this could be for many reasons, including removing some activities from the server to the client. You would simply find out that some component based architectures are not client scripting friendly. If your application is page oriented, with user interaction events and post back, you would discover that this requires a lot of work on request/response or non-component based platform. Whereas, this is the main stay of the component based frameworks. There is also a vast difference between the response times attainable, for components versus character stream based. The latter simply renders HTML syntax, whereas components involve keeping view state, component hierarchy. These differences could further be influenced by the choice of stateless or stateful backing objects (beans). The conclusion is that, rather than counting one or the other out, as “not proven concept”, the concentration should be on the business objectives and what platform would deliver it.
  7. Click framework[ Go to top ]

    The proposed solution very much resembles me click framework http://incubator.apache.org/click/
  8. I really hesitated to reply to this article, after thinking about it, I thought It will benefit everyone . I think Component based framework are well proven and they are not only in Java. The concept in itself is well adopted both in Java World and .Net. However, the author showed that he does not understand what it is and I strongly recommend to him to learn it.
  9. Studying source code of component frameworks is always tedious effort and each framework offers a huge set of features. Do I need all these fetures that component based frameworks offer?
  10. Studying source code of component frameworks is always tedious effort and each framework offers a huge set of features.

    Do I need all these fetures that component based frameworks offer?
    You may not need all these features, but you could definitely use some language training. There is this language called English you know, and it uses things like articles. Try using these a little more... they're really handy!
  11. Your argument isn't a proven concept. Having actually been involved with putting apps (B2B & B2C) based on a component framework (Wicket) into production, I have to disagree. Your vapid argument doesn't convince me otherwise. Not only that, these projects were far more enjoyable experiences than the controller based frameworks I've used (Struts & Spring MVC).
  12. [Editor: What do you think?]
    While his(?) framework maybe valid for the type of systems he builds, his arguments against component based ones are not as others have said.
  13. http://www.ibm.com/developerworks/websphere/library/bestpractices/do_not_implement_single_thread_model_in_servlets.html
  14. The type of framework to chose depends on the 'Business problem to solve' and some times its kind of mix and match. I dont think we can weigh a particular framework better than other(in addition to their own trade offs). In some scenarios, request handling oriented framework does better, in some cases component oriented and it depends on many factors like time to market, standards based or not, skillset available, technology risks, content driven/logic driven and other factors.
  15. Dear how many component based web frameworks you look at before writing this useless article. TheServerSide seems run out of good material to publish. Just for anyone coming to read this kiddy stuff, please have a look at JSF, WebObjects, Tapestry and Wicket first.
  16. Maybe[ Go to top ]

    I had trouble reading the article because it's not very well written, but I'm also in favor of keeping things simple, which I think is what the author is promoting. I'm not a fan of big architectures because for the most part, they aren't needed. Having recently done some .NET development, I really do not like how I have to spend a lot time coding with, around, and behind the architecture. The pages are bloated and they feel bloated to the users. There are just so many pieces to learn and understand that really have nothing to do with just getting some HTML to a browser. I've managed to avoid most of the Java architectures and stuck with just basic Servlets and JSP's. Consequently, development is routinely quick, reliable, and maintainable.
  17. Re: Maybe[ Go to top ]

    Consequently, development is routinely quick, reliable, and maintainable
    If two out of three "ain't bad", what is one out of three?
  18. Re: Maybe[ Go to top ]

    . I've managed to avoid most of the Java architectures and stuck with just basic Servlets and JSP's
    Maybe i shouldn't post in the "mood" i am in but i hope i never have to maintain your code. I have had to maintain code "like" yours. Why do you think people develop things like GWT and Echo and Wicket and ...? Cause they have tons of free time and money? No. Because building and maintaining [complex] applications with just JSPs and Servlets is a PITA.
  19. Probably[ Go to top ]

    You probably shouldn't maintain my code. Good design is difficult to do, but very easy to screw up. I find developing with Servlets and jsp as easy but apparently difficult for you. I don't know or care why people build these things. I just don't need them or have ever needed them. You obviously do because it's too difficult for you to code without them. I find for many people it's merely a crutch for bad design, but having never met you or seen your code, that would a pretty presumptuous judgement to make, right?
  20. Re: Probably[ Go to top ]

    Presumptuous indeed. I have found few frameworks that provide value in web application development and in fact wrote my own web framework and rich component JavaScript library in 2002 (when JavaScript wasn't cool). Do you use Hibernate, JPA, or Spring or did you roll your own solutions in that space too? Following your logic why use Servlets or JSP's when you can write your own solution?
  21. Re: Probably[ Go to top ]

    I missed your "Good to hear" message implying that you do write your own ORM, DI, AOP, etc.. solutions (or skip the concepts altogether). Just FYI I agree with you on most of your points but still hold out hope for a quality higher level web framework and believe that a few are emerging. There are very few frameworks that I incorporate into my applications and with the exception of Hibernate none of them are real trendy and likely to show up in a job posting. Unfortunately a lot of good frameworks grow exponentially complex to handle edge case requirements or in an attempt mask their inherent complexity.
  22. Re: Maybe[ Go to top ]

    I found your posting interesting, especially because of some of the points that you mentioned. For example "keeping things simple", not having to "to spend a lot time coding with, around, and behind the architecture", pages are "bloated and they feel bloated to the users", and you went on. I am with you on all those points. The only difference is that I go along with the program, because it is the fad, and one might almost look like an illiterate if one does not speak the Java world language. For example I had concern about the complexity of EJB 2.1 and the way it addressed data as entities, despite that I still did the EJB (Business Component) certification. Thereafter most programmers balked at the technology and went for light weight container, IOC, and no application server. On the Component Architecture fad, I am going for the ride. They, especially Seams, appear complete, and conceptually appealing. But in the back of my mind, I know that some of the issues that you mentioned could also be true, including some that you did not mention, like performance. I am sure that your posting will not be received positively, but we should all probable do a Maybe ..
  23. Re: Maybe[ Go to top ]

    Sometimes our opinions are skewed by the technologies we are comfortable and/or familiar with. What I like about a well written component framework (Wicket is my framework of choice) is that it allows me to make use of OO Java. Request/response frameworks tend to encourage procedural programming where with Wicket I am able to build clean, reusable code that ultimately cuts development time down substantially. Almost any option works for small projects but I have been stuck maintaining more substantial applications with dynamic interfaces that have elegant code from the UI back but funky kludge on the front end. I sure hope component frameworks, both HTML and non-HTML (ala Flex, Curl, etc...) are the future of web programming. We could really benefit from an abstraction from the limitations of HTML/JavaScript and HTTP.
  24. Good to hear[ Go to top ]

    Fortunately for me, I've been given a lot of autonomy in my job because I have a proven track record of getting things done and creating quality applications. That means I don't have some guru imposing certain technologies upon me. Unfortunately, I'm finding in a lot of the job postings it's these architectures that people want. They are simple enough to pick up, but I've found them unnecessary and time consuming to master. I need to read some thick books and take these difficult certification classes just to learn the tools - whereas I was doing the job just fine before these tools and architectures were ever invented. It's just the old "accidental complexity" that Brooks mentioned years ago multiplying to an absurd degree lately. It started with EJB, then Struts, then Spring, and a slew of ORMs, and the big daddy of them all - .NET. and I'm sure something else down the line to make Spring easier or .NET easier - tools for tools. Anyway, that's the end of my rant.
  25. A component oriented way of developing your application means that instead of thinking in request/ response cycles you can think in widgets: panels, trees, form fields, etc. The point is that you can break up your problem in smaller and independent bits and pieces, and reuse those pieces in different contexts. I can't even begin to describe how those four classes utterly miss the point of the stuff web frameworks really try to solve. FWIW, besides using e.g. Wicket or GWT, I also consider a SOA approach (whether that's using web services, JSON interaction or something else) with an Ajax front end to be a component oriented approach when done right. What matters is that you can focus your attention on something finer grained than just a request/ response and a template.
  26. FWIW, besides using e.g. Wicket or GWT, I also consider a SOA approach (whether that's using web services, JSON interaction or something else) with an Ajax front end to be a component oriented approach when done right. What matters is that you can focus your attention on something finer grained than just a request/ response and a template.
    Thanks Eelco, besides SOA, is there XUL approach? GWT+XUL - there maybe no need to write HTML. not fully sure. rgds,
  27. Component orientation has been proven many many years ago in desktop and in web components shine when used with AJAX, in fact AJAX pushes component orientation in web to the desktop level.
    besides SOA, is there XUL approach? GWT+XUL - there maybe no need to write HTML. not fully sure.
    rgds,
    You can understand XUL as a richer HTML with more built-in components (visual controls). You can develop server-centric and client-centric applications using XUL, XUL does not impose a concrete strategy. Anyway a page based application based on XUL is technologically awful, XUL + AJAX is a powerful platform (server-centric or client-centric).
  28. ... simpler solutions can be achieved by extending servlets.
    Try http://www.hybridserverpages.com/, you will not regret. That IS a simple solution extending servlets. Here is how it compares to Wicket: http://www.theserverside.com/news/thread.tss?thread_id=54866#313158