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 <[EMAIL PROTECTED]> 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 <[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
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >>
>
>
