myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Freedman <michael.freed...@oracle.com>
Subject Re: Ajax, pprPanelGroup and Portlets working together...
Date Thu, 03 Apr 2008 17:15:35 GMT
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 <darkarena@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.p.clement@gmail.com> 
>>> wrote:
>>>  >
>>>  >> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl 
>>> <ernst.fastl@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 
>>> <darkarena@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
>>>  >>  >  >  >
>>>  >>  >  >  >
>>>  >>  >  >
>>>  >>  >  >
>>>  >>  >
>>>  >>
>>>  >>
>>>
>>>
>>>     
>


Mime
View raw message