Re: Message Panel in JSF/MyFaces
Thanks for your feedbacks... I will investigate in that direction. another little question: Is it better to have some kind of message panel inside the page as we have first though or should we have to go to a separate browser window that will implement Ajax or pure jsf or pure html ? 2005/10/7, Richard Wallace [EMAIL PROTECTED]: Have you taken a look at AjaxAnywhere (http://ajaxanywhere.sourceforge.net/)? I haven't used it yet but I plan to for all my data tables that will be sortable and pageable etc. The basic principal is that you mark zones of the page as ajax reloadable and then you use javascript to reload whichever zone you want whenever you want it reloaded. They don't have true JSF components yet, but you can still use it with JSF. Here's a demo http://ajaxanywhere.sweetdev-labs.org:8080/ajaxAnywhereDemo/facesFrame.jsp. They plan on adding more JSF capabilities in the next version AFAIK. Rich MarcV wrote: Hello, we have to implement a message panel where the a-synchronous messages from the server will be displayed in real-time and avoiding the usual refresh page. The messages will be of 3 audience : All, group of user, specific user. We've saw in the Sandbox the auto-update table with Ajax... Is it suitable for that ? Is it compatible with Sun RI Do you have any other tips/tools/recommendation for that ? -- A+, MarcV. -- A+, MarcV.
tabbedpane onclick
Hi, I´m using a tabbed pane and I would like that when one of the tabs is clicked on, a backing bean method is called. Is that possible? If it is, how do I do it? Thanks Kelly.
Re: MyFaces and Shale Clay again
[EMAIL PROTECTED] (Gary VanMatre) wrote on 10/06/2005 02:24:38 PM: I've not tried the tomahawk components yet but I think Clay should have a base configuration file for these components. If you take on that task and would like to contribute back to Shale, please let us know:-) I agree, clay should have a base configuration for the tomahawk components. I will contribute it to shale when I finish.
Re: [OT] Generic search in Hibernate
Richard Wallace wrote: How do you normally do search functionality like this? Do you expose the Hibernate query API to the JSF layer? No, that is why the BO-DAO Pattern existis, I usually and that works exceptionally well, split the application into three layers one which is tied to JSF sort of the UI layer then the business object layer which encapsules all the functionality needed in a semi/reusable abstracted business layer and over that layer automated transactions are woven via aop (spring in the last two cases) and the pure database access is moved into DAO objects. It is more overhead to program, but in the end you get resuable business logic and a rather good abstraction of the data access layer. In the long run probably a move of the BO layer to EJB3 will make sense (I am using Spring for that now) but EJB was sort of a no touch thing to me, up until recently, due to the overhead complexity and glue code involved with it, that will change soon with EJB3. The main reason I wanted to try and abstract it was in case we did see some need in the future to swtich to a different ORM tool like EJB 3 or whatever else is the latest greatest. I mean, in theory, the presentation layer shouldn't care one wit what the data access layer uses to get it's job done. That's the whole reason for abstracting the Hibernate stuff in DAOs. I think DAO should be enough, you just pass the parameter lists you determine into the DAO and have the query logic there figure it out. No need for another layer of query abstraction, you might also consider to move all your query stuff which is not categorized to a central place so that you can adjust that. But moving that stuff into a DAO layer if you do it cleanly should be sufficient to give you the chance to move the data access into another system, one of the reasons why the DAO pattern exists at all. I don't think my situation is all that different from others that are out there. I have Hibernate at the lowest level doing data access, spring in the middle managing services which use the data access layer and then JSF at the presentation layer utilizing the APIs the services expose. I guess I'm just curious about what the best practices are and what people would think if I exposed the fact that the data layer is using Hibernate at the presentation layer by using the Hibernate criteria API. No as I said... push the query data through your layers as POJOs into the DAO layer and have the dao layer deal with it on the query level. But do not push controls or something else JSF related into either the Business Layer or the DAO layer, you lose portability and and up in a mess which is hard to clean afterwards. Generally following the DAO-BO approach with a clean separation of concerns is currently to my knowledge considered a very good approach. You get other benefits from it, like you can AOP the interfaces and do other stuff (like adding automated transaction handling on business level, you can do a simulation on parts of the system which are not finished and then IoC the parts you just get in etc...) The downside of this pattern is, it is rather coding intensive and definitely not suitable for quick hacks and swiftly written applications. The ideal idea would be to have a collection of business objects which you can apply to a workflow the system has to perform, but that idea is unfortunately good on paper but does not work out as expected in reality. Hence the whole EJB approach sort of was a good idea but did not work fully out.
Re: Message Panel in JSF/MyFaces
Opening separate browser windows, within the same session opens a can of worms of problems you might not really want to tap into. Opening a message window is a viable approach however which might not trigger the problems you get with a multi window approach as long as no application logic is interwoven, however most common and a generally good design is not to use popups (I use them myself sometimes, but I probably should beat me for that as well) You might get more problems than solutions by using popups in the future, and believe me users hate them. I usually use a specially marked location within the page to display error messages or messages generally. Using something like a fade or another special effect helps to push the users attention to the message. That approach works exceptionally well. Werner MarcV wrote: Thanks for your feedbacks... I will investigate in that direction. another little question: Is it better to have some kind of message panel inside the page as we have first though or should we have to go to a separate browser window that will implement Ajax or pure jsf or pure html ? 2005/10/7, Richard Wallace [EMAIL PROTECTED]:
Re: [OT] Generic search in Hibernate
Werner Punz wrote: Richard Wallace wrote: How do you normally do search functionality like this? Do you expose the Hibernate query API to the JSF layer? No, that is why the BO-DAO Pattern existis, I usually and that works exceptionally well, split the application into three layers one which is tied to JSF sort of the UI layer then the business object layer which encapsules all the functionality needed in a semi/reusable abstracted business layer and over that layer automated transactions are woven via aop (spring in the last two cases) and the pure database access is moved into DAO objects. It is more overhead to program, but in the end you get resuable business logic and a rather good abstraction of the data access layer. In the long run probably a move of the BO layer to EJB3 will make sense (I am using Spring for that now) but EJB was sort of a no touch thing to me, up until recently, due to the overhead complexity and glue code involved with it, that will change soon with EJB3. Yes, this is the EXACT situation I'm in. I have my DAOs only doing data access and have a BO, or service layer, that is where I do all the more complicated business logic stuff and JSF only ever accesses the service API. I also use Spring and have my transactions woven in with aop and plan to also use acegi to weave in authorization. The main reason I wanted to try and abstract it was in case we did see some need in the future to swtich to a different ORM tool like EJB 3 or whatever else is the latest greatest. I mean, in theory, the presentation layer shouldn't care one wit what the data access layer uses to get it's job done. That's the whole reason for abstracting the Hibernate stuff in DAOs. I think DAO should be enough, you just pass the parameter lists you determine into the DAO and have the query logic there figure it out. No need for another layer of query abstraction, you might also consider to move all your query stuff which is not categorized to a central place so that you can adjust that. But moving that stuff into a DAO layer if you do it cleanly should be sufficient to give you the chance to move the data access into another system, one of the reasons why the DAO pattern exists at all. The only reason I'm reluctant to do something like a parameter list is because it's pretty limited to the kind of queries you can do. Usually you'll be stuck only doing an and or an or on all the parameters and can't really do anything more complex. For most situations that would be ok but there are a couple of situations in which I will need to be able to do more expressive queries. I don't think my situation is all that different from others that are out there. I have Hibernate at the lowest level doing data access, spring in the middle managing services which use the data access layer and then JSF at the presentation layer utilizing the APIs the services expose. I guess I'm just curious about what the best practices are and what people would think if I exposed the fact that the data layer is using Hibernate at the presentation layer by using the Hibernate criteria API. No as I said... push the query data through your layers as POJOs into the DAO layer and have the dao layer deal with it on the query level. But do not push controls or something else JSF related into either the Business Layer or the DAO layer, you lose portability and and up in a mess which is hard to clean afterwards. Generally following the DAO-BO approach with a clean separation of concerns is currently to my knowledge considered a very good approach. You get other benefits from it, like you can AOP the interfaces and do other stuff (like adding automated transaction handling on business level, you can do a simulation on parts of the system which are not finished and then IoC the parts you just get in etc...) The downside of this pattern is, it is rather coding intensive and definitely not suitable for quick hacks and swiftly written applications. The ideal idea would be to have a collection of business objects which you can apply to a workflow the system has to perform, but that idea is unfortunately good on paper but does not work out as expected in reality. Hence the whole EJB approach sort of was a good idea but did not work fully out. Alright, it sounds like there are a couple of approaches that I can explore. 1) Passing a list of parameters to the DAOs and let them build the criteria or query to be executed. One interesting thing here is that I could actually use some query by example kind of thing and then just use Hibernates query by example capabilities. Otherwise, this is probably going to be something like a list of some kind of object that encapsulates the property, the operation and the value to do the filtering with. This would limit me to doing only disjunctions and conjunctions, but it does put all the data access specific logic in the DAOs where they should
Using Enums in a list
I recently blogged about how I use Enums in select lists. Perhaps others here may find it useful or have some comments. http://brondsema.net/blog/index.php/2005/09/30/jsf_and_java_5_0_enums -- Dave Brondsema : [EMAIL PROTECTED] http://www.brondsema.net : personal http://www.splike.com : programming signature.asc Description: OpenPGP digital signature
inputCalendar and javascript errors
I can run the calendar.jsp example (from myfaces-20051006-examples, simple.war) here on my local machine with no problems. However when simple.war is deployed to an actual host (Kattare or DailyRazor) and I again attempt to run calendar.jsp, I immediately get two javascript errors: Error: jscalendarSetImageDirectory is not defined Source File: http://www.ghkcfg.com/simple/calendar.jsf Line: 19 Error: loadPopupScript is not defined Source File: http://www.ghkcfg.com/simple/calendar.jsf Line: 78 No images are displayed and no pop-ups pop-up. I really would like to use inputCalendar as it's very cool. Can anyone help me?
