You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by a clem <a....@gmail.com> on 2008/03/24 12:15:01 UTC
Ajax, pprPanelGroup and Portlets working together...
Hi,
I ve made working pprPanelGroup in liferay portal. To do that, I had
to patch 2 files of the core and sandbox distributions.
- org/apache/myfaces/custom/dojo/DojoUtils.java
- org/apache/myfaces/custom/ppr/PPRPhaseListener.java
Basically the modifications consist to check wether the request is a
portletrequest or a servletrequest.
It would be nice if ajax related myfaces code could be completely
servlet or portlet context agnostic, for example using a layer of
abstraction on top of servlet and portlet apis.
I also had to patch 6 files of the liferay code base to make the
portal PPR aware. For those who are interested, just let me know.
It is quite simple but it works nice and it is, I think, a more
flexible and powerful approach than the IceFaces one to get Ajax
working within your portlets.
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Scott O'Bryan <da...@gmail.com>.
Plus, for containers like Orchestra which are not necessarily tied to a
specific bridge implementation, it would allow them to work in
environments with older bridges.
Scott
Scott O'Bryan wrote:
> Mike... True, although I did some timing and instanceof's (at least
> in JDK 1.5) seemed to be on order of magnitudes faster then pulling a
> request attribute off of the attribute map. At least on the server I
> was testing. Secondly, Configurators sometimes run prior to the
> bridge for servlets and, quite probably, JSR-286. Therefore, while
> the attribute would eliminate most of the issues to an application
> developer, I'm not sure in the configurator case that it would work in
> all cases. I thought it prudent to include a utility that would work
> in all cases where configurators might be involved.
>
> Scott
>
> Michael Freedman wrote:
>> FYI ... the JSR 301 -- bridge allows such subsystems to avoid this
>> issue because it sets a request attribute one can check to determine
>> if you are running in a portlet environment. The subsystem can check
>> whether this attribute is set/exists using the ExternalContext prior
>> to making any references to a portlet class. So with the
>> standardization of the bridge -- hopefully this problem is "solved".
>> -Mike-
>>
>> Scott O'Bryan wrote:
>>> Well, they are and they aren't related. In Trinidad the
>>> ExternalContextUtils were developed as part of the configurator
>>> system. Just turns out that once we had the utility, it had other
>>> uses outside of the configurator framework. Current (with the
>>> externalContextUtils *IN* the configurator package, I'm also able to
>>> take advantage of caching the request type which makes things a bit
>>> faster. Let me play around with it an see if I can *unmarry* the
>>> two libraries with a minimum of duplicated code.
>>>
>>> Scott
>>>
>>> Ernst Fastl wrote:
>>>> Hi
>>>>
>>>> duplicating code even if just a bare minimum doesn't sound good to
>>>> me. Even if
>>>> option 2 means that 2 jars need to be copied for the configurator
>>>> subsystem
>>>> I think they still belong there. Although probably not very
>>>> problematic it would seem
>>>> strange to me if components which are not directly related to the
>>>> configurator sub-system
>>>> would require myfaces-commons-configurator instead of
>>>> myfaces-commons-utils.
>>>>
>>>> So my +1 goes to option 2.
>>>>
>>>> cheers
>>>>
>>>> Ernst
>>>>
>>>> On Fri, Mar 28, 2008 at 9:28 PM, Scott O'Bryan
>>>> <da...@gmail.com> wrote:
>>>>
>>>>> Okay Okay already.. :) I'll work on getting these in the commons
>>>>> somewhere. The code for the configurators (and my nifty new, much
>>>>> nicer externalContextUtils) is done but I've been wishy washy about
>>>>> where things should go so I haven't created the poms yet. Maybe
>>>>> I can
>>>>> work on that a bit this weekend.
>>>>>
>>>>> That said, I suppose I could ask the group for their preference.
>>>>> The
>>>>> ExternalContextUtils is, undoubtedly, a very handy stand-alone
>>>>> piece of
>>>>> code. Seems you guys really want to use it :).. Where is really
>>>>> shines
>>>>> though (and I suspect most usecases which need this logic would
>>>>> eventually implement this) is when used with configurators. The
>>>>> configurator system I've created will go into it's own module in the
>>>>> commons package. Configurators can be used by simply dropping
>>>>> the jar
>>>>> into your classpath, but if the ExternalContextUtils was put into
>>>>> the
>>>>> commons-utils package (rather then the configurators), then you
>>>>> would
>>>>> need to drop in both. So I guess here is my question for the
>>>>> community
>>>>> and perhaps it will keep me from being wishy washy and actually
>>>>> get this
>>>>> code checked in...
>>>>>
>>>>> 1. Keep the ExternalContextUtils in the myfaces-commons-configurator
>>>>> jar. Dropping this jar in your classpath gives you access to
>>>>> both the
>>>>> ExternalContextUtils as well as the configurator sub-system if
>>>>> you want
>>>>> to use it.
>>>>>
>>>>> 2. Put ExternalContextUtils in the myfaces-commons-util jar, thus
>>>>> making
>>>>> it so that the configurator sub-system requires both jars to be
>>>>> copied
>>>>> into your classpath in order to enable configurators.
>>>>>
>>>>> 3. Put ExternalContextUtils in the myfaces-commons-util jar and
>>>>> duplicate the bare minimum amount of code needed to support the
>>>>> configurators into the configurators package. This way a project
>>>>> can
>>>>> drop in the configurator package if they want configurators, and the
>>>>> util package if they want ExternalContextUtils and both jars will
>>>>> operate independently of one another.
>>>>>
>>>>> IMO option 3 seemed kind of cool to start off with, but I was
>>>>> doing some
>>>>> experimenting with the configurators and found option 1 was much
>>>>> cleaner
>>>>> on some of the new API's I've been adding. In other words, one
>>>>> of the
>>>>> things I did to make configurators run more efficiently is to take
>>>>> advantage of an enumeration provided by the ExternalContextUtils
>>>>> within
>>>>> the configurator API. In order to use these enhancements as
>>>>> written, 1
>>>>> or 2 might be the best.
>>>>>
>>>>> Any preferences?
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>> a clem wrote:
>>>>> > yep, it seems that ExternalContextUtils is already the
>>>>> abstraction on
>>>>> > top of servlet and portlet apis i'm talking about. ;)
>>>>> > And it is using reflection to dispatch the call either to
>>>>> portlet or
>>>>> > servlet api. Using reflection means that ExternalContextUtils
>>>>> has only
>>>>> > an 'implicit' dependency on both apis meaning that type
>>>>> checking is
>>>>> > delayed to runtime (like dynamic languages do). Going further,
>>>>> with
>>>>> > this mechanism we could removed explicit dependency (compile time
>>>>> > checked) on servlet api too!! ;)
>>>>> > So sorry for my misunderstanding and Good idea Scott!! ;)
>>>>> >
>>>>> > On Fri, Mar 28, 2008 at 9:53 AM, a clem <a....@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> >> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl
>>>>> <er...@gmail.com> wrote:
>>>>> >> > +1 for ExternalContextUtils
>>>>> >> > Good idea Scott
>>>>> >> >
>>>>> >> > In this case I wait for those utils before doing the
>>>>> changes in the
>>>>> >> > PPRPhaseListener
>>>>> >> >
>>>>> >> > greez
>>>>> >> >
>>>>> >> > E
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan
>>>>> <da...@gmail.com> wrote:
>>>>> >> > > Take a look at Trinidad's ExternalContextUtils class.
>>>>> It uses
>>>>> >> > > reflection. I'm also going to try to get something
>>>>> like this in the
>>>>> >> > > myfaces commons, probably in the configurator package
>>>>> if I end up
>>>>> >> > > submitting my current code.
>>>>> >> > >
>>>>> >> > > If you don't have time to find the ExternalContextUtils
>>>>> on your own,
>>>>> >> > > I'll try to post some source tomorrow.
>>>>> >> > >
>>>>> >> > > Scott
>>>>> >> > >
>>>>> >> > >
>>>>> >> > >
>>>>> >> > > Leonardo Uribe wrote:
>>>>> >> > > > Hi
>>>>> >> > > >
>>>>> >> > > > I have seen lines like this on the attached files:
>>>>> >> > > >
>>>>> >> > > > //Don't do the rendering twice
>>>>> >> > > > if (request instanceof PortletRequest &&
>>>>> >> > > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR)
>>>>> != null) {
>>>>> >> > > > return;
>>>>> >> > > > }
>>>>> >> > > >
>>>>> >> > > > The problem here is that doing this makes that
>>>>> tomahawk requires
>>>>> >> > > > portlet api to work, in non portlet environments.
>>>>> >> > > >
>>>>> >> > > > The same problem is present on MYFACES-434 patch.
>>>>> >> > > >
>>>>> >> > > > Can anyone suggest a way to avoid this dependency? or
>>>>> we should put
>>>>> >> > > > portlet api as compile dependency for tomahawk?
>>>>> >>
>>>>> >> I don't think this is a problem to have a dependancy on a
>>>>> standard API
>>>>> >> since this an API (not an implementation) and a standard one.
>>>>> >> This is known as the pattern 'dependency inversion'.
>>>>> >> One alternative could be to develop a abstraction layer on
>>>>> top of the
>>>>> >> standard servlet and portlet apis (to hide them).
>>>>> >>
>>>>> >> regards
>>>>> >>
>>>>> >> > > >
>>>>> >> > > > regards
>>>>> >> > > >
>>>>> >> > > > Leonardo Uribe
>>>>> >> > > >
>>>>> >> > > >
>>>>> >> > >
>>>>> >> > >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Scott O'Bryan <da...@gmail.com>.
Mike... True, although I did some timing and instanceof's (at least in
JDK 1.5) seemed to be on order of magnitudes faster then pulling a
request attribute off of the attribute map. At least on the server I
was testing. Secondly, Configurators sometimes run prior to the bridge
for servlets and, quite probably, JSR-286. Therefore, while the
attribute would eliminate most of the issues to an application
developer, I'm not sure in the configurator case that it would work in
all cases. I thought it prudent to include a utility that would work in
all cases where configurators might be involved.
Scott
Michael Freedman wrote:
> FYI ... the JSR 301 -- bridge allows such subsystems to avoid this
> issue because it sets a request attribute one can check to determine
> if you are running in a portlet environment. The subsystem can check
> whether this attribute is set/exists using the ExternalContext prior
> to making any references to a portlet class. So with the
> standardization of the bridge -- hopefully this problem is "solved".
> -Mike-
>
> Scott O'Bryan wrote:
>> Well, they are and they aren't related. In Trinidad the
>> ExternalContextUtils were developed as part of the configurator
>> system. Just turns out that once we had the utility, it had other
>> uses outside of the configurator framework. Current (with the
>> externalContextUtils *IN* the configurator package, I'm also able to
>> take advantage of caching the request type which makes things a bit
>> faster. Let me play around with it an see if I can *unmarry* the two
>> libraries with a minimum of duplicated code.
>>
>> Scott
>>
>> Ernst Fastl wrote:
>>> Hi
>>>
>>> duplicating code even if just a bare minimum doesn't sound good to
>>> me. Even if
>>> option 2 means that 2 jars need to be copied for the configurator
>>> subsystem
>>> I think they still belong there. Although probably not very
>>> problematic it would seem
>>> strange to me if components which are not directly related to the
>>> configurator sub-system
>>> would require myfaces-commons-configurator instead of
>>> myfaces-commons-utils.
>>>
>>> So my +1 goes to option 2.
>>>
>>> cheers
>>>
>>> Ernst
>>>
>>> On Fri, Mar 28, 2008 at 9:28 PM, Scott O'Bryan <da...@gmail.com>
>>> wrote:
>>>
>>>> Okay Okay already.. :) I'll work on getting these in the commons
>>>> somewhere. The code for the configurators (and my nifty new, much
>>>> nicer externalContextUtils) is done but I've been wishy washy about
>>>> where things should go so I haven't created the poms yet. Maybe I
>>>> can
>>>> work on that a bit this weekend.
>>>>
>>>> That said, I suppose I could ask the group for their preference. The
>>>> ExternalContextUtils is, undoubtedly, a very handy stand-alone
>>>> piece of
>>>> code. Seems you guys really want to use it :).. Where is really
>>>> shines
>>>> though (and I suspect most usecases which need this logic would
>>>> eventually implement this) is when used with configurators. The
>>>> configurator system I've created will go into it's own module in the
>>>> commons package. Configurators can be used by simply dropping the
>>>> jar
>>>> into your classpath, but if the ExternalContextUtils was put into the
>>>> commons-utils package (rather then the configurators), then you would
>>>> need to drop in both. So I guess here is my question for the
>>>> community
>>>> and perhaps it will keep me from being wishy washy and actually
>>>> get this
>>>> code checked in...
>>>>
>>>> 1. Keep the ExternalContextUtils in the myfaces-commons-configurator
>>>> jar. Dropping this jar in your classpath gives you access to both
>>>> the
>>>> ExternalContextUtils as well as the configurator sub-system if you
>>>> want
>>>> to use it.
>>>>
>>>> 2. Put ExternalContextUtils in the myfaces-commons-util jar, thus
>>>> making
>>>> it so that the configurator sub-system requires both jars to be
>>>> copied
>>>> into your classpath in order to enable configurators.
>>>>
>>>> 3. Put ExternalContextUtils in the myfaces-commons-util jar and
>>>> duplicate the bare minimum amount of code needed to support the
>>>> configurators into the configurators package. This way a project can
>>>> drop in the configurator package if they want configurators, and the
>>>> util package if they want ExternalContextUtils and both jars will
>>>> operate independently of one another.
>>>>
>>>> IMO option 3 seemed kind of cool to start off with, but I was
>>>> doing some
>>>> experimenting with the configurators and found option 1 was much
>>>> cleaner
>>>> on some of the new API's I've been adding. In other words, one of
>>>> the
>>>> things I did to make configurators run more efficiently is to take
>>>> advantage of an enumeration provided by the ExternalContextUtils
>>>> within
>>>> the configurator API. In order to use these enhancements as
>>>> written, 1
>>>> or 2 might be the best.
>>>>
>>>> Any preferences?
>>>>
>>>> Scott
>>>>
>>>>
>>>>
>>>> a clem wrote:
>>>> > yep, it seems that ExternalContextUtils is already the
>>>> abstraction on
>>>> > top of servlet and portlet apis i'm talking about. ;)
>>>> > And it is using reflection to dispatch the call either to
>>>> portlet or
>>>> > servlet api. Using reflection means that ExternalContextUtils
>>>> has only
>>>> > an 'implicit' dependency on both apis meaning that type
>>>> checking is
>>>> > delayed to runtime (like dynamic languages do). Going further, with
>>>> > this mechanism we could removed explicit dependency (compile time
>>>> > checked) on servlet api too!! ;)
>>>> > So sorry for my misunderstanding and Good idea Scott!! ;)
>>>> >
>>>> > On Fri, Mar 28, 2008 at 9:53 AM, a clem <a....@gmail.com>
>>>> wrote:
>>>> >
>>>> >> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl
>>>> <er...@gmail.com> wrote:
>>>> >> > +1 for ExternalContextUtils
>>>> >> > Good idea Scott
>>>> >> >
>>>> >> > In this case I wait for those utils before doing the
>>>> changes in the
>>>> >> > PPRPhaseListener
>>>> >> >
>>>> >> > greez
>>>> >> >
>>>> >> > E
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan
>>>> <da...@gmail.com> wrote:
>>>> >> > > Take a look at Trinidad's ExternalContextUtils class. It
>>>> uses
>>>> >> > > reflection. I'm also going to try to get something like
>>>> this in the
>>>> >> > > myfaces commons, probably in the configurator package if
>>>> I end up
>>>> >> > > submitting my current code.
>>>> >> > >
>>>> >> > > If you don't have time to find the ExternalContextUtils
>>>> on your own,
>>>> >> > > I'll try to post some source tomorrow.
>>>> >> > >
>>>> >> > > Scott
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > > Leonardo Uribe wrote:
>>>> >> > > > Hi
>>>> >> > > >
>>>> >> > > > I have seen lines like this on the attached files:
>>>> >> > > >
>>>> >> > > > //Don't do the rendering twice
>>>> >> > > > if (request instanceof PortletRequest &&
>>>> >> > > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR)
>>>> != null) {
>>>> >> > > > return;
>>>> >> > > > }
>>>> >> > > >
>>>> >> > > > The problem here is that doing this makes that
>>>> tomahawk requires
>>>> >> > > > portlet api to work, in non portlet environments.
>>>> >> > > >
>>>> >> > > > The same problem is present on MYFACES-434 patch.
>>>> >> > > >
>>>> >> > > > Can anyone suggest a way to avoid this dependency? or
>>>> we should put
>>>> >> > > > portlet api as compile dependency for tomahawk?
>>>> >>
>>>> >> I don't think this is a problem to have a dependancy on a
>>>> standard API
>>>> >> since this an API (not an implementation) and a standard one.
>>>> >> This is known as the pattern 'dependency inversion'.
>>>> >> One alternative could be to develop a abstraction layer on top
>>>> of the
>>>> >> standard servlet and portlet apis (to hide them).
>>>> >>
>>>> >> regards
>>>> >>
>>>> >> > > >
>>>> >> > > > regards
>>>> >> > > >
>>>> >> > > > Leonardo Uribe
>>>> >> > > >
>>>> >> > > >
>>>> >> > >
>>>> >> > >
>>>> >> >
>>>> >>
>>>> >>
>>>>
>>>>
>>>>
>>
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Michael Freedman <mi...@oracle.com>.
FYI ... the JSR 301 -- bridge allows such subsystems to avoid this issue
because it sets a request attribute one can check to determine if you
are running in a portlet environment. The subsystem can check whether
this attribute is set/exists using the ExternalContext prior to making
any references to a portlet class. So with the standardization of the
bridge -- hopefully this problem is "solved".
-Mike-
Scott O'Bryan wrote:
> Well, they are and they aren't related. In Trinidad the
> ExternalContextUtils were developed as part of the configurator
> system. Just turns out that once we had the utility, it had other
> uses outside of the configurator framework. Current (with the
> externalContextUtils *IN* the configurator package, I'm also able to
> take advantage of caching the request type which makes things a bit
> faster. Let me play around with it an see if I can *unmarry* the two
> libraries with a minimum of duplicated code.
>
> Scott
>
> Ernst Fastl wrote:
>> Hi
>>
>> duplicating code even if just a bare minimum doesn't sound good to
>> me. Even if
>> option 2 means that 2 jars need to be copied for the configurator
>> subsystem
>> I think they still belong there. Although probably not very
>> problematic it would seem
>> strange to me if components which are not directly related to the
>> configurator sub-system
>> would require myfaces-commons-configurator instead of
>> myfaces-commons-utils.
>>
>> So my +1 goes to option 2.
>>
>> cheers
>>
>> Ernst
>>
>> On Fri, Mar 28, 2008 at 9:28 PM, Scott O'Bryan <da...@gmail.com>
>> wrote:
>>
>>> Okay Okay already.. :) I'll work on getting these in the commons
>>> somewhere. The code for the configurators (and my nifty new, much
>>> nicer externalContextUtils) is done but I've been wishy washy about
>>> where things should go so I haven't created the poms yet. Maybe I can
>>> work on that a bit this weekend.
>>>
>>> That said, I suppose I could ask the group for their preference. The
>>> ExternalContextUtils is, undoubtedly, a very handy stand-alone
>>> piece of
>>> code. Seems you guys really want to use it :).. Where is really
>>> shines
>>> though (and I suspect most usecases which need this logic would
>>> eventually implement this) is when used with configurators. The
>>> configurator system I've created will go into it's own module in the
>>> commons package. Configurators can be used by simply dropping the jar
>>> into your classpath, but if the ExternalContextUtils was put into the
>>> commons-utils package (rather then the configurators), then you would
>>> need to drop in both. So I guess here is my question for the
>>> community
>>> and perhaps it will keep me from being wishy washy and actually get
>>> this
>>> code checked in...
>>>
>>> 1. Keep the ExternalContextUtils in the myfaces-commons-configurator
>>> jar. Dropping this jar in your classpath gives you access to both the
>>> ExternalContextUtils as well as the configurator sub-system if you
>>> want
>>> to use it.
>>>
>>> 2. Put ExternalContextUtils in the myfaces-commons-util jar, thus
>>> making
>>> it so that the configurator sub-system requires both jars to be copied
>>> into your classpath in order to enable configurators.
>>>
>>> 3. Put ExternalContextUtils in the myfaces-commons-util jar and
>>> duplicate the bare minimum amount of code needed to support the
>>> configurators into the configurators package. This way a project can
>>> drop in the configurator package if they want configurators, and the
>>> util package if they want ExternalContextUtils and both jars will
>>> operate independently of one another.
>>>
>>> IMO option 3 seemed kind of cool to start off with, but I was doing
>>> some
>>> experimenting with the configurators and found option 1 was much
>>> cleaner
>>> on some of the new API's I've been adding. In other words, one of the
>>> things I did to make configurators run more efficiently is to take
>>> advantage of an enumeration provided by the ExternalContextUtils
>>> within
>>> the configurator API. In order to use these enhancements as
>>> written, 1
>>> or 2 might be the best.
>>>
>>> Any preferences?
>>>
>>> Scott
>>>
>>>
>>>
>>> a clem wrote:
>>> > yep, it seems that ExternalContextUtils is already the
>>> abstraction on
>>> > top of servlet and portlet apis i'm talking about. ;)
>>> > And it is using reflection to dispatch the call either to portlet or
>>> > servlet api. Using reflection means that ExternalContextUtils has
>>> only
>>> > an 'implicit' dependency on both apis meaning that type checking is
>>> > delayed to runtime (like dynamic languages do). Going further, with
>>> > this mechanism we could removed explicit dependency (compile time
>>> > checked) on servlet api too!! ;)
>>> > So sorry for my misunderstanding and Good idea Scott!! ;)
>>> >
>>> > On Fri, Mar 28, 2008 at 9:53 AM, a clem <a....@gmail.com>
>>> wrote:
>>> >
>>> >> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl
>>> <er...@gmail.com> wrote:
>>> >> > +1 for ExternalContextUtils
>>> >> > Good idea Scott
>>> >> >
>>> >> > In this case I wait for those utils before doing the changes
>>> in the
>>> >> > PPRPhaseListener
>>> >> >
>>> >> > greez
>>> >> >
>>> >> > E
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan
>>> <da...@gmail.com> wrote:
>>> >> > > Take a look at Trinidad's ExternalContextUtils class. It
>>> uses
>>> >> > > reflection. I'm also going to try to get something like
>>> this in the
>>> >> > > myfaces commons, probably in the configurator package if
>>> I end up
>>> >> > > submitting my current code.
>>> >> > >
>>> >> > > If you don't have time to find the ExternalContextUtils
>>> on your own,
>>> >> > > I'll try to post some source tomorrow.
>>> >> > >
>>> >> > > Scott
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > Leonardo Uribe wrote:
>>> >> > > > Hi
>>> >> > > >
>>> >> > > > I have seen lines like this on the attached files:
>>> >> > > >
>>> >> > > > //Don't do the rendering twice
>>> >> > > > if (request instanceof PortletRequest &&
>>> >> > > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR)
>>> != null) {
>>> >> > > > return;
>>> >> > > > }
>>> >> > > >
>>> >> > > > The problem here is that doing this makes that tomahawk
>>> requires
>>> >> > > > portlet api to work, in non portlet environments.
>>> >> > > >
>>> >> > > > The same problem is present on MYFACES-434 patch.
>>> >> > > >
>>> >> > > > Can anyone suggest a way to avoid this dependency? or
>>> we should put
>>> >> > > > portlet api as compile dependency for tomahawk?
>>> >>
>>> >> I don't think this is a problem to have a dependancy on a
>>> standard API
>>> >> since this an API (not an implementation) and a standard one.
>>> >> This is known as the pattern 'dependency inversion'.
>>> >> One alternative could be to develop a abstraction layer on top
>>> of the
>>> >> standard servlet and portlet apis (to hide them).
>>> >>
>>> >> regards
>>> >>
>>> >> > > >
>>> >> > > > regards
>>> >> > > >
>>> >> > > > Leonardo Uribe
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>>
>>>
>>>
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Scott O'Bryan <da...@gmail.com>.
Well, they are and they aren't related. In Trinidad the
ExternalContextUtils were developed as part of the configurator system.
Just turns out that once we had the utility, it had other uses outside
of the configurator framework. Current (with the externalContextUtils
*IN* the configurator package, I'm also able to take advantage of
caching the request type which makes things a bit faster. Let me play
around with it an see if I can *unmarry* the two libraries with a
minimum of duplicated code.
Scott
Ernst Fastl wrote:
> Hi
>
> duplicating code even if just a bare minimum doesn't sound good to me. Even if
> option 2 means that 2 jars need to be copied for the configurator subsystem
> I think they still belong there. Although probably not very
> problematic it would seem
> strange to me if components which are not directly related to the
> configurator sub-system
> would require myfaces-commons-configurator instead of myfaces-commons-utils.
>
> So my +1 goes to option 2.
>
> cheers
>
> Ernst
>
> On Fri, Mar 28, 2008 at 9:28 PM, Scott O'Bryan <da...@gmail.com> wrote:
>
>> Okay Okay already.. :) I'll work on getting these in the commons
>> somewhere. The code for the configurators (and my nifty new, much
>> nicer externalContextUtils) is done but I've been wishy washy about
>> where things should go so I haven't created the poms yet. Maybe I can
>> work on that a bit this weekend.
>>
>> That said, I suppose I could ask the group for their preference. The
>> ExternalContextUtils is, undoubtedly, a very handy stand-alone piece of
>> code. Seems you guys really want to use it :).. Where is really shines
>> though (and I suspect most usecases which need this logic would
>> eventually implement this) is when used with configurators. The
>> configurator system I've created will go into it's own module in the
>> commons package. Configurators can be used by simply dropping the jar
>> into your classpath, but if the ExternalContextUtils was put into the
>> commons-utils package (rather then the configurators), then you would
>> need to drop in both. So I guess here is my question for the community
>> and perhaps it will keep me from being wishy washy and actually get this
>> code checked in...
>>
>> 1. Keep the ExternalContextUtils in the myfaces-commons-configurator
>> jar. Dropping this jar in your classpath gives you access to both the
>> ExternalContextUtils as well as the configurator sub-system if you want
>> to use it.
>>
>> 2. Put ExternalContextUtils in the myfaces-commons-util jar, thus making
>> it so that the configurator sub-system requires both jars to be copied
>> into your classpath in order to enable configurators.
>>
>> 3. Put ExternalContextUtils in the myfaces-commons-util jar and
>> duplicate the bare minimum amount of code needed to support the
>> configurators into the configurators package. This way a project can
>> drop in the configurator package if they want configurators, and the
>> util package if they want ExternalContextUtils and both jars will
>> operate independently of one another.
>>
>> IMO option 3 seemed kind of cool to start off with, but I was doing some
>> experimenting with the configurators and found option 1 was much cleaner
>> on some of the new API's I've been adding. In other words, one of the
>> things I did to make configurators run more efficiently is to take
>> advantage of an enumeration provided by the ExternalContextUtils within
>> the configurator API. In order to use these enhancements as written, 1
>> or 2 might be the best.
>>
>> Any preferences?
>>
>> Scott
>>
>>
>>
>> a clem wrote:
>> > yep, it seems that ExternalContextUtils is already the abstraction on
>> > top of servlet and portlet apis i'm talking about. ;)
>> > And it is using reflection to dispatch the call either to portlet or
>> > servlet api. Using reflection means that ExternalContextUtils has only
>> > an 'implicit' dependency on both apis meaning that type checking is
>> > delayed to runtime (like dynamic languages do). Going further, with
>> > this mechanism we could removed explicit dependency (compile time
>> > checked) on servlet api too!! ;)
>> > So sorry for my misunderstanding and Good idea Scott!! ;)
>> >
>> > On Fri, Mar 28, 2008 at 9:53 AM, a clem <a....@gmail.com> wrote:
>> >
>> >> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl <er...@gmail.com> wrote:
>> >> > +1 for ExternalContextUtils
>> >> > Good idea Scott
>> >> >
>> >> > In this case I wait for those utils before doing the changes in the
>> >> > PPRPhaseListener
>> >> >
>> >> > greez
>> >> >
>> >> > E
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan <da...@gmail.com> wrote:
>> >> > > Take a look at Trinidad's ExternalContextUtils class. It uses
>> >> > > reflection. I'm also going to try to get something like this in the
>> >> > > myfaces commons, probably in the configurator package if I end up
>> >> > > submitting my current code.
>> >> > >
>> >> > > If you don't have time to find the ExternalContextUtils on your own,
>> >> > > I'll try to post some source tomorrow.
>> >> > >
>> >> > > Scott
>> >> > >
>> >> > >
>> >> > >
>> >> > > Leonardo Uribe wrote:
>> >> > > > Hi
>> >> > > >
>> >> > > > I have seen lines like this on the attached files:
>> >> > > >
>> >> > > > //Don't do the rendering twice
>> >> > > > if (request instanceof PortletRequest &&
>> >> > > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
>> >> > > > return;
>> >> > > > }
>> >> > > >
>> >> > > > The problem here is that doing this makes that tomahawk requires
>> >> > > > portlet api to work, in non portlet environments.
>> >> > > >
>> >> > > > The same problem is present on MYFACES-434 patch.
>> >> > > >
>> >> > > > Can anyone suggest a way to avoid this dependency? or we should put
>> >> > > > portlet api as compile dependency for tomahawk?
>> >>
>> >> I don't think this is a problem to have a dependancy on a standard API
>> >> since this an API (not an implementation) and a standard one.
>> >> This is known as the pattern 'dependency inversion'.
>> >> One alternative could be to develop a abstraction layer on top of the
>> >> standard servlet and portlet apis (to hide them).
>> >>
>> >> regards
>> >>
>> >> > > >
>> >> > > > regards
>> >> > > >
>> >> > > > Leonardo Uribe
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>>
>>
>>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Ernst Fastl <er...@gmail.com>.
Hi
duplicating code even if just a bare minimum doesn't sound good to me. Even if
option 2 means that 2 jars need to be copied for the configurator subsystem
I think they still belong there. Although probably not very
problematic it would seem
strange to me if components which are not directly related to the
configurator sub-system
would require myfaces-commons-configurator instead of myfaces-commons-utils.
So my +1 goes to option 2.
cheers
Ernst
On Fri, Mar 28, 2008 at 9:28 PM, Scott O'Bryan <da...@gmail.com> wrote:
> Okay Okay already.. :) I'll work on getting these in the commons
> somewhere. The code for the configurators (and my nifty new, much
> nicer externalContextUtils) is done but I've been wishy washy about
> where things should go so I haven't created the poms yet. Maybe I can
> work on that a bit this weekend.
>
> That said, I suppose I could ask the group for their preference. The
> ExternalContextUtils is, undoubtedly, a very handy stand-alone piece of
> code. Seems you guys really want to use it :).. Where is really shines
> though (and I suspect most usecases which need this logic would
> eventually implement this) is when used with configurators. The
> configurator system I've created will go into it's own module in the
> commons package. Configurators can be used by simply dropping the jar
> into your classpath, but if the ExternalContextUtils was put into the
> commons-utils package (rather then the configurators), then you would
> need to drop in both. So I guess here is my question for the community
> and perhaps it will keep me from being wishy washy and actually get this
> code checked in...
>
> 1. Keep the ExternalContextUtils in the myfaces-commons-configurator
> jar. Dropping this jar in your classpath gives you access to both the
> ExternalContextUtils as well as the configurator sub-system if you want
> to use it.
>
> 2. Put ExternalContextUtils in the myfaces-commons-util jar, thus making
> it so that the configurator sub-system requires both jars to be copied
> into your classpath in order to enable configurators.
>
> 3. Put ExternalContextUtils in the myfaces-commons-util jar and
> duplicate the bare minimum amount of code needed to support the
> configurators into the configurators package. This way a project can
> drop in the configurator package if they want configurators, and the
> util package if they want ExternalContextUtils and both jars will
> operate independently of one another.
>
> IMO option 3 seemed kind of cool to start off with, but I was doing some
> experimenting with the configurators and found option 1 was much cleaner
> on some of the new API's I've been adding. In other words, one of the
> things I did to make configurators run more efficiently is to take
> advantage of an enumeration provided by the ExternalContextUtils within
> the configurator API. In order to use these enhancements as written, 1
> or 2 might be the best.
>
> Any preferences?
>
> Scott
>
>
>
> a clem wrote:
> > yep, it seems that ExternalContextUtils is already the abstraction on
> > top of servlet and portlet apis i'm talking about. ;)
> > And it is using reflection to dispatch the call either to portlet or
> > servlet api. Using reflection means that ExternalContextUtils has only
> > an 'implicit' dependency on both apis meaning that type checking is
> > delayed to runtime (like dynamic languages do). Going further, with
> > this mechanism we could removed explicit dependency (compile time
> > checked) on servlet api too!! ;)
> > So sorry for my misunderstanding and Good idea Scott!! ;)
> >
> > On Fri, Mar 28, 2008 at 9:53 AM, a clem <a....@gmail.com> wrote:
> >
> >> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl <er...@gmail.com> wrote:
> >> > +1 for ExternalContextUtils
> >> > Good idea Scott
> >> >
> >> > In this case I wait for those utils before doing the changes in the
> >> > PPRPhaseListener
> >> >
> >> > greez
> >> >
> >> > E
> >> >
> >> >
> >> >
> >> > On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan <da...@gmail.com> wrote:
> >> > > Take a look at Trinidad's ExternalContextUtils class. It uses
> >> > > reflection. I'm also going to try to get something like this in the
> >> > > myfaces commons, probably in the configurator package if I end up
> >> > > submitting my current code.
> >> > >
> >> > > If you don't have time to find the ExternalContextUtils on your own,
> >> > > I'll try to post some source tomorrow.
> >> > >
> >> > > Scott
> >> > >
> >> > >
> >> > >
> >> > > Leonardo Uribe wrote:
> >> > > > Hi
> >> > > >
> >> > > > I have seen lines like this on the attached files:
> >> > > >
> >> > > > //Don't do the rendering twice
> >> > > > if (request instanceof PortletRequest &&
> >> > > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
> >> > > > return;
> >> > > > }
> >> > > >
> >> > > > The problem here is that doing this makes that tomahawk requires
> >> > > > portlet api to work, in non portlet environments.
> >> > > >
> >> > > > The same problem is present on MYFACES-434 patch.
> >> > > >
> >> > > > Can anyone suggest a way to avoid this dependency? or we should put
> >> > > > portlet api as compile dependency for tomahawk?
> >>
> >> I don't think this is a problem to have a dependancy on a standard API
> >> since this an API (not an implementation) and a standard one.
> >> This is known as the pattern 'dependency inversion'.
> >> One alternative could be to develop a abstraction layer on top of the
> >> standard servlet and portlet apis (to hide them).
> >>
> >> regards
> >>
> >> > > >
> >> > > > regards
> >> > > >
> >> > > > Leonardo Uribe
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >>
>
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Scott O'Bryan <da...@gmail.com>.
Okay Okay already.. :) I'll work on getting these in the commons
somewhere. The code for the configurators (and my nifty new, much
nicer externalContextUtils) is done but I've been wishy washy about
where things should go so I haven't created the poms yet. Maybe I can
work on that a bit this weekend.
That said, I suppose I could ask the group for their preference. The
ExternalContextUtils is, undoubtedly, a very handy stand-alone piece of
code. Seems you guys really want to use it :).. Where is really shines
though (and I suspect most usecases which need this logic would
eventually implement this) is when used with configurators. The
configurator system I've created will go into it's own module in the
commons package. Configurators can be used by simply dropping the jar
into your classpath, but if the ExternalContextUtils was put into the
commons-utils package (rather then the configurators), then you would
need to drop in both. So I guess here is my question for the community
and perhaps it will keep me from being wishy washy and actually get this
code checked in...
1. Keep the ExternalContextUtils in the myfaces-commons-configurator
jar. Dropping this jar in your classpath gives you access to both the
ExternalContextUtils as well as the configurator sub-system if you want
to use it.
2. Put ExternalContextUtils in the myfaces-commons-util jar, thus making
it so that the configurator sub-system requires both jars to be copied
into your classpath in order to enable configurators.
3. Put ExternalContextUtils in the myfaces-commons-util jar and
duplicate the bare minimum amount of code needed to support the
configurators into the configurators package. This way a project can
drop in the configurator package if they want configurators, and the
util package if they want ExternalContextUtils and both jars will
operate independently of one another.
IMO option 3 seemed kind of cool to start off with, but I was doing some
experimenting with the configurators and found option 1 was much cleaner
on some of the new API's I've been adding. In other words, one of the
things I did to make configurators run more efficiently is to take
advantage of an enumeration provided by the ExternalContextUtils within
the configurator API. In order to use these enhancements as written, 1
or 2 might be the best.
Any preferences?
Scott
a clem wrote:
> yep, it seems that ExternalContextUtils is already the abstraction on
> top of servlet and portlet apis i'm talking about. ;)
> And it is using reflection to dispatch the call either to portlet or
> servlet api. Using reflection means that ExternalContextUtils has only
> an 'implicit' dependency on both apis meaning that type checking is
> delayed to runtime (like dynamic languages do). Going further, with
> this mechanism we could removed explicit dependency (compile time
> checked) on servlet api too!! ;)
> So sorry for my misunderstanding and Good idea Scott!! ;)
>
> On Fri, Mar 28, 2008 at 9:53 AM, a clem <a....@gmail.com> wrote:
>
>> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl <er...@gmail.com> wrote:
>> > +1 for ExternalContextUtils
>> > Good idea Scott
>> >
>> > In this case I wait for those utils before doing the changes in the
>> > PPRPhaseListener
>> >
>> > greez
>> >
>> > E
>> >
>> >
>> >
>> > On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan <da...@gmail.com> wrote:
>> > > Take a look at Trinidad's ExternalContextUtils class. It uses
>> > > reflection. I'm also going to try to get something like this in the
>> > > myfaces commons, probably in the configurator package if I end up
>> > > submitting my current code.
>> > >
>> > > If you don't have time to find the ExternalContextUtils on your own,
>> > > I'll try to post some source tomorrow.
>> > >
>> > > Scott
>> > >
>> > >
>> > >
>> > > Leonardo Uribe wrote:
>> > > > Hi
>> > > >
>> > > > I have seen lines like this on the attached files:
>> > > >
>> > > > //Don't do the rendering twice
>> > > > if (request instanceof PortletRequest &&
>> > > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
>> > > > return;
>> > > > }
>> > > >
>> > > > The problem here is that doing this makes that tomahawk requires
>> > > > portlet api to work, in non portlet environments.
>> > > >
>> > > > The same problem is present on MYFACES-434 patch.
>> > > >
>> > > > Can anyone suggest a way to avoid this dependency? or we should put
>> > > > portlet api as compile dependency for tomahawk?
>>
>> I don't think this is a problem to have a dependancy on a standard API
>> since this an API (not an implementation) and a standard one.
>> This is known as the pattern 'dependency inversion'.
>> One alternative could be to develop a abstraction layer on top of the
>> standard servlet and portlet apis (to hide them).
>>
>> regards
>>
>> > > >
>> > > > regards
>> > > >
>> > > > Leonardo Uribe
>> > > >
>> > > >
>> > >
>> > >
>> >
>>
>>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by a clem <a....@gmail.com>.
yep, it seems that ExternalContextUtils is already the abstraction on
top of servlet and portlet apis i'm talking about. ;)
And it is using reflection to dispatch the call either to portlet or
servlet api. Using reflection means that ExternalContextUtils has only
an 'implicit' dependency on both apis meaning that type checking is
delayed to runtime (like dynamic languages do). Going further, with
this mechanism we could removed explicit dependency (compile time
checked) on servlet api too!! ;)
So sorry for my misunderstanding and Good idea Scott!! ;)
On Fri, Mar 28, 2008 at 9:53 AM, a clem <a....@gmail.com> wrote:
>
> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl <er...@gmail.com> wrote:
> > +1 for ExternalContextUtils
> > Good idea Scott
> >
> > In this case I wait for those utils before doing the changes in the
> > PPRPhaseListener
> >
> > greez
> >
> > E
> >
> >
> >
> > On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan <da...@gmail.com> wrote:
> > > Take a look at Trinidad's ExternalContextUtils class. It uses
> > > reflection. I'm also going to try to get something like this in the
> > > myfaces commons, probably in the configurator package if I end up
> > > submitting my current code.
> > >
> > > If you don't have time to find the ExternalContextUtils on your own,
> > > I'll try to post some source tomorrow.
> > >
> > > Scott
> > >
> > >
> > >
> > > Leonardo Uribe wrote:
> > > > Hi
> > > >
> > > > I have seen lines like this on the attached files:
> > > >
> > > > //Don't do the rendering twice
> > > > if (request instanceof PortletRequest &&
> > > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
> > > > return;
> > > > }
> > > >
> > > > The problem here is that doing this makes that tomahawk requires
> > > > portlet api to work, in non portlet environments.
> > > >
> > > > The same problem is present on MYFACES-434 patch.
> > > >
> > > > Can anyone suggest a way to avoid this dependency? or we should put
> > > > portlet api as compile dependency for tomahawk?
>
> I don't think this is a problem to have a dependancy on a standard API
> since this an API (not an implementation) and a standard one.
> This is known as the pattern 'dependency inversion'.
> One alternative could be to develop a abstraction layer on top of the
> standard servlet and portlet apis (to hide them).
>
> regards
>
> > > >
> > > > regards
> > > >
> > > > Leonardo Uribe
> > > >
> > > >
> > >
> > >
> >
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by a clem <a....@gmail.com>.
On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl <er...@gmail.com> wrote:
> +1 for ExternalContextUtils
> Good idea Scott
>
> In this case I wait for those utils before doing the changes in the
> PPRPhaseListener
>
> greez
>
> E
>
>
>
> On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan <da...@gmail.com> wrote:
> > Take a look at Trinidad's ExternalContextUtils class. It uses
> > reflection. I'm also going to try to get something like this in the
> > myfaces commons, probably in the configurator package if I end up
> > submitting my current code.
> >
> > If you don't have time to find the ExternalContextUtils on your own,
> > I'll try to post some source tomorrow.
> >
> > Scott
> >
> >
> >
> > Leonardo Uribe wrote:
> > > Hi
> > >
> > > I have seen lines like this on the attached files:
> > >
> > > //Don't do the rendering twice
> > > if (request instanceof PortletRequest &&
> > > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
> > > return;
> > > }
> > >
> > > The problem here is that doing this makes that tomahawk requires
> > > portlet api to work, in non portlet environments.
> > >
> > > The same problem is present on MYFACES-434 patch.
> > >
> > > Can anyone suggest a way to avoid this dependency? or we should put
> > > portlet api as compile dependency for tomahawk?
I don't think this is a problem to have a dependancy on a standard API
since this an API (not an implementation) and a standard one.
This is known as the pattern 'dependency inversion'.
One alternative could be to develop a abstraction layer on top of the
standard servlet and portlet apis (to hide them).
regards
> > >
> > > regards
> > >
> > > Leonardo Uribe
> > >
> > >
> >
> >
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Ernst Fastl <er...@gmail.com>.
+1 for ExternalContextUtils
Good idea Scott
In this case I wait for those utils before doing the changes in the
PPRPhaseListener
greez
E
On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan <da...@gmail.com> wrote:
> Take a look at Trinidad's ExternalContextUtils class. It uses
> reflection. I'm also going to try to get something like this in the
> myfaces commons, probably in the configurator package if I end up
> submitting my current code.
>
> If you don't have time to find the ExternalContextUtils on your own,
> I'll try to post some source tomorrow.
>
> Scott
>
>
>
> Leonardo Uribe wrote:
> > Hi
> >
> > I have seen lines like this on the attached files:
> >
> > //Don't do the rendering twice
> > if (request instanceof PortletRequest &&
> > ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
> > return;
> > }
> >
> > The problem here is that doing this makes that tomahawk requires
> > portlet api to work, in non portlet environments.
> >
> > The same problem is present on MYFACES-434 patch.
> >
> > Can anyone suggest a way to avoid this dependency? or we should put
> > portlet api as compile dependency for tomahawk?
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
>
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Scott O'Bryan <da...@gmail.com>.
Take a look at Trinidad's ExternalContextUtils class. It uses
reflection. I'm also going to try to get something like this in the
myfaces commons, probably in the configurator package if I end up
submitting my current code.
If you don't have time to find the ExternalContextUtils on your own,
I'll try to post some source tomorrow.
Scott
Leonardo Uribe wrote:
> Hi
>
> I have seen lines like this on the attached files:
>
> //Don't do the rendering twice
> if (request instanceof PortletRequest &&
> ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
> return;
> }
>
> The problem here is that doing this makes that tomahawk requires
> portlet api to work, in non portlet environments.
>
> The same problem is present on MYFACES-434 patch.
>
> Can anyone suggest a way to avoid this dependency? or we should put
> portlet api as compile dependency for tomahawk?
>
> regards
>
> Leonardo Uribe
>
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have seen lines like this on the attached files:
//Don't do the rendering twice
if (request instanceof PortletRequest &&
((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
return;
}
The problem here is that doing this makes that tomahawk requires portlet api
to work, in non portlet environments.
The same problem is present on MYFACES-434 patch.
Can anyone suggest a way to avoid this dependency? or we should put portlet
api as compile dependency for tomahawk?
regards
Leonardo Uribe
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by a clem <a....@gmail.com>.
hi,
people interested by AJAX enabled JSF portlets in Liferay portal using
tomahawk pprPanelGroup may take a look to this article:
http://newsted1.blogspot.com/2008/03/jsf-ajax-enabled-portlets-for-liferay.html
On Mon, Mar 24, 2008 at 10:23 PM, Ernst Fastl <er...@gmail.com> wrote:
> Hi,
>
> I just took a quick glance at the changes in the PPRPhaseListener.
> What I've seen looks
> alright so far and since I'm working on that class at the moment
> anyway I'll be happy to
> factor in those changes.
>
> As for the DojoUtils, those are as far as I know mainly maintained by werner.
> Maybe he wants to have a look there - otherwise I'll also take a look
> at that too.
>
> You are absolutely right when you say that our components should also work in
> portlet environments. thanks for your contribution.
>
> cheer
>
> Ernst
>
>
>
> On Mon, Mar 24, 2008 at 2:21 PM, Scott O'Bryan <da...@gmail.com> wrote:
> > Cool beans. Be careful though before checking these patches into a mainline
> > code base (maybe a sandbox or something). This solution probably won't work
> > for remote WSRP portals. As for your second suggestion, I couldn't agree
> > more. The Trinidad configurators provide an ExternalContext specifically to
> > keep the abstraction container agnostic. You may wish to implement the
> > ExternalContext in your change.
> >
> > Scott
> >
> >
> >
> > On Mon, Mar 24, 2008 at 5:15 AM, a clem <a....@gmail.com> wrote:
> > > Hi,
> > >
> > > I ve made working pprPanelGroup in liferay portal. To do that, I had
> > > to patch 2 files of the core and sandbox distributions.
> > > - org/apache/myfaces/custom/dojo/DojoUtils.java
> > > - org/apache/myfaces/custom/ppr/PPRPhaseListener.java
> > >
> > > Basically the modifications consist to check wether the request is a
> > > portletrequest or a servletrequest.
> > > It would be nice if ajax related myfaces code could be completely
> > > servlet or portlet context agnostic, for example using a layer of
> > > abstraction on top of servlet and portlet apis.
> > >
> > > I also had to patch 6 files of the liferay code base to make the
> > > portal PPR aware. For those who are interested, just let me know.
> > > It is quite simple but it works nice and it is, I think, a more
> > > flexible and powerful approach than the IceFaces one to get Ajax
> > > working within your portlets.
> > >
> >
> >
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Ernst Fastl <er...@gmail.com>.
Hi,
I just took a quick glance at the changes in the PPRPhaseListener.
What I've seen looks
alright so far and since I'm working on that class at the moment
anyway I'll be happy to
factor in those changes.
As for the DojoUtils, those are as far as I know mainly maintained by werner.
Maybe he wants to have a look there - otherwise I'll also take a look
at that too.
You are absolutely right when you say that our components should also work in
portlet environments. thanks for your contribution.
cheer
Ernst
On Mon, Mar 24, 2008 at 2:21 PM, Scott O'Bryan <da...@gmail.com> wrote:
> Cool beans. Be careful though before checking these patches into a mainline
> code base (maybe a sandbox or something). This solution probably won't work
> for remote WSRP portals. As for your second suggestion, I couldn't agree
> more. The Trinidad configurators provide an ExternalContext specifically to
> keep the abstraction container agnostic. You may wish to implement the
> ExternalContext in your change.
>
> Scott
>
>
>
> On Mon, Mar 24, 2008 at 5:15 AM, a clem <a....@gmail.com> wrote:
> > Hi,
> >
> > I ve made working pprPanelGroup in liferay portal. To do that, I had
> > to patch 2 files of the core and sandbox distributions.
> > - org/apache/myfaces/custom/dojo/DojoUtils.java
> > - org/apache/myfaces/custom/ppr/PPRPhaseListener.java
> >
> > Basically the modifications consist to check wether the request is a
> > portletrequest or a servletrequest.
> > It would be nice if ajax related myfaces code could be completely
> > servlet or portlet context agnostic, for example using a layer of
> > abstraction on top of servlet and portlet apis.
> >
> > I also had to patch 6 files of the liferay code base to make the
> > portal PPR aware. For those who are interested, just let me know.
> > It is quite simple but it works nice and it is, I think, a more
> > flexible and powerful approach than the IceFaces one to get Ajax
> > working within your portlets.
> >
>
>
Re: Ajax, pprPanelGroup and Portlets working together...
Posted by Scott O'Bryan <da...@gmail.com>.
Cool beans. Be careful though before checking these patches into a mainline
code base (maybe a sandbox or something). This solution probably won't work
for remote WSRP portals. As for your second suggestion, I couldn't agree
more. The Trinidad configurators provide an ExternalContext specifically to
keep the abstraction container agnostic. You may wish to implement the
ExternalContext in your change.
Scott
On Mon, Mar 24, 2008 at 5:15 AM, a clem <a....@gmail.com> wrote:
> Hi,
>
> I ve made working pprPanelGroup in liferay portal. To do that, I had
> to patch 2 files of the core and sandbox distributions.
> - org/apache/myfaces/custom/dojo/DojoUtils.java
> - org/apache/myfaces/custom/ppr/PPRPhaseListener.java
>
> Basically the modifications consist to check wether the request is a
> portletrequest or a servletrequest.
> It would be nice if ajax related myfaces code could be completely
> servlet or portlet context agnostic, for example using a layer of
> abstraction on top of servlet and portlet apis.
>
> I also had to patch 6 files of the liferay code base to make the
> portal PPR aware. For those who are interested, just let me know.
> It is quite simple but it works nice and it is, I think, a more
> flexible and powerful approach than the IceFaces one to get Ajax
> working within your portlets.
>