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