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 <[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
> > >
> > >
> >
> >
>
