Discussions

News: AppServer Faces - Writing Web applications without pages

  1. AppServer Faces attempts a really object-oriented, component-based, event-driven and intuitive approach to Web application development. Yes, this is another Web application framework. But it's very different from other approachs to Web application development. Based on some well-thought abstractions on Web application, we tried to make writing Web application easier and intuitive, even for a sophisticated application. Its main features include:

    1. It's an all Java solution, not relying on server side scripting or templating languages. A web application can be written like a normal Java application.

    2. It's not page-oriented. Its view layer is defined in plain old Java objects, not page files.

    3. Web application and its components are defined by two types of components: PageCom and MargeCom. PageCom components are view components, MargeCom components encapsulate the application logic implementations, and they use PageCom components as their views. Both types of component are plain old Java objects, and they separate the concerns of presentation and application logic.

    4. Markup language representations are hidden from programmers. From the view of a programmer, the UI of a web application is described by intuitive view components, and she doesn't care how the view components are transformed into HTML. A PageCom component knows how to transform itself into standard compliant (X)HTML representations.

    5. PageCom components can be dynamically applied CSS style objects, and the style rules are expressed in standard CSS syntax. This makes it possible to define rich styles for a view component by just invoking one single method like applyStyle(CSS style), instead of defining many methods like setFont(Font font), setColor(Color color), etc. The separate design of CSS style objects also separates the concerns of the view structure and the style applied to it. The framework can dynamically generate the CSS stylesheet for every HTTP request.

    6. A Web application is implemented based on other MargeCom components, and the views of these child components are like portlets to their parent component.

    7. Both types of components(MargeCom and PageCom) can be composite of other components, and this makes it easy to define custom components, and encourages a modular development.

    8. It's event-driven. The application logic responds to semantic specific events, not to the generic HTTP request;

    9. It already has many built in components.

    Please visit www.dataosoft.com for more information.

    We know there are already many Web application frameworks in this world, and JSF is out finally. We post this news here is not just announcing a product, but also want to exchange our design thought with other people. We think Web application architecture is still not a field no more challenges there. We hope hearing your comments.

    Threaded Messages (47)

  2. When I get a chance I'll download the eval.

    But till then - how does this differ/build on/better from Echo(+Echopoint), Millstone, and others(Commercial products that I don't offhand remember the names to) in the genre?
  3. Forgive me I can't comment on this because I'll be biased. I think the article has said what AppServer Faces is.

    Thank you.

    Bo Yuan
  4. Forgive me I can't comment on this because I'll be biased. I think the article has said what AppServer Faces is. Thank you.Bo Yuan
    Understand. I'll try to do an unbiased eval. But I still would like your comments and to know if you've looked at those other tools.
  5. It reminds me of ECS[ Go to top ]

    Am I the only that thinks of the good old ECS (element construction set) from jakarta?
    When I look at the tutorial on their webpage and just think that I have to write these endless lines of code to get a simple HTML page it would be a pain.
    These days you have nice tools like dreamweaver and many more that helps you writing HTML/JSP/Velocity/Freemarker.... pages.
    What is the advantage of this approach? Maybe there are developers out their bored with their life who want to spend more time in their cubicle.....

    All these "pure" java approaches have usually one in common: an butt ugly user interface that you cannot even make pretty with tons of CSS styles.
  6. It reminds me of ECS[ Go to top ]

    If it's just a method for you to write HTML representations with Java, it'll be not so useful. But it also defines component architecture and event-driven mechanism for you to write full functional Web applications like you write Swing applications. A MargeCom component with sophisticated interaction logic can be reused and embedded in your application. Even for the presentation layer, you can dynamically create, say, a grid layout and dynamically apply CSS to it, this in many cases(not all cases) will be more convenient than writing a html page file.

    Cheers

    Bo Yuan
  7. Please note AppServer Faces encourages a stateless architecture at server side. It doesn't save any instance of the application into HttpSession. I know those frameworks you mentioned, but I'm definitely not expert of them. AppServer Faces is still too young, and we'll learn a lot of from those mature frameworks.

    Cheers

    Bo Yuan
  8. Excellent Idea[ Go to top ]

    Stole my idea! Well, maybe. I was thinking of having a universal JSP or servlet to take care of all the UI tasks including ecapsulating all the various types of views. There are some varieties of parts to a view. An underlying data structure (ie: a table, list, empty hash/populated hash, master detail) etc. and then there is the rendering of that data into the visual representations that populate with that data or create forms that will take input for the data. I can imagine how this was done. I also support the JSF movement. It's a good idea. What can then come next is a way of using tools that are not bound to the web and you using standard componenets to build apps that you can render in a variety of ways and windowing toolkits.
  9. Excellent Idea[ Go to top ]

    Stole my idea! Well, maybe. I was thinking of having a universal JSP or servlet to take care of all the UI tasks including ecapsulating all the various types of views. There are some varieties of parts to a view. An underlying data structure (ie: a table, list, empty hash/populated hash, master detail) etc. and then there is the rendering of that data into the visual representations that populate with that data or create forms that will take input for the data. I can imagine how this was done. I also support the JSF movement. It's a good idea. What can then come next is a way of using tools that are not bound to the web and you using standard componenets to build apps that you can render in a variety of ways and windowing toolkits.
    One is able to do this with Echo. I'm able to develop in Swing or Echo and easily convert the app to the other one. Which is why a comparison is in order, especially since it is LGPL.
  10. 2. It's not page-oriented. Its view layer is defined in plain old Java objects, not page files.
    May be I misunderstood the model, but correct me if I'm wrong: you code the UI portion with POJO UI components that render HTML.

    Most shops have "web developers" and "application developers". Web developers are dedicated to UI design and layout formatting, and are proficient with graphics, DHTML, CSS, and some JavaScript. Application developers are dedicated to the middle tier(s) and back end data store, and are proficient in Java, XML, and DBs.

    Coding the UI part with POJO's, even if there are helper UI components, isn't such a good idea, and can't be productively used by web developers, who bascially don't have programming experience. This is why JSP was added to the pure servlets model.

    This might be useful for small-scale and personal web sites, but I doubt it'll take off for large commercial sites.
  11. 1.PageCom component can be designed with tools. A Web developer can work with a tool to design a view component, and her product is a Java class. The tool doesn't exist at the moment.

    2.A PageCom component represents certain view structure, it can be applied CSS style object. With AppServer Faces, the view structure and the styles applied to it can be designed separately. When the view structures(e.g, layout) of an application are chosen, a Web developer can work on style sheets, that doesn't require programming.

    3. It's too early to say if it can be used in large projects.

    cheers

    Bo Yuan
  12. 1.PageCom component can be designed with tools. A Web developer can work with a tool to design a view component, and her product is a Java class. The tool doesn't exist at the moment.
    We often hear this from "new framework" creators. It's an incurable optimism to suppose that vendors like Macromedia, Borland etc. would create a useful tool in order to handle all the presentation troubles for this framework.
    At the same time it's a mistake to believe that an open source project for GUI editing will be available soon (and it's quality/interface/documentation will be good enough for designers to work with it)

    Regards,
    Theodore
  13. <Peter Frost>Coding the UI part with POJO's, even if there are helper UI components, isn't such a good idea</Peter Frost>

    No, it is a great idea. Since POJOs allow inheritance, UI can be controlled by parameters in the super class. Many of the shops I have worked in have no developers who work exclusively on UI. So I've had to toil with JSPs because management has a vision that one day UI and app devleopers will work hand-in-hand on the same files. That day never comes and they are stuck with a bunch of hard to maintain JSPs.

    Writing Web applications without pages is a great idea. I use the Apache Element Construction Set (ECS). Very slick.
  14. This will never give you total control over the design and layout of your UI. In addition, developing a sophisticted layout using this approach is a BIG pain in the neck! May be a tool will alleviate this problem. But hey, this tool will effectively do same function as JSP pages, i.e., it will take that layout and convert it to Java code, and JSP pages take DHTML/CSS layouts and compile them to servelets. Then why bother?

    Web developers eat and breath DHTML, CSS, graphics design, and other layout stuff. They know every trick in the book, and outside the book. You as a Java developer shouldn't waste your time on learning the ins and outs of UI layout in DHTML and CSS. You better spend your time somewhere else. Do you want your graphics designer to mess with your Java code? Or do you want to train him/her on programming and Java? Most likely he'll quit the second day :)

    If your company can't afford dedicated graphics designers and web developers, then its web project is small or small-medium (or Intranet/Extranet project where you don't care much about layout), and this platform is fine for this kind of project, where you can throw in a quick and dirty UI layout.

    But if you have a big commercial website with sophisticated UI, this won't cut it.
  15. This tool, tools like it (Echo, ...), and tools like unto it (Tapestry) are for making applications that are deployed using the browser. NOT for making web pages or full blow web sites. The website can still be done like you describe (I've not worked a place that has web designers) and the application portion of it done with this technology but the look controlled by the web designers.
  16. We are not yet there.[ Go to top ]

    Most likely he'll quit the second day :)If your company can't afford dedicated graphics designers and web developers, then its web project is small or small-medium (or Intranet/Extranet project where you don't care much about layout), and this platform is fine for this kind of project, where you can throw in a quick and dirty UI layout.But if you have a big commercial website with sophisticated UI, this won't cut it.
    I've worked for both big companies and very small companies. Only one had a "web" developer who was actually a graphic designer and we had him for 3 weeks.

    Despite the dream of "only the web guy will do the front-end and the java guys will do the back" the reality is that this just isn't happening.

    It didn't happen during the boom and now, when we are either still in or just coming out of a recession, companies want their people doing as much as possible. I still have to do JSP pages. You can write them in such a way to welcome that far off day when only the web guys will write them, but we are not there.

    I don't know if this stuff is good or bad, but I'll personally look at anything to ease this task, even if it is just for ideas.
  17. I AGREE[ Go to top ]

    There is a BIG difference between HTML/web developers and J2EE/Java developers. You shouldn't force the Java developers to learn HTML, nor vice versa.
  18. Re: I AGREE[ Go to top ]

    You don't need to force a Java developer to learn HTML. With AppServer Faces a Java developer works on a view abstraction when s/he needs a view component, the HTML is hidden from her/him. The writer of the PageCom components may need to know HTML and CSS. But the PageCom component writer may not need to know HTML well because a PageCom component can be easily composite of other PageCom components. Of course in a project there must be someone who is good at HTML and CSS stuff. But the point is that because PageCom components can be separately designed, the concerns can be well separated between the writer of view components and the application developers.

    Cheers

    Bo Yuan
  19. ECS[ Go to top ]

    +1 to that.

    ECS is the most underrated tool in the whole of Java Web development.


    Best regards,

    Robert Lowe
    http://RMLowe.com/
  20. Concerns[ Go to top ]

    Seperation of concerns; the Java code should not know anything about the view, (HTML) in this case. In my opinion implementing the MVC pattern is the best solution offering, flexibility and control.
  21. Concerns[ Go to top ]

    One thing I think should be clarified: Java can do anything. A PageCom component(view component) can be implemented by any means, as long as it just exposes the necessary interfaces to its user--in this case the application developer. An application developer doesn't care how PageCom components render content(this of course is not always true). AppServer Faces happens to implement PageCom components as Java classes. Actually we are considering supporting templating langages within the implementation of PageCom components.
  22. Concerns[ Go to top ]

    <Jacob Briscoe>Seperation of concerns; the Java code should not know anything about the view, (HTML) in this case</Jacob Briscoe>

    Just because Java code is used to create the view does not mean the Model and the Controller need to know anything about it. An MVC architecture is as readily attainable with pure Java code.
  23. Concerns[ Go to top ]

    <Jacob Briscoe>Seperation of concerns; the Java code should not know anything about the view, (HTML) in this case</Jacob Briscoe>Just because Java code is used to create the view does not mean the Model and the Controller need to know anything about it. An MVC architecture is as readily attainable with pure Java code.
    Like Swing and SWT. I would say that MVC is better accomlished with Swing/SWT/AppServer Faces(and tools like it) that pure play web page dev.
  24. You mean I can create a complete web application with only the Java syntax? I don't need to learn a bunch of proprietary JSP tags or XSL commands?

    Good work Bo.
  25. Yes. You can create a complete web application with only Java. Because it supports dynamically applying CSS style objects to view components, you can create web applications with very rich styles as long as CSS is capable.

    Cheers

    Bo Yuan
  26. You mean I can create a complete web application with only the Java syntax? I don't need to learn a bunch of proprietary JSP tags or XSL commands? Good work Bo.
    Probably, but you will have to learn a bunch of proprietary APIs. You can't really escape learning new things.

    BTW, what is the problem with developers having to learn XSLT? XSLT 1.0 has been a standard for years.
  27. <grain_of_salt>I haven't looked at the actual product.</grain_of_salt>

    From the description, this doesn't sound much different than a lot of other component-oriented web user interface frameworks. And specifically, I don't see how this offers an advantage over JSF -- JSF components are POJOs, and its backing beans (which collect form values and respond to events) are POJOs as well. In addition, it's entirely possible to specify JSF views with pure Java code, without worrying about the generated markup (witness the Smile open source implementation [http://smile.sourceforge.net]). And, JSF uses an event-oriented approach as well.

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
  28. This is a framework to address programmer preferences (My pattern is better, I use intoceptor patter, etc...). I agree with Kito. The market is becoming too saturated with frameworks. What problem does this solve that other frameworks have not? I do not see any. There are tons of frameworks that hide the HTML from Java developers and vice versa.
  29. what is its advantage ...[ Go to top ]

    .. over mature open source frameworks like

    echo or wingS?

    Holger
  30. Javascript[ Go to top ]

    I have writting a similar hand rolled thing for making it easier to inherit UI elements and share code. The problem I have run into is how javascript interacts or is served from my libraries. How do you handle javascript in your framework?
  31. Javascript[ Go to top ]

    JavaScript is encapsulated in the implementation of PageCom components. Not all PageCom components need JavaScript. We are very careful when we add Javascript into PageCom components. One challenge is that a JavaScript function often needs to be uniquely identified within the current page, considering a child MargeCom component may use an arbitrary PageCom component in its view(or change its implementation). AppServer Faces provides a easy way to do this. It's the responsibility of a concrete PageCom component's implementation to make sure the JavaScript is correct and cross Browsers.
  32. Lumps in the pudding[ Go to top ]

    I see a couple of problems here guys. One is that you specify formatting through the objects (or at least you can). That's kind of a no-no in the java world, and I'd agree with that one.

    The other is that if you just use CSS styles for formatting, then you can run into browser issues since not all browsers support all CSS layout options.

    Funny too - I have some similar code components before I knew better. :)

    Nice try... is this projec open source?
  33. Lumps in the pudding[ Go to top ]

    AppServer Faces allows you set any Html attribute directly on the HTML implementation of a PageCom component. If you don't feel safe with CSS, you don't need to use it.

    Cheers

    Bo Yuan
  34. Awareness and Reinventing Wheels[ Go to top ]

    It boggles the mind that developers out there are doing the same thing over and over and over again. Bo, you seem really to really believe in your approach, and that is fine, but why oh why did you start from scratch? Did you even research the other frameworks that are out there? It sounds like yours really is exactly like numerous others. Did you look into contributing to those existing projects first before you started work on this framework?

    Back in the days when I started JPublish I based it largely on what I saw done with Turbine, Aquarium and a PHP framework all of which were based on one concept. I was young and foolish and felt that Turbine was not sufficient for what I was doing as was too entrenched in a long history. I wanted to start fresh but I didn't do it without first at least understanding what was already there. In the end I think I made the right choice especially since Jakarta now has three web frameworks and Turbine is really the oldest and least well known of the bunch.

    Regardless of whether or not I agree with your approach to web development (and for the record I do not) I do hope that you are aware of the other projects out there which are similar to yours and that you understand why you are choosing to reinvent the same wheel.

    Sincerely,
    Anthony Eden
  35. Eden,

    Why is it OK for you to "reinvent the same wheel" but Bo Yuang is foolish and should have known better?

    BTW, I was called in to fix a project that used JPublish. We tore that crap out and replaced it an elegant ECS based system. It's now much more performant and the code base is about 1/2 the size that it was.

    Keep up the good work Edie.
  36. Do you even know how to read? Perhaps you should go back and read my message, specifically the part where I said: "I was young and foolish". I never said Bo was being young and foolish. Anyone can reinvent any wheel they choose, they have every right. My point was that if you're going to do it you really ought to know why.

    As for your decision to use ECS over JPublish, there's not much I can say. JPublish is not a fit for every project. I have no idea what the scope of your project was or any other information on it for that matter since you choose to hide your identity and offer no information about what it is you've done or why you've done it, but whatever.
  37. Awareness and Reinventing Wheels[ Go to top ]

    Edie

    I would be interested to know what it is you deemed "crap" with jpublish.

    We are now on our third project using JPulbish, having previously used struts and webwork, and are very happy with it.

    It has proved easy to learn, quick to develop, performant (load testing and real user feedback) and - most important for the kind of work we do - very easy to make constant changes.
  38. Re: Awareness and Reinventing Wheels[ Go to top ]

    Hi Anthony Eden,

    How do you know we didn't look at other frameworks? What important wheels do you think are there in JPublish we have re-invented? As I said in the original news,"We post this news here is not just announcing a product, but also want to exchange our design thought with other people", what's wrong with this?

    Honestly speaking, we even don't count on many people will use this framework because there are already many mature ones(including yours) for them to choose. Exchanging information with other people is a pleasure for us.

    Best regards,

    Bo Yuan
  39. Re: Awareness and Reinventing Wheels[ Go to top ]

    Hi Anthony Eden,How do you know we didn't look at other frameworks?
    I don't know, that's why I asked. Did you?
    What important wheels do you think are there in JPublish we have re-invented?
    JPublish and your project approach the same problem very differently. I was not comparing them, on the contrary I was trying to make a point about awareness of the other projects around you.
    As I said in the original news,"We post this news here is not just announcing a product, but also want to exchange our design thought with other people", what's wrong with this?
    What's wrong with it is that you may be able to contribute to an existing project and make more of a difference than if you write something new. However this is all a moot point since you already have written something new.
    Honestly speaking, we even don't count on many people will use this framework because there are already many mature ones(including yours) for them to choose. Exchanging information with other people is a pleasure for us.

    Best regards,Bo Yuan
    Whatever makes you happy.

    Sincerely,
    Anthony Eden
  40. It reminds me ASP.NET[ Go to top ]

    I can find these features of AppServer Faces in ASP.NET, just like object-oriented, component-based, event-driven. I like this style of developing Web Application.
  41. Bad Marketing - Ugly Website[ Go to top ]

    Just a word of advice to the makers of AppServer Faces:

    Get a graphic designer to make your site (and especially your online demos) look professional. It doesn't matter how cool your technology is if it is producing a site that looks like it was designed from a Microsoft Frontpage template circa 1993.

    If I'm going to be persuaded to make a major shift in how our web-apps are created I need to be shown that your software can produce a client that is as slick and powerful (professional) as what can be done with current methods (Struts/Tiles, HTML, JSP, JavaScript, CSS etc..).

    Marketing 101: Fugly don't sell.
  42. Re: Bad Marketing - Ugly Website[ Go to top ]

    Thank you George Coller. You are right that's not a work cooperated with graphic designers. We still need to do much to improve our work. This also proves how important it is to separate concerns in a Web application. A good Web application framework should provide a platform for Web developers(including graphic designers) and application programmers working separately and even parallely. With AppServer Faces a Web developer can design the view layer by designing PageCom components. Within the implementation of a PageCom component, she can use CSS, JavaScript, or by directly setting (X)HTML attributes to control the look of the component, and she often does this by manipulating the other PageCom components used or added into the current PageCom component, defining and changing their styles and (X)HTML attributes settings. A Java programmer doesn't know how the PageCom components she used are laid out or styled, she just cares how to interface with them at the data binding and application logic layer. A PageCom component can freely change its implementation later as long as it doesn't break its public interface methods.

    Thank you very much.

    Bo Yuan
  43. Hi: Yuan. I am a great fan of not writing cryptic html or XML at presentation tier. It's like writing machine code instead of programming in a high level language. I echoed my opinion lot of times at TSS and really glad that there are people out there who are much more committed than me to make it happen. I appreciate people at dataosoft.com but don't understand how this framework goes hand in hand with JSF, because they seem to overlap each other or at least based on the same philosophy. Do Appserver faces have any advantages over JSF, if yes are there any plans to brought these advantages to JSF while datasoft concentrate more on the IDE or tools feature to use these frameworks? I bet there is a big market out there craving for some good IDE that can compete with VS.NET to develop web applications visually. If you ask my opinion this space is still open to grasp and could be very lucrative.
  44. ... I bet there is a big market out there craving for some good IDE that can compete with VS.NET to develop web applications visually. If you ask my opinion this space is still open to grasp and could be very lucrative.
    Having used VS.Net (in this case WebForms) and tools like AppServer Faces, I would say that AppServer Faces/Echo/Millstone/... are a step above WebForms. WebForms still deals with things with in a Page paradigm. Yes, it has a GUI builder but that is more a hindrance than a help (monolithic views, no knowledge how to do what you can't with the GUI, etc). It (probably) would be very difficult (lot more work) to do WebForms without a GUI tool. But these others are just like writing Swing/... and that really isn't that difficult.

    But I guess the point is that most 'developers' are programming challenged (ie they need 1 yrs experience 10 times). So unless they have a tool - they can't function. Or don't believe they can be productive without drag-and-drop. Personally, I think the middle ground is the best. But too many (including myself) use tools as crutches as opposed to enhancements. So to compare technologies that need tools vs technologies that don't isn't objective. Then again, maybe that is your point. They are great without a GUI tool. Just think what they would be with one.
  45. Hi Rashid,

    We love open standards like every Java programmer. We choose to publish our framework after JSF 1.0 came out and we waited so long time just because we thought JSF would be a standard and we really don't want to compete with a standard. But JSF is not what we want. People often say don't reinvent the same wheels. But I think we should also ask why nobody reinvents something like Servlet or Collections? If EJB is good enough, can we still see other similar frameworks?

    AppServer Faces sits on top of Servlet 2.2+, so it's standard compliant if you don't think competing with JSF is violating standards(I'm not sure if it can be called standard already).

    As you pointed out JSP(and JSF) has become more and more like cryptic files. The original intention to invent a tagged layer is said that the jobs of Web developers and Java developers can be separated. A good point in theory but in reality can you expect a Web developer without programming training could understand those complex tag library with subtle data binding logic? Can you teach them what EL is? If a Java programmer feels JSF pages like cryptic files, how a Web developer feels it? Actually an artistic Web developer never wants to hand write even a simple html page even if she knows how to do it. Their capability lies in their artistic intuition and judgement of what's good and bad. They need tools to help them complete those technical works. This poses a question: what's the point to express the views of a complex Web application with tagged page files? If a person who knows programming has to write presentation tier, why not give him a more powerful tool--in this case Java? The advocates of JSF say tools will help people to write JSF pages. If that's right, why not view components directly written with Java that are more easier to support by a tool? One funny thing is that about 8 years ago when Netscape was competing with IE, both of them invented some custom tags and all Web developers worried about that until HTML 4.0 was out. Today we see much more custom tags at server side. If JSF is implemented by different vendors, should we worry about this again?

    How to represent a view component is more a preference problem rather than an architecture one in many cases. A good framework should allow people to do it in different ways. We are considering to support template languages later in AppServer Faces. But Web applications have become more and more complex. In some cases we not only need to present dynamic data, but also dynamic layout, view structure and style. In other words we not only need arithmetic, sometimes we also need algebra at the presentation tier of a Web application. I think only something powerful like Java language can help us in these cases.

    Actually the representation of the view ties is just one small problem IMHO. The more important problems are how to implement application logic and how to easily integrate different Web components with full functional interaction logic into the same Web application. AppServer Faces achieves this by MargeCom components. You can divide your application into different modules, and each one can define its own view and implement its interaction logic with client, then you can nicely integrate them into a whole.

    As to what's the advantages over JSF, because this reply is too long I try to give a brief answer. Of course I'm biased and even wrong. If I have any misunderstanding of JSF, please correct me.

    I just want to point out some problems we found in JSF here. Except for the JSP and custom tag problems I mentioned above, one dubious design in JSF is that it treats a Web application as stateful. I mean the conversational state especially the so-called view state. Yes a view component sometimes has view states. But the question is if we need to track them at server side(session) or client side(this is a copy of ASP.NET). With AppServer Faces some components like menu also has view states, but they are only used by client computing. Only the states relevant to application logic should be tracked. But with JSF it seems it serializes the whole component graph, and this information is used by the framework to reconstitute the component tree. This makes Web applications heavy and is unnecessarily complex, and it also makes the "back button" a big problem. Contrary to the belief of some people, save view states at client side page scope actually can not solve the back button problem. Another problem with JSF is related to the first one, it heavily relies on the form tag of HTML, and makes everything like submitting a form(another copy of ASP.NET). Although this may not be a big problem from the point of view of a application developer, this may make component tree very complex, and makes writing sophisticated UI component difficult IMHO. When a Web action is implemented with a form action, it can not be bookmarked. With AppServer Faces most Web actions are implemented with the normal link urls, only when it's necessary is the form processing used. I can't make a detail comparison here, but I want to point out with JSF it's not easy if not impossible to write a custom component using composition, and it can't provide the dynamic server side CSS support as AppServer Faces does. Using pages as views and defining the navigation rules with XML file are also not elegant as AppServer Faces because the view changes in an AppServer Faces application are naturally determined by application logic and there is no page file concept in AppServer Faces at all.

    Before I finish I should say some features of JSF are absent from AppServer Faces like built-in validators at the moment. I may also misunderstand JSF here. We'll try our best to be compatible with JSF, it's a standard after all. But some problems indeed exist with JSF, and these design problems can explain why JSF spends so long time to come out. Anybody implements a specification like JSF will not be easy.

    Cheers
    Bo Yuan
  46. <!--AppServer Faces sits on top of Servlet 2.2+, so it's standard compliant if you don't think competing with JSF is violating standards (I'm not sure if it can be called standard already).-->

    No it has nothing to do with violating standards. But I don’t want to learn so many different frameworks to accomplish the same task, because it is counter productive. Besides that it makes your application non-portable, as opposed to using some thing from standard Java API.

    <!--The original intention to invent a tagged layer is said that the jobs of Web developers and Java developers can be separated. A good point in theory but in reality can you expect a Web developer without programming training could understand those complex tag library with subtle data binding logic? Can you teach them what EL is? If a Java programmer feels JSF pages like cryptic files, how a Web developer feels it? --!>

    Couldn’t agree you more. Java folks stretch it too far, beyond the point where there are more people who knows how to write Java then to design pages using taglibs and understand all the issues related to it. Again like you said, you don’t design pages in space you got to understand issues related to your environment.

    <!--I just want to point out some problems we found in JSF here. Except for the JSP and custom tag problems I mentioned above, one dubious design in JSF is that it treats a Web application as stateful.---!>

    I think here I disagree with you. The good thing about the JSF is that you can have a programming framework that can hide lot of complexity under the development tools and IDEs. Of course how you implement it is up to the vendor, but I don’t think so SUN ManagedBean or ASP.NET code behind approach is too bad, if it is not as perfect. As far as making web application stateful, it is not necessarily all-bad too. Think of all the complexity it hides from the developers in order to re-render pages programmatically when we hit a post back.. As a matter of fact I don’t see any complexity here from development point of view instead it is a much of an ease of use. I can understand in some cases it can cause a serious bandwidth problem and it make your pages bit slower to load, but hey you can always disabled the view state at the page level or even at the component level if you don't want to restore stare automatically. At least it is true for web controls in .NET but I don’t have enough expertise of JSF to back this argument (some one can help me out here).

    Any way Yuan, your arguments have lot of solid points and I have my biases on the basis of my own experience. If I have time I will download your tool and try to use it, hopefully then I will be in much better shape to discuss things with you.
  47. Hi,
    I think here I disagree with you. The good thing about the JSF is that you can have a programming framework that can hide lot of complexity under the development tools and IDEs.
    If you try other frameworks(including AppServer Faces), you'll find all of them have a common purpose that is attempting to hide complexity from programmers. The problem with JSF is that a lot of complexity shouldn't have been there from the begining. The tools just hide the unnecessary complexity because of its particulay approach. For example the view state should not be a big problem if you think out of JSF's design and look at it from other approaches. You can disable it but it's there in JSF means in some cases you have to rely on it and cache the states of component tree in session or client side, otherwise JSF won't use it from the begining. Making a Web application stateful should be an exception not norm, because the cost of statefullness is too high. Sometimes people think a tool can help them with some complexity problems but are not aware of those complexities actually not existing if they follow other approaches. For instance, if you don't use JSP(or ASP), where is code behind? Think again of those unnecessary XML crazinesses you can see everywhere today. Simple, intuitive should be an important quality of a framework. You shouldn't count on tools to help you hide the complexities that shouldn't exist.

    Cheers

    Bo Yuan
  48. <!--The problem with JSF is that a lot of complexity shouldn't have been there from the begining.... if you don't use JSP(or ASP), where is code behind?.. You shouldn't count on tools to help you hide the complexities that shouldn't exist.
    --!>

    Very true...You Preempted me...