JSF Articles – Wish List for JSF 2.0 and more AJAX+JSF

Discussions

News: JSF Articles – Wish List for JSF 2.0 and more AJAX+JSF

  1. Kito Mann sent in references to a new editorial on JSFCentral about the things he'd like to see in the JSF2 specification, as well as a new article on JSF Central by Mark Schiefelbein (a VP at BackBase) on AJAX-based Web Development with JSF. From the set of things JSF 2.0 should have:
    After teaching so many JSF courses and observing the students during the labs, it’s clear that expressions and navigation rules are by far the biggest offenders in JSF applications. If an expression doesn’t resolve to an object, nothing is displayed. If you mistype a navigation rule, simply redisplayed.. I’d like to see a configurable "fail hard" context parameter that will cause JSF to throw a FacesException in these cases. That way, developers won’t waste so much time hunting down these minor errors. ... One of the best things about JSF is that it’s extremely pluggable. But that pluggability falls short if you have any interest in accessing the navigation rules. I’d like to see an object model representing the navigation rules. That way, developers could use a format other than faces-config.xml for storing navigation rules, or easily add features based on navigation rules that have been loaded in the default manner. I think this could open up a whole range of possibilities for expanding the power of the navigation subsystem.
    Mark Schiefelbein's article AJAX-based Web Development with JSF uses Duke's Bookstore to show how AJAX and JSF integrate (using BackBase as a platform), showing how elements can be bound to backend components and partially updated on the client-side via AJAX. It's not a new idea any more – most AJAX/JSF implementations do this in various ways – but it's good to see more possibilities and explanations.

    Threaded Messages (39)

  2. Spring Web Flow (http://www.springframework.org/webflow) provides a robust flow execution engine that can take over responsibility for navigation in a JSF-based application, adding power while still feeling natural to JSF developers at the same time. Specifically, the framework provides good support for implementing dynamic navigation rules and evolving those rules on-the-fly with no container restart required. In addition, SWF's state management features provide additional scopes "flash" (aka view or page scope), flow (local flow session scope), and conversation (ongoing interaction scope) that compliment JSF's default scopes nicely and useful for stateful, Ajax-based applications. Some highlights of successful SWF JSF usage from our user forums at http://forum.springframework.org:
    I have been using SWF as a complete replacement for JSF navigation-rules, even in the case of our simpler pages and menus. I was happy to be able to take it to this extreme as it would be a bit too confusing for my team to have navigation rules defined in multiple places.
    I find that even with the simpler pages in JSF, you oftentimes need something to manage the state of your model across multiple requests to the page...there are many solutions for this problem in the JSF community (Tomahawk's saveState tag, Shale's dialog framework, etc.), but I personally find SWF's multiple scopes to be the most robust and elegant solution.
    Source: http://forum.springframework.org/showthread.php?t=36693 With the upcoming 1.0.2 release (due out this week with nightly builds undergoing sanity testing now) the JSF support has also been significant enhanced based on feedback in version 1.0. Most notably 1.0.2 offers: - Ease of configuration for those using SWF in a JSF environment, consistent with the other environments Spring Web Flow supports. Previously the JSF environment was more difficult to get going than any other environment. Not the case anymore. - Automatic back/refresh/forward button support out-of-the-box, consistent with other environments. Previously the JSF environment was configured not to support back button behavior by default. Not the case anymore. - Support for resolving flow variables in any of the support scopes "flash" (like view scope), "flow" (local flow scope), "conversation" (global conversation scope). Previously only "flowScope" was accessible to view developers. - Support for resolving scoped flow variables using an explicit variable prefix like {#flowExecution.someBean.someProperty} or without a prefix {#someBean.someProperty}. The latter is more what JSF developers are used to and is the default behavior now. When no prefix is specified, a search of flash/flow/conversation is performed in that order, with the option to have a fallback variable resolver when no match is found. Previously only the "flowScope" variable prefix was supported. - Support for embedding the flowExecutionKey (identifying the state of an active flow instance) in the UIViewRoot. This means view developers no longer have to track the ${flowExecutionKey} themselves and remember to post it back to the server. So the bottom line is JSF views in a SWF environment now look like standard JSF views (there is no difference at all), which should make SWF easier to adopt by the JSF community. Just a update on progress with using Spring Web Flow in a JSF world. I'm excited about participating in the JSF 2.0 EG and working with Ed and his team to help channel whats proven to work in the area of state management and navigation on a general basis back into JSF 2.0. Cheers, Keith Lead, Spring Web Flow http://www.springframework.org/webflow
  3. But if JSF is not sunset (which is the most appropriate choice, considering the pervasive flaws it has), here is what I'd like to see addressed, and I am definitely missing a lot, since my problems arise with it on day to day basis and I forget them a week later: 1. Throw away the JSF life cycle model. It's unnecessary and does not accomplish anything. A nasty hack such as immediate="true" should not be necessary in a well designed framework! If I have valueChangeListeners defined, whatever changes I make to backing beans, those changes should stick without me having to know how to full around with JSF life cycle. 2. Throw away the JSF's internal component model. It causes more problems than it solves. Have you seen the ugly code you have to write just to make JSF forget the model state because you just updated backing beans from a pop-up or iframe? That should be completely unnecessary. JSF's model state is only useful for value change detection. How many times have I actually needed value change detection? ZERO times. I've used it as a hack to get a page-submit-refresh on radio button click (and ever since then regretted that choice, and moved to the javascript clicking an invisible button which plays "nice" with the atrocious JSF life cycle). If I give up value change detection, that's not much of a loss to me! Toss that idiotic and very very hard to manage JSF internal model! I cannot tell you how many subtle and hard to detect bugs I had in the system because of it. Yes, it's true that when you finally understand how exactly it works, it gets easier. But it's never a joy to work with. It's a pain. 3. Custom components should be joke easy to implement. On this point I agree with the author. 4. Throw away JSF's multi-renderer ability. SERIOUSLY -- who uses that??? I don't. I don't know anyone who does. Just because some 2 or 5 dev teams on the planet use it does not mean that the other 5000 companies/dev teams have to suffer with renderer-related baggage!!! Why is a minority of developers prioritized above the vast majority who just want a slick and easy to use (X)HTML rendering? If I need to render my backing beans into PDF, I won't be using JSF. Thank you very much. I can do it just fine with better frameworks suited for just that purpose! Hello? Is anyone listening? 5. JSP absolutely needs to be permanently sunset ASAP. Period. No questions. No arguments. There is absolutely nothing good or redeeming about it. It was a nasty hack even back in its day. Even back in its day there were many many superior ways to handle view display than JSP. If JSF people listen to all my points but yet keep JSP as the primary rendering mechanism, then it's a waste of time, might as well not bother improving JSF. Something like facelets should be standard and almost mandatory in JSF. You should have to dig very hard to find how to use JSF with JSP. It should be de-emphasized or better yet, completely de-supported and sunset. 6. Error reporting needs to become a first class citizen. Errors have to be designed! Errors should be tested via focus groups of clueless developers to make SURE they are actually reasonable. If errors make sense to the immediate JSF core developers, that's NOT an indication that they are good error messages! A JSF error should have all the information to resolve the problem within 10 minutes. There is absolutely no reason why this cannot be achieved other than neglect, stupidity or laziness on the part of JSF developers. 7. JSF needs to stop making excuses about its poor set of standard components! JSF needs to have a super-rich set of standard components on par with J2SE class library. In particular I never want to hear this excuse -- "JSF is only a specification. JSF RI should not be used. Use ADF." Nonsense! I want a fully usable technology. I don't want a specification! I want something I can use. Making excuses that RI has hardly any standard components by saying it's only a blueprint for other vendors to build upon is nonsense! It's a cop out and it needs to be abandoned. Sun does not release J2SE in a "blueprint" form, does it? When you get J2SE you have pretty much everything you need to do almost anything. And that's why it's so popular and used so widely. JSF needs to mimic J2SE class library in its completeness. In other words... As I see it, JSF needs a radical redesign. Some fundamental goals may need to be realized to be errors in retrospect and may need to be abandoned. Minor changes to JSF will not save it, just like minor improvements did not save Struts.
  4. one more thing[ Go to top ]

    And one more thing. If JSF is going to manage the beans, fine, but let me access those beans easily!!! Hello? Have you seen that absurdly long and ugly code you have to write just to fetch another bean? Meh.... I don't like JSF. Can you tell?
  5. Re: one more thing[ Go to top ]

    Actually to comment on this list. I personally do not see JSF as being a dead duck, I like it very much, but it has issues. I think a lot of those issues are addressed in Ed Burns JSF 2.0 proposal, you are not the only one, having to fight many of these problems. I personally do not think that multirendering really is a huge issue, multi rendering basically is just a nice icing which you get from the patterns anyway. For decent UIs you need event models, you need mvc models on component level, so going all the way of being able to render into HTML, WAP or something else, does not add too much there. HTML is one of the most broken protocols for user interfaces anyway, it cannot really get much worse, so supporting other server side rendering protocols is just really something you normally get out of the box anyway, once you have html up and running. As for some other stuff, component api, a huge issue, probably the biggest problem JSF still has, it seems to be targeted in ed burns 2.0 release plan, jsp tag handlers dropped (or moved into annotations), no configuration except for defaults and annotations and the renderer moved into templates. It simply has to become simpler to write components, there is definitely a huge need for simplification, and the potential is there and it is possible. JSP... well you cannot forget, there was and is a huge jsp codebase there which you really cannot drop. JSF 1.2 resolved some issues with the JSTL/JSP/JSF rendering cycle, but dropping JSP entirely is probably still a no go (although a lot of people probably would not mind), fortunately there are other/better options if you want to make a clean cut. There is facelets, and many people dropped JSP in favor for it. On the component side, you probably could cover most of the jsp glue code nowadays via a small set of annotations and defaults. (I think I saw this on Ed Burns jsf 2.0 plan) More components, I also agree here to some degree, as a nice to have, it is also a huge topic in Ed burns JSF 2.0 plan. You have to have in mind, that standard jsf basically only had the standard html components as save subset of components, but I agree fully, more standard components would be nice. But I personally do not see this as a huge isse, there is a lot of component sets nowadays available you can use. Cutting down on the lifecycles. I also agree here from a usability standpoint if it really would be possible, unfortunately those lifecycles have their roots in the broken html protocol, and are needed to add some missing stuff, or to provide some intercepting points. The sheer number of lifecycle stages, are usability wise problematic. I personally prefer the Shale Form controller approach which cuts down the lifecycles to 4, and very clean 4 indeed. The main problem is that the Shale form controller covers 95% of all lifecycle use cases, there are however the last missing 5%. But one big problem in my opinion is that the lifecycle names are very generic, and 90% of all problems stem from this fact. The lifecycle itself, is just intercepting points and a clear calling order of which type of methods are called when, you cannot really avoid this once you move out of simple action models into validating rich client event models. Easy access beans, well this is a matter of taste, a neat high level tools class would help a lot (a number of them are floating around) The Application factory/singleton pattern chosen for JSF however besides that you have to dig through a lot of method calls has one huge advantage, It cuts down massively on parameters and enforced interfaces. They simply avoided the mistake of Struts of having enforced base classes that way. I personally also think that IoC for injecting beans is the preferred way to go, you often can write applications without even going through the Variable Resolver Singleton/factory. I do not see a huge isse which has to be addressed here, to my experience IoC mechanisms for bean injection are nowadays standard anyway, and thanks to the flexible variable resolver interface there are a lot of bindings into various IoC libraries, Spring and Seam instantly come to my mind as alternative mechanisms for Bean definitions and IoC.
  6. multirendering[ Go to top ]

    I personally do not think that multirendering really is a huge issue
    I think it's one of the things that stands in the way of allowing easy to implement custom components. Custom components are a nightmare in JSF because of its internal complexity (such as the life cycle, etc.) that, unfortunately, a component developer have to be aware of. And another problem is that it should be very easy to GUI-fy JSF, and JSF views should be viewable in any browser (like facelets allow you to do, etc.). So if you don't have a GUI-fied component, you should be able to preview your work by simply hitting your view template in a regular web browser. By GUI-fying I mean adding all the necessary hints that allow tools to resize them and place them and so on. There should be an absolute minimum that you need to add to GUI-fy a JSF component. I am talking about something like Sun Studio Creator here and making custom JSF components for that. JSF components are pretty tricky without that, but if you ever see the tutorial on making them GUI-aware, it's a nightmare. Does it have to be that way?
  7. Re: multirendering[ Go to top ]

    I personally do not think that multirendering really is a huge issue


    I think it's one of the things that stands in the way of allowing easy to implement custom components.

    Custom components are a nightmare in JSF because of its internal complexity (such as the life cycle, etc.) that, unfortunately, a component developer have to be aware of.
    Actually all that multiple targets for rendering introduces into the component api, is the mvc splitting of components. The API is unnecessary complex I agree, but that is not really caused by multi rendering capabilities. There are several issues in the component API. There is way too much xml glue, partially redundant. This is caused by the JSP part of the API. Redundant double definitions of gluing of the parts in code and in the xml parts. This easily could be resolved via introspection and annotations, where it really would belong to for 99% of all components, with override possibilities if needed. The entire save restore mechanisms, while really needed, could use helper apis or even better introspection could do the same in most cases (or annotations) The save restore itself, is needed, because you have to keep the values statefule, but automated defaults for their handling are heavily needed. and finally the biggest problem the renderer. This is a mess, just like servlets are for programming renderers. You have callbacks being called depending on the phases, and you have a crude print writer api which is basically the base for all your rendered code. This is a mess, in the servlet world the solution to this was, to go to templating engines, and program all of this in the target language you want to render for. JSF has to go this direction as well. In the end the ideal component api probably would be ... a component pojo with automated defaults for the properties for saving and restoring, so this does not have to be handcoded, and a renderer being embedded into a templating language with the component as model for the template. Additionally no xml configuration at all (only a small number of annotations), but override possibilities on the XML side of things, if needed. You then would end up with a template which resembles the rendered code and in most cases a simple pojo with a handful of properties resembling the data stored and the exposed attributes. This is the ideal case. Doable, yes definitely even within the realm of JSF 1.1/1.2. Done, unfortunately no one has done it so far. Needed, yes more than anything else in the JSF world.
  8. Re: one more thing[ Go to top ]

    Have you seen that absurdly long and ugly code you have to write just to fetch another bean?
    How are you accessing other managed beans?
  9. Re: one more thing[ Go to top ]

    Have you seen that absurdly long and ugly code you have to write just to fetch another bean?


    How are you accessing other managed beans?
    He probably uses the Factory classes provided by the JSF Java api ;-) Most people to my knowledge nowawdays simply use IoC. The Factory classes are really ugly in a way that you have to dig through 5 method calls to reach the bean. However a simple tools class encapsulting this, or simply by using IoC (either JSFs own ioc or some underlying IoC being bound by the variable resolver) resolves this issue. The main advantage of JSFs Factory approach is, that you can reach for the bean from anywhere in the code without having to push the bean in via parameter or like in case of struts having base classes or enforced interfaces.
  10. yes[ Go to top ]

    Yes, I use JSF's BeanClass bean = (BeanClass) FacesContext.getCurrentInstance().get... blah blah "beanName". API. Please don't tell me about IoC because I shouldn't need another framework to make this one useful. JSF needs to pull its own conceptual weight. And it doesn't. Further, JSF instantiates the beans that are managed. How will IoC insert itself into that process without some very ugly hack, like code weaving, or like a patch to JSF that you have to maintain, or perhaps JSF has a hook for bean instantiation? Whatever the case may be, it's not nice at all. IoC is overkill for most apps. If you have 500 beans that you need to manage, then IoC makes sense. If you have 5, then it makes no sense. Good OO design + POJOs is all that you need and JSF should work perfectly with that. What I see happening in JSF and in most things that Sun developers, is that they cater to the top 2% of the market while ignoring the other 98%. Then the 98% have to carry the burden of increased conceptual complexity that is there to serve solely the top 2% of the market. That's not only unfair -- it's a very poor engineering choice. It's called "over engineered".
  11. Re: yes[ Go to top ]

    Yes, I use JSF's BeanClass bean = (BeanClass) FacesContext.getCurrentInstance().get... blah blah "beanName". API.

    Please don't tell me about IoC because I shouldn't need another framework to make this one useful. JSF needs to pull its own conceptual weight.
    JSF has basic inversion of object control... what you basically do is just that you use the java api instead of the managed bean/managed property facilities which do exactly that. No additional framework is needed. JSF is just flexible enough that you can replace its version of IoC with more sophisticated implementations. Ah yes there is one case where you need the Factory API if you have cyclic references. (Dennis made me aware of it, I simply never use the api)
    Further, JSF instantiates the beans that are managed. How will IoC insert itself into that process without some very ugly hack, like code weaving, or like a patch to JSF that you have to maintain, or perhaps JSF has a hook for bean instantiation? Whatever the case may be, it's not nice at all.
    Actually it is nice and not an ugly hack, first of all, JSF has its own IoC mechanism, if you do not want to use that one, but still want to use all of JSF, simply replace the variable resolver, with another implementation. Actually Seam and Spring both provide their own variable resolvers to do exactly that. The variable resolver is one of the well defined hook points where you can replace everything to your liking and you still do not have to do ugly hacks. There are several other hook points where you can replace and intercept without starting to hack ugly, the view handler iś one of those, the phases to some extent, the renderers, the navigation handler. The funny thing is that the factor of extensibility has been resolved excellently in JSF.
    IoC is overkill for most apps. If you have 500 beans that you need to manage, then IoC makes sense. If you have 5, then it makes no sense. Good OO design + POJOs is all that you need and JSF should work perfectly with that.
    Since you have to declare your managed beans anyway, why not simply also weave them in the config file via the managed property mechanism if you have to ;-) I few lines of configuration code more. Outside of the core jsf scope there is a handful of annotation based solutions as well, as extensions. I hope I could clear things up a little bit.
  12. thanks[ Go to top ]

    Yes, I see what you're saying. Unfortunately I've not run across any examples that managed properties used like that. I now see that I can use managed properties to get references to other beans. Thank you for this tip. I still don't see why the Java API has to be that ugly. Couldn't there have been a convenience method like FacesContext.getBean("blah")? My main beef is that all around JSF API is very unwieldy and verbose. It seems like it was designed by someone who doesn't eat his/her own dog food, and so doesn't know the pain of actually using it in real life. I picked a bad example of the unwieldy API. :) Still it is annoying that JSF is so tricky to use right. Somehow I feel that using a framework in the right way should be natural and should not require years of mentoring under some wizened JSF master. JSF should not be like a mine-field. It should be fun to use. It should be impossible for a silent error to occur, and this is exactly what happens when you have a validation error but no corresponding h:message(s) tag. If someone who cared about developers designed it, then maybe it would work such that if h:messages is present, the errors are displayed there, and if not, they are dumped to the log or standard error/out. There should never be a possibility for silent errors unless you specifically jump through some hoops to silence them on purpose. What I see is that JSF is so pluggable and extensible that it is useless, because you have to plug it and extend it and combine it with 2-3 other frameworks to make it feel nice. That, to me, means something is wrong. When a programmer adds immediate="true" instead of thinking "maybe our life cycle model is waaaaay overcomplicated and maybe in a properly designed framework such a thing would not be necessary at all", that's a problem. I've never seen any framework that has something like immediate="true" nonsense of JSF. Instead of adding features to cover up the deficiencies it would be nice if JSF developers re-evaluated the potency of the already existing features. Maybe 5 features that cover 5 use cases can become 2 features that cover 10 use cases. That's what I like to see. There should be very few concept you have to learn, but they should be powerful enough to provide any emergent behavior that you want without the need for any boring and repetitive maintenance code.
  13. It seems that you do not know JSF good enough, and that is why you "hate" it. You probably never heard of Spring? I do agree that JSP needs to be removed from JSF as standard presentation tech, but to remove JSP altogether would be a mistake. Luifecycle model was created to simulate a desktop app. I think the idea was that you could easily modify your webapp to become a SWING app, but that may gone down hill with AJAX. Otherwise I think you just don't know enough and got burnt on JSF. Sorry, but I think that you should either cool off or dump JSF.
  14. It seems that you do not know JSF good enough,
    The more valuable the post: hey JSF gurus - hear hear, that is real experience shared by many ( I too for the records consider JSF to be ugly)
    and that is why you "hate" it..
    I hear that guy simply dissatisfied, and rightfully so - in the year 2007 in the standard framework it should be obvious and easy to do typical things. It is OK to learn things, but learning should be like series of AHA! moments and WOW! they do that too! exclamations. Learning JSF is series of WTF moments - and it should not be!
  15. and that is why you "hate" it..


    I hear that guy simply dissatisfied, and rightfully so - in the year 2007 in the standard framework it should be obvious and easy to do typical things.

    It is OK to learn things, but learning should be like series of AHA! moments and WOW! they do that too! exclamations.
    Learning JSF is series of WTF moments - and it should not be!
    I don't think Mr Lipelis "hate" JSF. In fact, many people who "hate" JSF don't bother to talk about it anymore.
  16. maybe[ Go to top ]

    I bet I know it better than you think, but probably not as good as the most proficient people. Just because I can admit I don't know something doesn't mean I am an idiot who knows nothing at all. :) You should be able to come to a conclusion about a framework within 2 weeks of using it. It should not be required to have a year worth of experience to have an opinion. Of course after much time, and much study, and much trial and error, and after integrating it with 2-5 other frameworks, and after writing a custom API that wraps the JSF ugliness, and after patching the JSF warts via a custom extension (see some of the sandbox components/tags on myfaces wiki... why are those components/tags necessary? they are necessary only because the core JSF is not good enough to cover very common cases). What's really bad is that when JSF doesn't cover a common case and you want to make your own component to take care of it, it is non-trivial to do so. But then ask yourself why did you bother to download JSF at all? I mean why not offer a Java compiler and call it a "web framework". I mean with enough elbow grease a Java compiler is a web framework...you just need to add an API or two, but it's almost there (compared to making a web page in assembly). See the flaw in this logic? We call that soup made from a rock. You come to a greedy lady and ask for soup. She says she has no ingredients. You say you can make a soup from a rock. You start boiling the rock and taste the broth. "MMMM very good, it only needs a little butter..." She gives you butter. Then "MMMM wow.. not bad, it only needs one potato." She gives you a potato. And so on, little by little you get soup made from a rock. You know this story? JSF is that rock in a rock soup. You just need to add the rest of the framework to make it tasty. No biggie. *not*
  17. Re: yes[ Go to top ]

    Yes, I use JSF's BeanClass bean = (BeanClass) FacesContext.getCurrentInstance().get... blah blah "beanName".
    Put a setter on the managed bean and inject a reference from one to the other. first #{second}
    Please don't tell me about IoC because I shouldn't need another framework to make this one useful. JSF needs to pull its own conceptual weight.
    IoC is a design pattern, not a framework or a database. As Werner has pointed out, it pulls it's weight by *not* needing another framework for this.
  18. thanks again[ Go to top ]

    Yes, I got it when Werner mentioned it. Thank you for your hands-on example. Maybe someone will find it on Google some day and be happy. :)
  19. I got my hopes up too soon[ Go to top ]

    Ok, I thought this was good. I have a bean that has a list of other beans. Beans in the list need a reference back to the parent bean. I don't see any convenient way to do this with the managed properties, considering you don't know in advance how many items will be in the list and considering that list can change at any time, and so cannot really be managed solely by some dependence injection container, since the container has no way to know what is really happening. So either I have to pass the reference all over the place manually (which is a major pain sometimes, unless you had enough wisdom to do it as a pattern right at the beginning, and I have to confess I am not that wise), or you need to fall back on the ugly JSF API that I criticized. So my point still stands.
  20. Re: I got my hopes up too soon[ Go to top ]

    Ok, I thought this was good.

    I have a bean that has a list of other beans. Beans in the list need a reference back to the parent bean.

    I don't see any convenient way to do this with the managed properties, considering you don't know in advance how many items will be in the list and considering that list can change at any time, and so cannot really be managed solely by some dependence injection container, since the container has no way to know what is really happening.

    So either I have to pass the reference all over the place manually (which is a major pain sometimes, unless you had enough wisdom to do it as a pattern right at the beginning, and I have to confess I am not that wise), or you need to fall back on the ugly JSF API that I criticized.

    So my point still stands.
    I pointed that out yesterday, that cyclic references are one of the two exceptions where you cannot apply the standard JSF IoC mechanisms, but... Obvious solution, have the beans assigned to the controller object before pushing them in, set the reference to the parent (container). Less obvious solution, do not use beans at all, just one bean representing the model the one which keeps your (map probably would be better, to get naming access to the elements in the frontend) Anyway hint, rethink your structure and patterns, your description sounds like an antipattern to me. (Extremely strong inter object dependencies over module/namespace boundaries. I usually prefer coarse grained IoC this keeps inter object dependencies on module/namespace level down to a bare minimum. This means, IoCed objects: Form controller, form models (preferably one per form or a combined form controller/model approach) bo layer dao layer and tools singletons, and various other infrastructural stuff. Before I IoC bind for instance two model objects, I rethink twice what I am doing and If I introduce a pattern problem there. Binding a model object to a view object etc... is basically a no brainer, this is just applying a pattern preplanned.. The same goes for the binding of the layers... preplanned proven patterns. But that are just my 2c...
  21. maybe[ Go to top ]

    I may need to rethink the pattern. However I don't think the pattern I am using now is obviously broken. In other words, until proven broken I don't think it is. Just because it doesn't work well with JSF, is not at all an indication of a problem. It may still be a problem. I keep my mind open on this issue. Without using some heavy-weight O/R solution, it is natural to have domain model beans that have lists of other beans (for one to many relationships). Then when you save them or do some things, it is pretty natural to want to have access to some parent information from within the child. In HTML DOM it is very easy. If it's an anti-pattern, then why would parent access be there in DOM? Further, I am a little apprehensive of people who talk about patterns and anti-patterns. It conjures bad images to my mind. I know, I know -- it's subjective and might even be irrelevant. Just that I can't accept "anti-pattern" term as a valid critique or even a valid bit of information to think about.
  22. Re: maybe[ Go to top ]

    I may need to rethink the pattern. However I don't think the pattern I am using now is obviously broken. In other words, until proven broken I don't think it is. Just because it doesn't work well with JSF, is not at all an indication of a problem. It may still be a problem. I keep my mind open on this issue.

    Without using some heavy-weight O/R solution, it is natural to have domain model beans that have lists of other beans (for one to many relationships). Then when you save them or do some things, it is pretty natural to want to have access to some parent information from within the child. In HTML DOM it is very easy. If it's an anti-pattern, then why would parent access be there in DOM?

    Further, I am a little apprehensive of people who talk about patterns and anti-patterns. It conjures bad images to my mind. I know, I know -- it's subjective and might even be irrelevant. Just that I can't accept "anti-pattern" term as a valid critique or even a valid bit of information to think about.
    Sorry it was rather late, I should not have said antipatterns, which it indeed is not and also, because I do not know your app, the domain of the problem. I is just my personal experience that trying to weave everything via IoC might be problematic due to way to heavy configuration (been there done that crashed).. This is also a reason why i do not like struts particularily which also tries to bind absolutely everything over configuration. Hence I normally try to keep the configuration as low as possible, which means, that I usually use this to bind the layers and some patterns. The DAO bo patterns simplify this to a certain extent because they give clear boundaries, you can start to weave on. But DAO BO also might be overkill for certain domains as well... As I said, depending on the problem one working pattern is a problem for another domain. I really have to apologize for this.
  23. thinking...[ Go to top ]

    Werner, I agree with you. I also don't like heavy configuration. Part of the problem is that our application for reasons I would rather not get into is not optimally (to my mind) broken down. I take some responsibility for that. Ideally I would like our domain beans to have nothing to do with JSF backing beans (or view beans? what is the right name?). With a more clever and thought out domain bean model we probably could have been in a situation where there would be less need to access parent beans. But can such need really be completely eliminated? And if yes, then what is the most elegant way? I was thinking about it today and I nothing super-elegant came to my mind. The only thing I could think of is that maybe child beans should be inner classes. Inner classes naturally have access to their container class' information. I am not sure if that's a good thing to do. If I couple things too tightly, I feel pain when I have to modify something. But if I avoid coupling altogether, there is major pain just trying to access some routine data sometimes, since everything is so isolated. I guess what I am trying to say is that JSF should be very rewarding to experts and it should be very lenient to clueless developers (like I am at times). But instead my experience is that JSF is lenient with experts and tortures the clueless developer. I don't think that's good.
  24. Re: one more thing[ Go to top ]

    And one more thing.

    If JSF is going to manage the beans, fine, but let me access those beans easily!!! Hello? Have you seen that absurdly long and ugly code you have to write just to fetch another bean?tell?
    Well, as with many things in many libraries you often have to write your own small utility classes for stuff like that. It's no different than the fact that there isn't for example a simple "String loadFile(String name);" method in Java SE. If you want to access beans easily, put that "absurdly long" code in 1 static method and simply call that. A quick and dirty implementation could look something like this:
    public class ManagedBeans { @SuppressWarnings("unchecked") public static T getBean(String name, Class clazz ) { FacesContext context = FacesContext.getCurrentInstance(); ValueBinding binding = context.getApplication().createValueBinding( "#{" + name + "}" ); return (T)binding.getValue(context); } }
    If you need a bean within a JSF context, just call something like:
    MyBean bean = ManagedBeans.getBean( "fooBean", MyBean.class );
  25. I disagree[ Go to top ]

    I think it's the job of the framework to come complete with all the creature comforts you'll need. You shouldn't have to write your own utility classes. By the way, you probably meant to do this (looking at your code): public static T getBean(String name, Class clazz) { FacesContext context = FacesContext.getCurrentInstance(); ValueBinding binding = context.getApplication().createValueBinding( "#{" + name + "}" ); return clazz.cast(binding.getValue(context)); } Otherwise I don't understand why you're passing clazz into it.
  26. Re: I disagree[ Go to top ]

    I think it's the job of the framework to come complete with all the creature comforts you'll need.

    You shouldn't have to write your own utility classes.
    Yes & no. By their very nature, most utility methods are limited in scope and often meant for a very specific use. The framework offers some general functionality which you then specialize according to your needs (and acknowledge that any side effects don't apply to your use case). The "String loadFile(String file);" I mentioned earlier is perhaps a good example. Do we want something like this is the standard API? Its perhaps the #1 thing most people beginning with files in Java would want, but as experienced users we know we should not use such a method except in some special occasions. Nevertheless I do agree that some generality in Java could be augmented by having some sensible default functionality.
    I don't understand why you're passing clazz into it.
    Well for starters I said it was just a quick & dirty piece of code ;-) But the idea was to infer the method's return type from the method's argument. That way clients of this code would not have to resort to casting. While we're at it, the code is open for more optimizations of course. We might use formatting instead of the + operator, or perhaps even better, use the variable resolver mechanism directly instead of creating a value binding. I do appreciate your suggestion though :)
  27. One other thing[ Go to top ]

    I think it's the job of the framework to come complete with all the creature comforts you'll need.it.
    Just some other note about this issue; if you look at the source code of either the SUN RI of the MyFaces implementations, you'll find that quite a lot of these handy utility methods people grave for are in fact already there. They're just not in the public API. This is perhaps somewhat of a downside of JSF being a spec. Not only does it take far too much time and efforts to write specifications for all these little nitty gritty methods, it also imposes a far too great burden on implementors of a spec. We've seen this in the past. If a spec is too large and too detailed it just takes an incredible amount of time to implement. Sometimes so much efforts are involved that no implementations at all are created or that several partly implemented products are released. Of course, these different products than never implement the exact same amount of features which in effect locks code to a particular implementation. This completely defeats the purpose of having a spec in the first place. I believe there has been some talk on the MyFaces mailinglist to put some of those utility methods in an implementation independent library of their own. I also wouldn't be surprised if some of these existing utilities make in into a future version of the JSF spec.
  28. agreed[ Go to top ]

    I agree with you completely on this. I think most of the quality issues I see with JSF is due to the fact that JSF is a spec first and a product only a distant 10th (not even 2nd). If JSF was a product, first and foremost, and a spec only second, then we would all benefit. I think Sun should let their RI open source implementation be the spec (so to speak), with the formal spec trailing the RI implementation. RI should be a polished, complete, smooth product with great free documentation first and foremost. Let the formal spec trail behind that. If RI is open sourced under a reasonable license, I don't think independent vendors should be complaining if the spec trails RI. The RI being ahead of spec will only be a conflict of interest issue if RI implementation is closed source. JSF documentation is in a very bad shape right now because if JSF is not really a product and if it's only a spec, why should Sun bother documenting it when you have a (useless for real world development) spec document? All these problems with JSF stem from a few factors. JSF being a spec first and foremost is a very, very unfortunate choice that is a major factor in JSF's suckiness. The result of that is also a "design by committee" nonsense. Another factor is that JSF is written by some stooge who has no fun and has no concept of art or beauty of programming, no idea of elegance, of programmatic eloquence, of conceptual power to weight ratio and other such things that distinguish excellent programmers. I'd say get rid of all the old-at-heart (not physical age) stooges and put some open-minded developers who love what they do and who seek elegance and beauty and polish from their work. It could be 80 yr old code wizards who love what they do. I am not talking about something physical. Just get rid of the boring stooges and get rid of committees. Let one person be responsible for the majority of JSF, and let the spec committee trail behind RI. Besides all that I still think JSF needs a major overhaul. It's too bulky and unwieldy and the quality of RI is the pits for real world use (and we shouldn't be forced to get ADF to get good mileage from JSF). Just my .02c opinion.
  29. Spec trailing behind RI[ Go to top ]

    I think Sun should let their RI open source implementation be the spec (so to speak), with the formal spec trailing the RI implementation. RI should be a polished, complete, smooth product with great free documentation first and foremost. Let the formal spec trail behind that.
    I think this should really be the way ANY spec comes about! Design-by-committee has never been a good idea, so why do people think it is good for JSR's? Pick the specs out of the best open source projects and commercial products (where the vendor is willing to donate code), that way most of the teething problems and initial design flaws would never be in the spec to begin with, because people in real-life projects would have already smoothed these out. / Wille Blog: Buzzword Bingo
  30. 4. Throw away JSF's multi-renderer ability. SERIOUSLY -- who uses that??? I don't. I don't know anyone who does. Just because some 2 or 5 dev teams on the planet use it does not mean that the other 5000 companies/dev teams have to suffer with renderer-related baggage!!! Why is a minority of developers prioritized above the vast majority who just want a slick and easy to use (X)HTML rendering?
    I completely disagree. Just because you don't utilize it for your specific application/domain doesn't mean it's not useful. That's why other frameworks like Spring MVC, etc... all support different view technologies. Not everyone is building apps that emit html. What if I want to generate XML output that's streamed to the browser with an attached xsl stylesheet, to take advantage of client side caching capabilities and from then on all I have to do is stream xml data and the same stylesheet is reused. This web view model is way more flexible than html and also allows to render on non-browser devices. Ilya
  31. But what will left in JSF after that?
  32. nothing! that's the point[ Go to top ]

    What will be left? It's something between nothing and not much. That's the whole point. From my point of view, the flaws in JSF are so fundamental, that you can't just patch JSF into a workable shape. You probably need to scrap it and admit that it was a failed experiment. I'm playing with wicket right now. If I don't get a big nasty surprise soon, it might be the direction I will be going. I'm going to reserve judgment for now. I also like what Tapestry appears to be doing, but I don't have enough hands-on experience to say anything about it.
  33. More wishlist items[ Go to top ]

    I have a similar wishlist at http://www.ninthavenue.com.au/blog/jsf_2.0_ideas . In summary I'd like to see: * Master / client templating * JSF componenets as first class (ie no JSP tag handlers) * Standardized AJAX / partial request support * Separate Build and Render phases * Ability to invoke lifecycle / actions on initial page request * Standardized conversation scope * Improved state management through statelessness or state deltas * Allow action="GET" for Plus a bunch of other small timesavers which you can read about on my blog if you're interested. Most of these ideas already seem to have made it into the draft JSR, so I'm a happy JSF camper.
  34. I like the concepts in spring web flow, but have held off really looking at it because the online examples (even the non-JSF ones) can be easily broken with an excessive use of the back button.
  35. Delphi, Before the upcoming 1.0.2 release, Spring Web Flow's JSF integration did not enable browser back button support by default. With 1.0.2, full back button support is the default, and this is now the case for all environments Spring Web Flow supports including Spring MVC and Struts (1 and 2). Regarding your comment about back button issues on "excessive use" in the other samples: we place a limit on the number of restorable flow snapshots that can be restored per conversation (a snapshot is taken for each restorable point when using back). We do this to prevent excessive abuse or denial of service attacks. The limit is tuneable with a single flag, and you can configure that there be no limit at all. It's worth noting that respected companies are using Spring Web Flow in production today for demanding environments (I can provide references off-line). The framework is a mature open source product now 2-years into development, and production-ready since 1.0 final in October 2006. It, like the rest of Spring, is also backed by Interface21 professional support. I invite you to give Spring Web Flow 1.0.2 a try when it is released shortly! Keith Lead, Spring Web Flow http://www.springframework.org/webflow http://www.interface21.com
  36. Thanks for the reply Keith, I realize this is a late post, but I'll take a look at the new version. I thought the current version was supposed to handle back button navigation as part of the whole conversion management process.
  37. Hi all, It's discussions like this that make think twice about moving to JSF. I'd like to have the time to explore JSF and see for myself. But what are the other options? Hibernate + Spring is no gamble. JSP is 'old' but works fine, GWT is no option, ADF is Oracle specialized (?). Any thoughts? Any good comparisons out there? Ronald
  38. Hi all,

    It's discussions like this that make think twice about moving to JSF. I'd like to have the time to explore JSF and see for myself.
    But what are the other options? Hibernate + Spring is no gamble. JSP is 'old' but works fine, GWT is no option, ADF is Oracle specialized (?).

    Any thoughts? Any good comparisons out there?

    Ronald
    I myself am rethinking the benefit of using JSF. I've always been a fan - I think its an improvement over Struts. And its a standard. Now, just because something is a standard doesn't mean its worth using, but again I think its pretty well designed. What I'm struggling with now is the rationale for using JSF when there are so many other good RIA frameworks out there right now, open-source. I've been itching to use Icefaces but haven't had the time yet. But there are other options like openlazlo that seem to offer alot and are, in some ways, easier to use. One RIA framework I've used quite a bit of is ZK ( http://www.zkoss.org/ ). Its sinfully easy to use, alot less markup than JSF and it looks great. I definitely think the JSF vendors need to make a big push quickly toward AJAX if the framework is going to remain relevant. Mike
  39. Its sinfully easy to use, alot less markup than JSF and it looks great.
    I definitely think the JSF vendors need to make a big push quickly toward AJAX if the framework is going to remain relevant.

    Mike
    No worries, it is happening as we speak, we will probably see some of this stuff already very soon. For now some ajax already is in jsf, not in the core specs but in the component set. There is ajax4jsf and the Trinidad ppr solutions, for pushing page parts into the ajax domain, there are ajax enabled components and component sets which have ajax integrated. Many ajax frameworks outside of the JSF domain I have seen so far were basically extended ppr solutions pushing page parts into the ajax domain. A viable way, but also with shortcomings. This is there already... What really is needed however is a full rich client solution for this domain. But this is another beast. You have to deal with client side events triggered by the milisecond and then synced into the server etc... So there has to be some client and server side balancing of events, which are passed down which are not. Also you need to be stateful on the server, because you deal with micro requests. The frameworks on the JSF side which will have to push some kind of event filtering layer on top of it, the server side statefulness problem is solved in many ways, we have various dialog systems, we have shale, myfaces orchestra and spring dialog. To get all of that into the spec, we have to wait. There is nothing which prevents that however already on component set level, and as I said we probably will see something along those lines very soon.
  40. Hi all,

    It's discussions like this that make think twice about moving to JSF. I'd like to have the time to explore JSF and see for myself.
    But what are the other options? Hibernate + Spring is no gamble. JSP is 'old' but works fine, GWT is no option, ADF is Oracle specialized (?).

    Any thoughts? Any good comparisons out there?

    Ronald
    Well depends on what you want to achieve, if you want to have a fully dynamic site with almost no page refreshes, then JSF as is probably is not the way to go. Although you have solutions like ajax4jsf and some or a lot of ajax components depending on the component set. Not for now at least, most component packs have some ajax support in, but a really dynamic framework is not there yet, it is coming ;-)... For classical intranet situations, JSF + a good component pack, definitely is a viable way, the vendor support is there, the tools support as well, and the implementation time is way less than with a classical action based approach. Also the sheer number of hundreds of freely available components also helps in classical intranet situations. If you have a heavy load site, with lots of hits, then a mixed approach might make sense or a classical action based approach, it is simply lighter on the server. (Although aopproches like facelets help a lot to remove some server burden)