Re: [PORTAL] Custom lifecycle?
On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. What's the advantage of a custom lifecycle over using a phase listener? --Adam
RE: ADF Faces/Trinidad Shale?
Hi. I used the cleaned-up version of web.xml. But Im still getting the same error: No AdfRenderingContext -Original Message- From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 9:53 PM To: adffaces-dev@incubator.apache.org Subject: Re: ADF Faces/Trinidad Shale? See my commentsi n the XML code. Regards ?xml version = '1.0' encoding = 'windows-1252'? web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; !-- General settings -- descriptionEmpty web.xml file for Web Application/description session-config session-timeout10/session-timeout /session-config mime-mapping extensionhtml/extension mime-typetext/html/mime-type /mime-mapping mime-mapping extensiontxt/extension mime-typetext/plain/mime-type /mime-mapping welcome-file-list welcome-file/faces/pages/welcome.jsp/welcome-file /welcome-file-list !-- Commons Chain entrie -- !-- Commons Chain Configuration Listener -- context-param param-nameorg.apache.commons.chain.CONFIG_WEB_RESOURCE /param-name param-value/WEB-INF/chain-config.xml/param-value /context-param listener listener-classorg.apache.commons.chain.web.ChainListener /listener-class /listener !-- JSF entrie -- context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/faces/*/url-pattern /servlet-mapping !-- You really don't want to miss anycall do you? That might cause a problem, not sure. Personally I would flush this part-- !-- servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.faces/url-pattern /servlet-mapping -- !-- ADF Faces entrie -- servlet servlet-nameresources/servlet-name servlet-classoracle.adf.view.faces.webapp.ResourceServlet /servlet-class /servlet servlet-mapping servlet-nameresources/servlet-name url-pattern/adf/*/url-pattern /servlet-mapping filter filter-nameadfFaces/filter-name filter-classoracle.adf.view.faces.webapp.AdfFacesFilter /filter-class /filter !-- That's the correct mapping -- filter-mapping filter-nameadfFaces/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping !-- There's no servlet named *.jsp -- !-- filter-mapping filter-nameadfFaces/filter-name servlet-name*.jsp/servlet-name /filter-mapping -- !-- You should just place the filter on the servlet really. -- !-- filter-mapping filter-nameadfFaces/filter-name url-pattern*.jspx/url-pattern /filter-mapping -- !-- ADF Databinding entries -- context-param param-nameCpxFileName/param-name param-valueorg.clarke.pagedefs.DataBindings/param-value /context-param filter filter-nameadfBindings/filter-name filter-classoracle.adf.model.servlet.ADFBindingFilter /filter-class /filter !-- You were missing the mapping for ADF Databings -- filter-mapping filter-nameadfBindings/filter-name url-pattern*.jsp/url-pattern /filter-mapping filter-mapping filter-nameadfBindings/filter-name url-pattern*.jspx/url-pattern /filter-mapping !-- Shale entries -- context-param param-nameorg.apache.shale.view.EXCEPTION_DISPATCH_PATH /param-name param-value/exception/correct.faces/param-value /context-param !-- Shale Application Controller Filter -- filter filter-nameshale/filter-name filter-classorg.apache.shale.faces.ShaleApplicationFilter /filter-class /filter !-- That entry imply that shale will filter all request, not just the Faces Servlet ones, is that wanted? When that filter execute, it means that adfFaces filter won't be executed. Have you tried removing it?-- filter-mapping filter-nameshale/filter-name url-pattern/*/url-pattern /filter-mapping !-- Duplicate entry -- !--filter-mapping filter-nameshale/filter-name url-pattern/*/url-pattern /filter-mapping-- filter-mapping filter-nameshale/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping /web-app On 10/20/06, Simon Lessard [EMAIL PROTECTED] wrote: Ok... That's not a really clean web.xml. Let me clean it up fast and see if the new version works. On
RE: ADF Faces/Trinidad Shale?
Hi Mathias, Yes pls. I want to know if there is an issue between using servlets and filters with the commercial ADF Faces and with Trinidad. Actually I already tried using Mabon, I added the necessary entries for Mabon servlet, and I still get the same error: No AdfRenderingContext. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Friday, October 20, 2006 11:42 PM To: adffaces-dev@incubator.apache.org Subject: Re: ADF Faces/Trinidad Shale? Anthony, I was using Shale's viewcontroller on a Trinidad app. worked fine. I try to find the web.xml for that :) However, that is not needed filter-mapping filter-nameshale/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping -M On 10/20/06, Simon Lessard [EMAIL PROTECTED] wrote: See my commentsi n the XML code. Regards ?xml version = '1.0' encoding = 'windows-1252'? web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; !-- General settings -- descriptionEmpty web.xml file for Web Application/description session-config session-timeout10/session-timeout /session-config mime-mapping extensionhtml/extension mime-typetext/html/mime-type /mime-mapping mime-mapping extensiontxt/extension mime-typetext/plain/mime-type /mime-mapping welcome-file-list welcome-file/faces/pages/welcome.jsp/welcome-file /welcome-file-list !-- Commons Chain entrie -- !-- Commons Chain Configuration Listener -- context-param param-nameorg.apache.commons.chain.CONFIG_WEB_RESOURCE /param-name param-value/WEB-INF/chain-config.xml/param-value /context-param listener listener-classorg.apache.commons.chain.web.ChainListener /listener-class /listener !-- JSF entrie -- context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/faces/*/url-pattern /servlet-mapping !-- You really don't want to miss anycall do you? That might cause a problem, not sure. Personally I would flush this part-- !-- servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.faces/url-pattern /servlet-mapping -- !-- ADF Faces entrie -- servlet servlet-nameresources/servlet-name servlet-classoracle.adf.view.faces.webapp.ResourceServlet /servlet-class /servlet servlet-mapping servlet-nameresources/servlet-name url-pattern/adf/*/url-pattern /servlet-mapping filter filter-nameadfFaces/filter-name filter-classoracle.adf.view.faces.webapp.AdfFacesFilter /filter-class /filter !-- That's the correct mapping -- filter-mapping filter-nameadfFaces/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping !-- There's no servlet named *.jsp -- !-- filter-mapping filter-nameadfFaces/filter-name servlet-name*.jsp/servlet-name /filter-mapping -- !-- You should just place the filter on the servlet really. -- !-- filter-mapping filter-nameadfFaces/filter-name url-pattern*.jspx/url-pattern /filter-mapping -- !-- ADF Databinding entries -- context-param param-nameCpxFileName/param-name param-valueorg.clarke.pagedefs.DataBindings/param-value /context-param filter filter-nameadfBindings/filter-name filter-classoracle.adf.model.servlet.ADFBindingFilter /filter-class /filter !-- You were missing the mapping for ADF Databings -- filter-mapping filter-nameadfBindings/filter-name url-pattern*.jsp/url-pattern /filter-mapping filter-mapping filter-nameadfBindings/filter-name url-pattern*.jspx/url-pattern /filter-mapping !-- Shale entries -- context-param param-nameorg.apache.shale.view.EXCEPTION_DISPATCH_PATH /param-name param-value/exception/correct.faces/param-value /context-param !-- Shale Application Controller Filter -- filter filter-nameshale/filter-name filter-classorg.apache.shale.faces.ShaleApplicationFilter /filter-class /filter !-- That entry imply that shale will filter all request, not just the Faces Servlet ones, is that wanted? When that filter
trinidad build taking time
My trinidad build is taking a lot of time. It seems to get stuck here for a while. Anyone else, facing the same delay ? Is this related to the scheduled downtime ? [INFO] snapshot org.apache.myfaces.trinidadbuild:maven-faces-plugin:incubator-m1 -SNAPSHOT: checking for updates from people.apache-mirror [WARNING] repository metadata for: 'snapshot org.apache.myfaces.trinidadbuild:ma ven-faces-plugin:incubator-m1-SNAPSHOT' could not be retrieved from repository: people.apache-mirror due to an error: Error transferring file [INFO] Repository 'people.apache-mirror' will be blacklisted -Piyush
Re: trinidad build taking time
people.apache-mirror is currently down. this is one of the less interesting servers at the ASF. Only snapshot's and podlings deploy their stuff to it... Others might be ok, but some have still DNS issues with other asf servers... Tomorrow should be better :) -M On 10/23/06, Piyush Hari [EMAIL PROTECTED] wrote: My trinidad build is taking a lot of time. It seems to get stuck here for a while. Anyone else, facing the same delay ? Is this related to the scheduled downtime ? [INFO] snapshot org.apache.myfaces.trinidadbuild:maven-faces-plugin:incubator-m1 -SNAPSHOT: checking for updates from people.apache-mirror [WARNING] repository metadata for: 'snapshot org.apache.myfaces.trinidadbuild:ma ven-faces-plugin:incubator-m1-SNAPSHOT' could not be retrieved from repository: people.apache-mirror due to an error: Error transferring file [INFO] Repository 'people.apache-mirror' will be blacklisted -Piyush -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Formatting locale vs. translation locale
Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
Re: [PORTAL] Custom lifecycle?
Arash, Hey Arash, thanks for the links. The problem is that finding an AJAX solution will pretty much trump any other work we have. While certain portal implementations can be exploited to provide what is needed for AJAX, none of them are guaranteed with JSR-168. The real problem with AJAX and portletshas nothing to do with the life cycle. It more has to do with limitations of JSR-168. Let me elaborate. JSR-168 containers do not guarantee that a particular call to a resource is in the same namespace as it's parent application. This is typically the case in WSRP containers. Even assuming we could be connected to the same session as a particular portlet, the session data for a portlet instance is prefixed with a javax prefix and the portlet id. While this is SOMETIMES the same as the namespace, the JSR-168 does not guarantee this and there is no API for getting a hold of the portlet Id. Portlet 2.0 Spec is supposed to have some mechanisms for handling this, but anything we put in place in the mean time to handle AJAX will not work in all containers. Therefore, I'm of the opinion that we should get Trinidad working without AJAX first, making it the most compatible with JSR-168, and then look at possibly enhancing it to take a advantage of some specific portlet container implementations that might be exploited for AJAX. Until the portlet 2.0 specification is released, JSR-168 will not be able to support AJAX in all cases natively, or at the very least not in a fashion that is as secure as the web container. Scott Arash Rajaeeyan wrote: Hello, First let me tell, that since lifecycle of Portlets is different with Servlets, so the same implementation of the JSF life cycle for servlet is not necessarily good for portlets too. I didn't find an exact case in Trinidad sources, but there are should be some facilities similar to tomahawk immediate attributes ( http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works) Which some time short cut the lifecycle. So I think this should be taken into account If we can find a method for handling AJAX requests at same time is also good. The problem is every AJAX call to a portlet will generate a processAction and as a result will refresh all portlets in a page unnecessarily. For more information about this you can see the following articles: http://developers.sun.com/prodtech/portalserver/reference/techart/asynch_rendering.html http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html Arash Rajaeeyan On 10/23/06, Scott O'Bryan [EMAIL PROTECTED] wrote: We discussed this in 10.1.3 about how there is no guarantee that the cleanup will happen if the life cycle is short-circuited.plus we would need a bunch of touch-points. We would need listeners on the following: 1. Initialize before Restore Component Tree 2. Cleanup after Process Events only when Response Complete or Render Response is the next phase 3. Cleanup after Process Events only when Response Complete or Render Response is the next phase. 4. Cleanup after Process Events only when Response Complete or Render Response is the next phase 5. Cleanup after Process Events 2 6. Initialize before Reader Response 7. Cleanup after Reader Response It would be far easier to run the execution code at the beginning and end of the LifeCycle's execute method and at the beginning and end of the lifecycle's render method just to make sure we hit all the touch points. Also, some of the cleanup above (ie. cleaning up before Render Response and then reinitializing could be optimized, but do remember that in the portal, each portlet can recieve multiple render-requests for each action request. So the TrinidadFacesContext object should be the same between those calls to render-request. I've just added some code in 10.1.3 that was causing issues with this and process scope. Of course when dealing with servlets, this all becomes trivial. Now that being said, if you still think LifeCycle listeners are the way to go, I would be happy to explore that option. I know this is the type of stuff that LifeCycle listeners were designed for, but I also know there was a reason that Trinidad used filters instead of lifecycle listeners before. Eliminating the need for filters altogether would be a good thing. Scott Adam Winer wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. What's the advantage of a custom lifecycle over using a phase listener? --Adam
Re: Formatting locale vs. translation locale
+1 for the FormatingLocale(); you mean facesCtx.getViewRoot().getLocale() right? that's what the Trin Number/DateTime currently use when locale not set. -M On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [PORTAL] Custom lifecycle?
Matthias, I think that's true as well. There is no guaranteed order for phase listeners and whatnot. Ideally our initialization needs to happen before other phase listeners run. Scott Matthias Wessendorf wrote: Just a question regarding this: -Isn't it the case that you can't specifiy a *chaining* for PhaseListeners? Only like _a.jar b.jar z_myfaces.jar So when you register 5 for Phase #1 you can have issues with that, right ? At least when one of the PhaseListeners in front your yours does something wrong/ugly? My understanding to a custom lifecycle is that it doesn't bother with the *regular* Lifecycle's PhaseListeners. Thanks, Matthias On 10/22/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. What's the advantage of a custom lifecycle over using a phase listener? --Adam
Re: [PORTAL] Custom lifecycle?
Hi scott, you are right JSR 286 has non of these problems because they have added Resource Serving and Portlet filter concepts: PLT.13 page 67 Resource serving – provides ability for a portlet to serve a resource.. PLT 19 page 199 Portlet filter – allowing on the fly transformations of information in both the request to and the response from a portlet I think if want to add a filter for image and other resources, this should also do the job of ajax calls, and if use another method, we should still find a way for ajax calls and we will probably do same work twice On 10/24/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, Hey Arash, thanks for the links. The problem is that finding an AJAX solution will pretty much trump any other work we have. While certain portal implementations can be exploited to provide what is needed for AJAX, none of them are guaranteed with JSR-168. The real problem with AJAX and portletshas nothing to do with the life cycle. It more has to do with limitations of JSR-168. Let me elaborate. JSR-168 containers do not guarantee that a particular call to a resource is in the same namespace as it's parent application. This is typically the case in WSRP containers. Even assuming we could be connected to the same session as a particular portlet, the session data for a portlet instance is prefixed with a javax prefix and the portlet id. While this is SOMETIMES the same as the namespace, the JSR-168 does not guarantee this and there is no API for getting a hold of the portlet Id. Portlet 2.0 Spec is supposed to have some mechanisms for handling this, but anything we put in place in the mean time to handle AJAX will not work in all containers. Therefore, I'm of the opinion that we should get Trinidad working without AJAX first, making it the most compatible with JSR-168, and then look at possibly enhancing it to take a advantage of some specific portlet container implementations that might be exploited for AJAX. Until the portlet 2.0 specification is released, JSR-168 will not be able to support AJAX in all cases natively, or at the very least not in a fashion that is as secure as the web container. Scott Arash Rajaeeyan wrote: Hello, First let me tell, that since lifecycle of Portlets is different with Servlets, so the same implementation of the JSF life cycle for servlet is not necessarily good for portlets too. I didn't find an exact case in Trinidad sources, but there are should be some facilities similar to tomahawk immediate attributes ( http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works) Which some time short cut the lifecycle. So I think this should be taken into account If we can find a method for handling AJAX requests at same time is also good. The problem is every AJAX call to a portlet will generate a processAction and as a result will refresh all portlets in a page unnecessarily. For more information about this you can see the following articles: http://developers.sun.com/prodtech/portalserver/reference/techart/asynch_rendering.html http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html Arash Rajaeeyan On 10/23/06, Scott O'Bryan [EMAIL PROTECTED] wrote: We discussed this in 10.1.3 about how there is no guarantee that the cleanup will happen if the life cycle is short-circuited.plus we would need a bunch of touch-points. We would need listeners on the following: 1. Initialize before Restore Component Tree 2. Cleanup after Process Events only when Response Complete or Render Response is the next phase 3. Cleanup after Process Events only when Response Complete or Render Response is the next phase. 4. Cleanup after Process Events only when Response Complete or Render Response is the next phase 5. Cleanup after Process Events 2 6. Initialize before Reader Response 7. Cleanup after Reader Response It would be far easier to run the execution code at the beginning and end of the LifeCycle's execute method and at the beginning and end of the lifecycle's render method just to make sure we hit all the touch points. Also, some of the cleanup above (ie. cleaning up before Render Response and then reinitializing could be optimized, but do remember that in the portal, each portlet can recieve multiple render-requests for each action request. So the TrinidadFacesContext object should be the same between those calls to render-request. I've just added some code in 10.1.3 that was causing issues with this and process scope. Of course when dealing with servlets, this all becomes trivial. Now that being said, if you still think LifeCycle listeners are the way to go, I would be happy to explore that option. I know this is the type of stuff that LifeCycle listeners were designed for, but I also know there was a reason that Trinidad used filters instead of lifecycle listeners before. Eliminating the need
Re: [PORTAL] Custom lifecycle?
if we forget about ajax what about immediate, is there any facility in trinidad which shortcuts lifecycle? On 10/24/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, Hey Arash, thanks for the links. The problem is that finding an AJAX solution will pretty much trump any other work we have. While certain portal implementations can be exploited to provide what is needed for AJAX, none of them are guaranteed with JSR-168. The real problem with AJAX and portletshas nothing to do with the life cycle. It more has to do with limitations of JSR-168. Let me elaborate. JSR-168 containers do not guarantee that a particular call to a resource is in the same namespace as it's parent application. This is typically the case in WSRP containers. Even assuming we could be connected to the same session as a particular portlet, the session data for a portlet instance is prefixed with a javax prefix and the portlet id. While this is SOMETIMES the same as the namespace, the JSR-168 does not guarantee this and there is no API for getting a hold of the portlet Id. Portlet 2.0 Spec is supposed to have some mechanisms for handling this, but anything we put in place in the mean time to handle AJAX will not work in all containers. Therefore, I'm of the opinion that we should get Trinidad working without AJAX first, making it the most compatible with JSR-168, and then look at possibly enhancing it to take a advantage of some specific portlet container implementations that might be exploited for AJAX. Until the portlet 2.0 specification is released, JSR-168 will not be able to support AJAX in all cases natively, or at the very least not in a fashion that is as secure as the web container. Scott Arash Rajaeeyan wrote: Hello, First let me tell, that since lifecycle of Portlets is different with Servlets, so the same implementation of the JSF life cycle for servlet is not necessarily good for portlets too. I didn't find an exact case in Trinidad sources, but there are should be some facilities similar to tomahawk immediate attributes ( http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works) Which some time short cut the lifecycle. So I think this should be taken into account If we can find a method for handling AJAX requests at same time is also good. The problem is every AJAX call to a portlet will generate a processAction and as a result will refresh all portlets in a page unnecessarily. For more information about this you can see the following articles: http://developers.sun.com/prodtech/portalserver/reference/techart/asynch_rendering.html http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html Arash Rajaeeyan On 10/23/06, Scott O'Bryan [EMAIL PROTECTED] wrote: We discussed this in 10.1.3 about how there is no guarantee that the cleanup will happen if the life cycle is short-circuited.plus we would need a bunch of touch-points. We would need listeners on the following: 1. Initialize before Restore Component Tree 2. Cleanup after Process Events only when Response Complete or Render Response is the next phase 3. Cleanup after Process Events only when Response Complete or Render Response is the next phase. 4. Cleanup after Process Events only when Response Complete or Render Response is the next phase 5. Cleanup after Process Events 2 6. Initialize before Reader Response 7. Cleanup after Reader Response It would be far easier to run the execution code at the beginning and end of the LifeCycle's execute method and at the beginning and end of the lifecycle's render method just to make sure we hit all the touch points. Also, some of the cleanup above (ie. cleaning up before Render Response and then reinitializing could be optimized, but do remember that in the portal, each portlet can recieve multiple render-requests for each action request. So the TrinidadFacesContext object should be the same between those calls to render-request. I've just added some code in 10.1.3 that was causing issues with this and process scope. Of course when dealing with servlets, this all becomes trivial. Now that being said, if you still think LifeCycle listeners are the way to go, I would be happy to explore that option. I know this is the type of stuff that LifeCycle listeners were designed for, but I also know there was a reason that Trinidad used filters instead of lifecycle listeners before. Eliminating the need for filters altogether would be a good thing. Scott Adam Winer wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already
Re: Re: Formatting locale vs. translation locale
Yep, that's the idea. -- Adam On 10/23/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: +1 for a formatting locale. If I'm understanding you correctly the formatting locale would only be used for formatting, meaning 11-7-06 in the US and 7-11-06 in Germany, but the error string will still use the regular locale... Thanks, Gab Adam Winer wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam
Re: Re: Formatting locale vs. translation locale
Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
