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 <[EMAIL PROTECTED]> wrote:
>
> On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > > >
> > > >
> > >
> > >
> >
>
