Re: Client-side validation - enhance to match server-side
may be you can use GWT compiler for client side validation as well, it is also under Apache 2 license. On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Arash Rajaeeyan
Re: Client-side validation - enhance to match server-side
the difference is with GWT, user can write java code for client side validation instead of JS. they can compile it with their own Java IDE. but I also agree that adding another dependency to MyFaces is not good, specially dependency to such a big project. On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: I'd be happy to see functionality like this too. The trickiest part is, I think, figuring out how to clear the messages. I agree with Matthias that we don't need GWT. We already have the client-side JS. It's just the code that decides to turn the messages into an alert that is the problem. -- Adam On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
Re: panelNavigation bug in Firefox 2.0 RC3
why not report this bug to firefox developers? On 10/25/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: this same problem (of needing nbsp to display empty table cells) occurred back in the days of Netscape 4.7. It would suck if they've regressed back to that. Back then, we had to solve this by having a special ResponseWriter. The special ResponseWriter would detect if a TD was followed by a /TD with no intervening non-whitespace character, and automatically insert an NBSP for netscape. --arjuna On 10/24/06, Matt Cooper [EMAIL PROTECTED] wrote: Hi Simon, I've seen similar issues to this but not yet with Firefox 2.0. It can be a pretty annoying issue because placing text into something that didn't contain text before may alter its dimensions--even if a specific width and height are specified. When that was the case, I believe we worked around it by specifying either a line-height: 1px; style or possibly an overflow: hidden; style. If the container is larger than a character, then there is nothing to worry about. On a somewhat related note, I'm not sure the DOM structure of the tabs in the navigationPane are even in a format that is very flexible for alternative appearances. I'd be happy to see it restructured to be less reliant on tables--possibly even structured so the DOM elements actually overlap instead of having graphics to give the illusion of overlapping tabs. Thanks, Matt On 10/24/06, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, There's a small bug with panelNavigation in tab mode in Firefox 2.0 (didn't check 1.5) where the tab borders are not rendered. I think it's because Firefox renders some elements only if they contain something. Since tabs structure only use some td for background image, it fails. I think I had the same problem with panelBox and I ended adding a small nbsp; I might have to check. Anyone else has experience with this or comments for the potential fix? Regards, ~ Simon -- Arash Rajaeeyan
Re: Re: Re: Formatting locale vs. translation locale
thanks adam useful hints as usual On 10/25/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, No, there isn't a conflict. Code looking for translations will all use UIViewRoot.getLocale(). BTW, for reading direction, we already have a RequestContext getReadingDirection() that can be overridden using trinidad-config.xml. -- Adam On 10/24/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Adam, let me clear that I think separating Formatting locale and translation locale is a very good idea. there are lots of methods in JSF to get current locale, my point is to make sure these methods don't return some thing in conflict with each other. for example we must make sure the other components on the page you mentioned are not searching for German translation of texts. the same concept can also be extended to direction, users whose language is written from right to left like Hebrew, Arabic and Farsi may prefer their menu, trees, tabs, etc to be right aligned, and behave how they expect even if the text is still in English. for example scroll bars in left side is common in right to left languages, and if your browser has put one scroll bar in left, and a JSF page displayed in the browser has put scroll bar in right side of the page it becomes very confusing. On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: 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 -- Arash Rajaeeyan -- Arash Rajaeeyan
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?
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: who is in charge for JSR 301?
thank you Carsten, you may have seen the portlet patch of shinsuke for tomahawk, we (me and some other developers) want to do polish this patch and do similar thing for trindad and tobago. it will be great if we can have one soloution working for all components under myfaces umbrella and may be even other components. it looks like this target of JSR 301 as an exprienced member of this group, do you have any guidelines for us? On 10/12/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Yes, I'm in the spec group - but upto now I don't know who else from Apache is on. Carsten Matthias Wessendorf wrote: added Carsten On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet. I can jump on that if you guys want. Michael Freedman is the Spec Lead and he is someone I work with on a regular basis. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ -- Arash Rajaeeyan
who is in charge for JSR 301?
hello who is in charge for JSR 301 here? -- Arash Rajaeeyan
Re: MyFaces 1.1.4
although my vote is not counted but that's a good idea just be aware that there are some incompatibilities between those versions. although I don't think those effect trinidad but it is so good to upgrade and be sure those incompatibilities will not affect trinidad On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: anyone mind to use myfaces 1.1.4 instead of 1.1.2? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: [Jira] Portlet Issue
there two kind of portals
some use Servlet classes as a base for Portlet and other Portlet Classes,
and subclasses classes like PortletRequest from HttpServletRequest.
some develop Portlet classes from scratch.
lots of problems arise in second type of portlet API implementation which
the Portlet classes can not be casted to Servlet classes.
IBM websphere is from first kind.
Liferay is second type.
pluto is some thing between:
package org.apache.pluto.internal.impl;
public abstract class PortletRequestImpl extends HttpServletRequestWrapper
implements PortletRequest, InternalPortletRequest {
as you see they have subclasses HttpServletRequestWrapper
so they have all methods of HttpServlet
so I think its better that we don't test portlet patch implementation on
pluto.
On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I added seven issues to the Trinidad Portlet component in Jira and one
to the MyFaces Portlet_Support component. That should get us started.
We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done
before we can start, however.
I do have a fix for MYFACES-1383, but it needs some testing. Hopefully
I'll be able to check it in soon.
Scott
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Arash Rajaeeyan
Re: [Jira] Portlet Issue
Hi scott,
my post was generally about portlet support.
you are right the second type method can be fixed by a wrapper which
implements HttpServlet and wraps Portlet.
I prefer to use a method which works in all portals JSR168, or WSRP and even
in future JSR 286, if some solution works for second type (Not Drived
Classes from HttpServlet) of portals it will work for first type (Drived
Portlet classes from HttpServlet)
I will test every thing with both kind of portals to make sure they both
work fine.
may be we can modify that MyFaces Bridge and add what ever we need to
support trinidad.
trindidad and tomahawk are both under myfaces, and many people including
myself are using both set of components.
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
To answer Mitthias, I'm going to be testing against Pluto and Oracle's
WSRP. I *MAY* add Gridsphere to the test since it's Websphere like.
Now, Arash, you are replying to a different issue. I noticed that
Tomahawk has added support for PortletFilters and I guess I jumped the
gun on wanting to use it. By removing dependencies on the wapper
objects in the filters, we can remove any dependency we have on the
implementation of the particular portal for now. Perhaps we may even
have to depend on our own bridge portlet which (like tomahawk) is
derived off of the MyFaces Bridge. The things that concerns me is that
never will the two run together in a portal environment if we do this.
I have a requirement to allow this stuff to run in a WSRP container
which is more like type 2 of your scenario. Therefore, I am flat
against using an implied implementation (like taking advantage of the
fact that WebSphere wraps httpServletRequest/Response objects. I
*don't* mind providing an interface with various adapters (for each
portal maybe) that could implement these wrapper objects as hopefully
well have something similar in the spec in a year or so.
That being said, while LifeRay is not of the first type you recomended,
someone familiar with the system should be able to provide a wrapper
object for LifeRay's PortletRequest implementation object.
Scott
Arash Rajaeeyan wrote:
there two kind of portals
some use Servlet classes as a base for Portlet and other Portlet
Classes,
and subclasses classes like PortletRequest from HttpServletRequest.
some develop Portlet classes from scratch.
lots of problems arise in second type of portlet API implementation
which
the Portlet classes can not be casted to Servlet classes.
IBM websphere is from first kind.
Liferay is second type.
pluto is some thing between:
package org.apache.pluto.internal.impl;
public abstract class PortletRequestImpl extends
HttpServletRequestWrapper
implements PortletRequest, InternalPortletRequest {
as you see they have subclasses HttpServletRequestWrapper
so they have all methods of HttpServlet
so I think its better that we don't test portlet patch implementation on
pluto.
On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I added seven issues to the Trinidad Portlet component in Jira and
one
to the MyFaces Portlet_Support component. That should get us
started.
We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done
before we can start, however.
I do have a fix for MYFACES-1383, but it needs some testing.
Hopefully
I'll be able to check it in soon.
Scott
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Arash Rajaeeyan
Re: [Jira] Portlet Issue
Hi yes it makes sense. you know the problem is Protlet is more limited than servlet so some Portlet Classes (say PortletRequest) have less methods and properties than their counter part (say HttpServlet) so the wrapper which implements Servlet class and has wrapped a portlet related class inside should return null or throw exception in some special cases. so these wrappers behaviour is not completely same as their http servlet counter parts. I don't know if this functionality are used any where in trinidad or not. as long as I find out in the codes there is no dependency on HttpServlet classes and in most places the JSF classes are used in trinidad. for example in most places FacesContext is used and not ServletContext so there is no problem in returning PortletContext in getFacesContext On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Yeah, that was my origonal thought. I'll reopen MYFACES-1448 which is a task to do just that. All we need is something simple to do the Non-Wrapper initialization code. It would need an init and a destroy as well as a pre-lifecycle and post-lifecycle call, but these could be done with the PortletContext, PortletRequest/Response classes. As for the wrappers, you get me wrong. I'm not wanting to tie myself to HttpServlet stuff at all. Here is my theory about moving the functionality of the wrapper objects to our existing ExternalContext wrapper. If we have an HttpServletRequest/Response then we can simply use the provided wrapper objects. If we don't then we would need to get the original request object and ExternalContext and wrap them overriding only the functionality we need to. The wrapped external context would return a wrapped PortletRequest/PortletResponse/PortletContext object of the appropriate (Action or Render) type. For dispatching your wrapper simply need to take the provided object's wrapped object and pass it into the superclass. Therefore, the external context references a wrapped PortletRequest and Response as well as it's underlying implementation. We'd have to be a bit careful when the objects switch from ActionRequests to RenderRequests, but this should be pretty easy to do. This would allow us to create wrapper objects without actually having them supported by JSR-168 or the need to cast to HttpServlet stuff. Does this make sense? Arash Rajaeeyan wrote: Hi scott, my post was generally about portlet support. you are right the second type method can be fixed by a wrapper which implements HttpServlet and wraps Portlet. I prefer to use a method which works in all portals JSR168, or WSRP and even in future JSR 286, if some solution works for second type (Not Drived Classes from HttpServlet) of portals it will work for first type (Drived Portlet classes from HttpServlet) I will test every thing with both kind of portals to make sure they both work fine. may be we can modify that MyFaces Bridge and add what ever we need to support trinidad. trindidad and tomahawk are both under myfaces, and many people including myself are using both set of components. On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote: To answer Mitthias, I'm going to be testing against Pluto and Oracle's WSRP. I *MAY* add Gridsphere to the test since it's Websphere like. Now, Arash, you are replying to a different issue. I noticed that Tomahawk has added support for PortletFilters and I guess I jumped the gun on wanting to use it. By removing dependencies on the wapper objects in the filters, we can remove any dependency we have on the implementation of the particular portal for now. Perhaps we may even have to depend on our own bridge portlet which (like tomahawk) is derived off of the MyFaces Bridge. The things that concerns me is that never will the two run together in a portal environment if we do this. I have a requirement to allow this stuff to run in a WSRP container which is more like type 2 of your scenario. Therefore, I am flat against using an implied implementation (like taking advantage of the fact that WebSphere wraps httpServletRequest/Response objects. I *don't* mind providing an interface with various adapters (for each portal maybe) that could implement these wrapper objects as hopefully well have something similar in the spec in a year or so. That being said, while LifeRay is not of the first type you recomended, someone familiar with the system should be able to provide a wrapper object for LifeRay's PortletRequest implementation object. Scott Arash Rajaeeyan wrote: there two kind of portals some use Servlet classes as a base for Portlet and other Portlet Classes, and subclasses classes like PortletRequest from HttpServletRequest. some develop Portlet classes from scratch. lots of problems arise in second type of portlet API implementation which the Portlet classes can not be casted to Servlet classes. IBM websphere is from first kind. Liferay is second type. pluto
Re: [Jira] adding new category/component for Portlet ?
hi scot I can't find that portlet component in jira: https://issues.apache.org/jira/browse/ADFFACES can you tell me where should I look for it? On 10/7/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, I'll get some JIRA tasks loaded up for this and you can have at it. We're going to need to make some enhancements to the bridge as well and we might need to have a Trinidad bridge which derives off the Generic Bridge in MyFaces to handle some of the special cases that we can't handle until the JSR-286 is release. There are, however, tons of housekeeping things we need to do as well in order to get things ready. Any help you can give would be much appreciated. I would be interested in understanding how you solved PPR and Filter issue in Tomahawk as well. Scott Adam Winer wrote: That'd be excellent. I know there's also some internal work at Oracle on ADF Faces that should apply to Trinidad - I'll ping the developer about that. -- Adam On 10/6/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: [Jira] adding new category/component for Portlet ?
I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: [Jira] adding new category/component for Portlet ?
hi again, I will wait for them this is a reference to what Shinsuke SUGAYA has done for myfaces I will start studying his solution till admins define those jira tasks http://wiki.apache.org/myfaces/Using_Portlets http://issues.apache.org/jira/browse/MYFACES-434 and here is link to filter: (it may not be latest version) http://portals.apache.org/bridges/multiproject/portals-bridges-portletfilter/xref/org/apache/portals/bridges/portletfilter/ On 10/7/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, I'll get some JIRA tasks loaded up for this and you can have at it. We're going to need to make some enhancements to the bridge as well and we might need to have a Trinidad bridge which derives off the Generic Bridge in MyFaces to handle some of the special cases that we can't handle until the JSR-286 is release. There are, however, tons of housekeeping things we need to do as well in order to get things ready. Any help you can give would be much appreciated. I would be interested in understanding how you solved PPR and Filter issue in Tomahawk as well. Scott Adam Winer wrote: That'd be excellent. I know there's also some internal work at Oracle on ADF Faces that should apply to Trinidad - I'll ping the developer about that. -- Adam On 10/6/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
