Re: Antwort: Re: Auto discovery of ActionBeanContext.Class

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Antwort: Re: Auto discovery of ActionBeanContext.Class

Dmitri Colebatch-2
I must be missing something, what's wrong with this:

public class BaseActionBean<C extends ActionBeanContext> implements ActionBean
{
        private C context;

        public void setContext(ActionBeanContext context)
        {
                this.context = (C) context;
        }

        public C getContext()
        {
                return context;
        }
}

Simply add that class to stripes as is and you have a best of both
worlds - no change to the ActionBean interface, but you also provide a
useful base class that (I believe) satisfies the requirements raised
in this thread.

cheers
dim

On 10/13/06, Tim Fennell <[hidden email]> wrote:

> My concern over this is that ActionBean is pretty much the first class any
> new user encounters with Stripes.  As such, seeing a nice plain interface
> like:
>
> interface ActionBean {
>     ActionBeanContext getContext();
>     void setContext(ActionBeanContext ctx);
> }
>
> is good because it's really not much to understand at first blush.  But
> compare that to (as it would have to correctly be specified):
>
> interface ActionBean<T extends ActionBeanContext> {
>     T getContext();
>     void setContext(T ctx);
> }
>
> If you haven't spent any time with generics, that's rather a lot to take in.
>  Is this problem of overriding the getContext() method (once in a base
> class) so bad that we'd want to impose this on new users?
>
> -t
>
>
> On Oct 12, 2006, at 2:40 PM, Ben Gunter wrote:
> I suggested this very thing in STS-206 on June 17. If you want to vote for
> it, you can. Tim posted some comments there giving reasons he might not want
> to do that.
>
> http://stripes.mc4j.org/jira/browse/STS-206
>
> I did not suggest adding a type parameter to the ActionBean interface, only
> to the abstract base class that implements it. But I think ActionBean could
> be changed to ActionBean<T extends ActionBeanContext> and still be backward
> compatible so that's a good idea. Even better, Stripes could look at the
> type parameter to determine what ActionBeanContext subclass to instantiate.
>
> So yeah, I do think this is a good idea.
>
> -Ben
>
> Sebastian Wiemer wrote:
> Ok i see, the annotation is not really necessary ;)

But how about another
> suggestion. How to extend the ActionBean interface like

public interface
> ActionBean {
 public T getContext();
 public void setContext( T context
> );
}

This would allow stripes to provide a base class like

public abstract
> class StripesActionBean implements ActionBean {
 private T
> actionBeanContext;
 public T getContext() { return( this.actionBeanContext
> ); }
 public void setContext( T context ) { this.actionBeanContext =
> context; }
}

Therefore no more need to implements getContext() and
> setContext() in all
ActionBeans of your application.

Just to an
public
> class MyActionBean extends StripesActionBean {
 // no more getContext()
> setContext() anymore ;)

 public Resolution foo() {
> getContext().getMySpecialValue();
 }
}

And stripes will
> still have to initiate the corret generic type of
ActionBeanContext an
> LifecycleStage.ActionBeanResolution
>

Isn't that much more cleaner since you never have to cast any context
>
anymore ? Btw. i think this would also solve Gary Moselene's problem,
> doesn't
it ?
Did i miss something ?




Am Donnerstag, 12. Oktober 2006
> 13:30 schrieb Ben Gunter:

>
> I thought about that, too, but I think in most cases an annotation
> would
just duplicate what is already made clear by the getContext()
> return
type. Unless you are really masochistic your bean will declare a
> field
with the same type as your specific ActionBeanContext
> subclass.
(Otherwise you'd have to cast it every time you use whatever
> methods you
added to it.) So why not just declare getContext()'s return type
> as your
subclass and be done with it?

The case in which it doesn't work
> quite so nicely is when an ActionBean
type BeanB extends ActionBean type
> BeanA, and BeanB uses
ActionBeanContext ContextB, which extends BeanA's
> ContextA. Then an
annotation might be a little bit cleaner than overriding
> getContext() to
return ContextB. But you would probably want to override
> getContext()
anyway so you could do
> this

getContext().callMethodFromContextB();

instead of
> this

((ContextB) context).callMethodFromContextB();

Just
> my two cents.

-Ben

[hidden email] wrote:

> Nice idea,

but wouldn't it be saver, and maybe clearer, to use an class
> level
annotation for such ActionBeans ?
One benefit would be to be able to
> define subclassed/specialized
ActionBeanContexts without having to change
to
> getContext() notation.

Just an idea ?
-Sebastian





 Tim Fennell
> <[hidden email]
 m>
An Gesendet von: Stripes Users List
> stripes-users-bou
<[hidden email]
> [hidden email] et>
 forge.net
Kopie


Thema 12.10.2006 03:35 Re:
> [Stripes-users] Auto discovery of
ActionBeanContext.Class

 Bitte antworten
> an
 Stripes Users
 List
 <stripes-users@li
 sts.sourceforge.n
> et>






Exactly. Makes me wonder why I didn't think of this myself and a
> lot
earlier :p
-t

On Oct 11, 2006, at 9:15 PM, Ben Gunter wrote:

 So then,
> doesn't this strategy make it unnecessary (although still
 possible) to
> explicitly configure an ActionBeanContext subclass? If
 so, then that very
> much fits the Stripes philosophy! :)

 Tim Fennell wrote:
 You know (and I'm
> not joking) this is why I love users with
 high
 expectations! I'd simply
> never thought about doing it the
way you
 suggest. So if I understand you
> correctly you'd like it to
 work like
 this:

 1. If the return type of
> getContext() on the ActionBean
 subclass is a
 subclass of ActionBeanContext
> (and not the class itself)
 instantiate
 that class

 2. If the return type
> is ActionBeanContext, look for a
 configured class

 3. Finally, fall back
> to ActionBeanContext.class

 Should be easy enough, I'll log it in JIRA.

> -t


 On Oct 11, 2006, at 5:36 PM, Gary Moselen wrote:


 Hello,

 We have
> got a number of ActionBeanContext subclasses
 which are used
 for
 different
> logical modules of our system. The way we
have it set up now
 seems to work
> only be coincidence. In web.xml we have
 multiple entries
 for
> ActionBeanContext.Class.


 ActionBeanContext.Class
 com.FooContext


> ActionBeanContext.Class
 com.BarContext


 ActionBeanContext.Class
> com.BazContext


 From the documentation this doesn't seem like the
> intended use (there
 should be only one ActionBeanContext.Class configured
> globally?). In
 other respects Stripes will just discover the
ActionBean
> classes that
 are available on the class path so we can have a module
> system that
 configures itself based on what modules are available
on the
> classpath.
 This is what we get Hibernate/JAXB to do as well. So we
 can
> deploy
 just
 the Core module and only the Core ActionBeans and Core
> Hibernate
 entities etc are found on the class path so everything
> configures
 itself.

 Having to specify the specific Context classes
> in
web.xml breaks this
 for us.

 I have looked at the
> ActionBeanContextFactory.Class
 configuration
 and I
 could probably write a
> factory that did what I wanted
 using reflection
 to eliminate any hard
> dependencies, but it seems like a
 neater
 solution
 would be to have
> Stripes discover ActionBeanContext
 classes
 depending on
 the type expected
> by the ActionBean.

 The set up now seems a little weird, because we
> just
tell it about
 these
 Context classes but we don't associate them with
> an
 ActionBean. When
 Stripes hits an ActionBean it knows which one we
> wanted
 even though we
 never associated it with it (I guess by reflecting
> on
the getActionBeanContext()?). Could Stripes go the extra step and
> eliminate
 this need for the configuration in web.xml?

 thanks,
 Gary



>
----------------------------------------------------------------------

> ---
 Using Tomcat but need to do more? Need to support web
 services,
> security?
 Get stuff done quickly with pre-integrated technology
to make
> your
 job easier
 Download IBM WebSphere Application Server v.1.0.1 based
> on Apache
 Geronimo
 http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
>
https://lists.sourceforge.net/lists/listinfo/stripes-users


>
-------------------------------------------------------------------------

> Using Tomcat but need to do more? Need to support web
services, security?
> Get stuff done quickly with pre-integrated technology to make
 your job
> easier
 Download IBM WebSphere Application Server v.1.0.1 based on
 Apache
> Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users

>
-------------------------------------------------------------------------
Using
> Tomcat but need to do more? Need to support web services, security?
 Get
> stuff done quickly with pre-integrated technology to make your
 job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
 Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_
______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
-------------------------------------------------------------------------
Using
> Tomcat but need to do more? Need to support web services, security?
Get
> stuff done quickly with pre-integrated technology to make your
> job
easier
Download IBM WebSphere Application Server v.1.0.1 based on
> Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users
> mailing
> list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



-------------------------------------------------------------------------
Using
> Tomcat but need to do more? Need to support web services, security?
Get
> stuff done quickly with pre-integrated technology to make your job
easier
> Download IBM WebSphere Application Server v.1.0.1 based on
> Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users
> mailing
> list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
> -------------------------------------------------------------------------
Using
> Tomcat but need to do more? Need to support web services, security?
Get
> stuff done quickly with pre-integrated technology to make your job
easier
> Download IBM WebSphere Application Server v.1.0.1 based on
> Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users
> mailing
> list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
> -------------------------------------------------------------------------
Using
> Tomcat but need to do more? Need to support web services, security?
Get
> stuff done quickly with pre-integrated technology to make your job
> easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users
> mailing
> list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users

> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Antwort: Re: Auto discovery of ActionBeanContext.Class

Dmitri Colebatch-2
Sorry - I've now read (and voted for) the bug... Tim, unless I'm
missing something, what's suggested in the bug isn't asking for a
change to the ActionBean interface.  I don' understand what your
concern is - I would envisage that the quickstart guide would stay as
is, and the BaseActionBean in the bug would be a useful thing for
people to use once they need it.

cheers
dim

On 10/13/06, Dmitri Colebatch <[hidden email]> wrote:

> I must be missing something, what's wrong with this:
>
> public class BaseActionBean<C extends ActionBeanContext> implements ActionBean
> {
>        private C context;
>
>        public void setContext(ActionBeanContext context)
>        {
>                this.context = (C) context;
>        }
>
>        public C getContext()
>        {
>                return context;
>        }
> }
>
> Simply add that class to stripes as is and you have a best of both
> worlds - no change to the ActionBean interface, but you also provide a
> useful base class that (I believe) satisfies the requirements raised
> in this thread.
>
> cheers
> dim
>
> On 10/13/06, Tim Fennell <[hidden email]> wrote:
> > My concern over this is that ActionBean is pretty much the first class any
> > new user encounters with Stripes.  As such, seeing a nice plain interface
> > like:
> >
> > interface ActionBean {
> >     ActionBeanContext getContext();
> >     void setContext(ActionBeanContext ctx);
> > }
> >
> > is good because it's really not much to understand at first blush.  But
> > compare that to (as it would have to correctly be specified):
> >
> > interface ActionBean<T extends ActionBeanContext> {
> >     T getContext();
> >     void setContext(T ctx);
> > }
> >
> > If you haven't spent any time with generics, that's rather a lot to take in.
> >  Is this problem of overriding the getContext() method (once in a base
> > class) so bad that we'd want to impose this on new users?
> >
> > -t
> >
> >
> > On Oct 12, 2006, at 2:40 PM, Ben Gunter wrote:
> > I suggested this very thing in STS-206 on June 17. If you want to vote for
> > it, you can. Tim posted some comments there giving reasons he might not want
> > to do that.
> >
> > http://stripes.mc4j.org/jira/browse/STS-206
> >
> > I did not suggest adding a type parameter to the ActionBean interface, only
> > to the abstract base class that implements it. But I think ActionBean could
> > be changed to ActionBean<T extends ActionBeanContext> and still be backward
> > compatible so that's a good idea. Even better, Stripes could look at the
> > type parameter to determine what ActionBeanContext subclass to instantiate.
> >
> > So yeah, I do think this is a good idea.
> >
> > -Ben
> >
> > Sebastian Wiemer wrote:
> > Ok i see, the annotation is not really necessary ;)
>
> But how about another
> > suggestion. How to extend the ActionBean interface like
>
> public interface
> > ActionBean {
>  public T getContext();
>  public void setContext( T context
> > );
> }
>
> This would allow stripes to provide a base class like
>
> public abstract
> > class StripesActionBean implements ActionBean {
>  private T
> > actionBeanContext;
>  public T getContext() { return( this.actionBeanContext
> > ); }
>  public void setContext( T context ) { this.actionBeanContext =
> > context; }
> }
>
> Therefore no more need to implements getContext() and
> > setContext() in all
> ActionBeans of your application.
>
> Just to an
> public
> > class MyActionBean extends StripesActionBean {
>  // no more getContext()
> > setContext() anymore ;)
>
>  public Resolution foo() {
> > getContext().getMySpecialValue();
>  }
> }
>
> And stripes will
> > still have to initiate the corret generic type of
> ActionBeanContext an
> > LifecycleStage.ActionBeanResolution
> >
>
> Isn't that much more cleaner since you never have to cast any context
> >
> anymore ? Btw. i think this would also solve Gary Moselene's problem,
> > doesn't
> it ?
> Did i miss something ?
>
>
>
>
> Am Donnerstag, 12. Oktober 2006
> > 13:30 schrieb Ben Gunter:
>
> >
> > I thought about that, too, but I think in most cases an annotation
> > would
> just duplicate what is already made clear by the getContext()
> > return
> type. Unless you are really masochistic your bean will declare a
> > field
> with the same type as your specific ActionBeanContext
> > subclass.
> (Otherwise you'd have to cast it every time you use whatever
> > methods you
> added to it.) So why not just declare getContext()'s return type
> > as your
> subclass and be done with it?
>
> The case in which it doesn't work
> > quite so nicely is when an ActionBean
> type BeanB extends ActionBean type
> > BeanA, and BeanB uses
> ActionBeanContext ContextB, which extends BeanA's
> > ContextA. Then an
> annotation might be a little bit cleaner than overriding
> > getContext() to
> return ContextB. But you would probably want to override
> > getContext()
> anyway so you could do
> > this
>
> getContext().callMethodFromContextB();
>
> instead of
> > this
>
> ((ContextB) context).callMethodFromContextB();
>
> Just
> > my two cents.
>
> -Ben
>
> [hidden email] wrote:
>
> > Nice idea,
>
> but wouldn't it be saver, and maybe clearer, to use an class
> > level
> annotation for such ActionBeans ?
> One benefit would be to be able to
> > define subclassed/specialized
> ActionBeanContexts without having to change
> to
> > getContext() notation.
>
> Just an idea ?
> -Sebastian
>
>
>
>
>
>  Tim Fennell
> > <[hidden email]
>  m>
> An Gesendet von: Stripes Users List
> > stripes-users-bou
> <[hidden email]
> > [hidden email] et>
>  forge.net
> Kopie
>
>
> Thema 12.10.2006 03:35 Re:
> > [Stripes-users] Auto discovery of
> ActionBeanContext.Class
>
>  Bitte antworten
> > an
>  Stripes Users
>  List
>  <stripes-users@li
>  sts.sourceforge.n
> > et>
>
>
>
>
>
>
> Exactly. Makes me wonder why I didn't think of this myself and a
> > lot
> earlier :p
> -t
>
> On Oct 11, 2006, at 9:15 PM, Ben Gunter wrote:
>
>  So then,
> > doesn't this strategy make it unnecessary (although still
>  possible) to
> > explicitly configure an ActionBeanContext subclass? If
>  so, then that very
> > much fits the Stripes philosophy! :)
>
>  Tim Fennell wrote:
>  You know (and I'm
> > not joking) this is why I love users with
>  high
>  expectations! I'd simply
> > never thought about doing it the
> way you
>  suggest. So if I understand you
> > correctly you'd like it to
>  work like
>  this:
>
>  1. If the return type of
> > getContext() on the ActionBean
>  subclass is a
>  subclass of ActionBeanContext
> > (and not the class itself)
>  instantiate
>  that class
>
>  2. If the return type
> > is ActionBeanContext, look for a
>  configured class
>
>  3. Finally, fall back
> > to ActionBeanContext.class
>
>  Should be easy enough, I'll log it in JIRA.
>
> > -t
>
>
>  On Oct 11, 2006, at 5:36 PM, Gary Moselen wrote:
>
>
>  Hello,
>
>  We have
> > got a number of ActionBeanContext subclasses
>  which are used
>  for
>  different
> > logical modules of our system. The way we
> have it set up now
>  seems to work
> > only be coincidence. In web.xml we have
>  multiple entries
>  for
> > ActionBeanContext.Class.
>
>
>  ActionBeanContext.Class
>  com.FooContext
>
>
> > ActionBeanContext.Class
>  com.BarContext
>
>
>  ActionBeanContext.Class
> > com.BazContext
>
>
>  From the documentation this doesn't seem like the
> > intended use (there
>  should be only one ActionBeanContext.Class configured
> > globally?). In
>  other respects Stripes will just discover the
> ActionBean
> > classes that
>  are available on the class path so we can have a module
> > system that
>  configures itself based on what modules are available
> on the
> > classpath.
>  This is what we get Hibernate/JAXB to do as well. So we
>  can
> > deploy
>  just
>  the Core module and only the Core ActionBeans and Core
> > Hibernate
>  entities etc are found on the class path so everything
> > configures
>  itself.
>
>  Having to specify the specific Context classes
> > in
> web.xml breaks this
>  for us.
>
>  I have looked at the
> > ActionBeanContextFactory.Class
>  configuration
>  and I
>  could probably write a
> > factory that did what I wanted
>  using reflection
>  to eliminate any hard
> > dependencies, but it seems like a
>  neater
>  solution
>  would be to have
> > Stripes discover ActionBeanContext
>  classes
>  depending on
>  the type expected
> > by the ActionBean.
>
>  The set up now seems a little weird, because we
> > just
> tell it about
>  these
>  Context classes but we don't associate them with
> > an
>  ActionBean. When
>  Stripes hits an ActionBean it knows which one we
> > wanted
>  even though we
>  never associated it with it (I guess by reflecting
> > on
> the getActionBeanContext()?). Could Stripes go the extra step and
> > eliminate
>  this need for the configuration in web.xml?
>
>  thanks,
>  Gary
>
>
>
> >
> ----------------------------------------------------------------------
>
> > ---
>  Using Tomcat but need to do more? Need to support web
>  services,
> > security?
>  Get stuff done quickly with pre-integrated technology
> to make
> > your
>  job easier
>  Download IBM WebSphere Application Server v.1.0.1 based
> > on Apache
>  Geronimo
>  http://sel.as-us.falkag.net/sel?
> > cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> >
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> >
> -------------------------------------------------------------------------
>
> > Using Tomcat but need to do more? Need to support web
> services, security?
> > Get stuff done quickly with pre-integrated technology to make
>  your job
> > easier
>  Download IBM WebSphere Application Server v.1.0.1 based on
>  Apache
> > Geronimo
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>
> >
> -------------------------------------------------------------------------
> Using
> > Tomcat but need to do more? Need to support web services, security?
>  Get
> > stuff done quickly with pre-integrated technology to make your
>  job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
>  Geronimo
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_
> ______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> -------------------------------------------------------------------------
> Using
> > Tomcat but need to do more? Need to support web services, security?
> Get
> > stuff done quickly with pre-integrated technology to make your
> > job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on
> > Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users
> > mailing
> > list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
> -------------------------------------------------------------------------
> Using
> > Tomcat but need to do more? Need to support web services, security?
> Get
> > stuff done quickly with pre-integrated technology to make your job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on
> > Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users
> > mailing
> > list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
> > -------------------------------------------------------------------------
> Using
> > Tomcat but need to do more? Need to support web services, security?
> Get
> > stuff done quickly with pre-integrated technology to make your job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on
> > Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users
> > mailing
> > list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
> > -------------------------------------------------------------------------
> Using
> > Tomcat but need to do more? Need to support web services, security?
> Get
> > stuff done quickly with pre-integrated technology to make your job
> > easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users
> > mailing
> > list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >
> >
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Antwort: Re: Auto discovery of ActionBeanContext.Class

Remco Bos
In reply to this post by Dmitri Colebatch-2
Now you mention it, configuration can be tricky indeed. I don't like xml configuration and that's why i love stripes, but I still have to configure the Filter in the web.xml and lookup all the parameters in the documentation.I would like to configure everything with objects. Maybe extend the DefaultConfiguration or give the BootstrapPropertyResolver an object with contstants? I'm no expert on this, just some thoughts...

Ben Gunter <[hidden email]> wrote:
I get where you're coming from, but in the end what makes one thing a little more complex makes another thing simpler.

It's almost a given that even the most basic webapp can benefit from having its own ActionBeanContext subclass. One of the first docs a newcomer should read is the Best Practices document. In there, it says you should subclass ActionBeanContext to provide typesafe access to session objects. Good idea, indeed. So after a newcomer grasps the basic concepts that drive Stripes and attempts something a little more complex, he will will almost invariably write his own ActionBeanContext. Then he has to turn to the configuration reference to figure out how to tell Stripes to use that custom class.

I know now that it's pretty straightforward: just add an ActionBeanContext.Class init-param to the StripesFilter declaration in web.xml. But when I first tried to figure that out, I somehow got mixed up and implemented my own ActionBeanContextFactory to create my contexts. We've seen an instance just yesterday (I think) where someone was trying to add a config param and put it under the wrong element in web.xml and struggled with that for hours. My point is the configuration and customizations can be a little tricky at first.

Now if using a custom ActionBeanContext were as simple as passing a type param in your ActionBean class declaration, then the instructions would be pretty simple: just implement ActionBean<MyActionBeanContext>.

I think you can mitigate the intimidation factor of a crazy generic interface by instead presenting a simple implementation of it, sans the type parameter. Something like this:

public class MyActionBean implements ActionBean {
    private ActionBeanContext context;
    public void setContext(ActionBeanContext context) { this.context = context; }
    public ActionBeanContext getContext() { return context; }

    @DefaultHandler
    public Resolution go() {
       return new RedirectResolution ("/");
    }
}

And then just dissect it and tell what the different pieces mean. That way they see how simple it can be. And then they can move on to more advanced topics when they're ready. Given the advantages this would provide to the people who use Stripes every day, I do think this change would be worth it. This is especially true for those who are using multiple ActionBeanContext implementations in a single webapp.

Well I guess I've pretty much worn out this topic :)

-Ben

Tim Fennell wrote:
My concern over this is that ActionBean is pretty much the first class any new user encounters with Stripes.  As such, seeing a nice plain interface like:

interface ActionBean {
    ActionBeanContext getContext();
    void setContext(ActionBeanContext ctx);
}

is good because it's really not much to understand at first blush.  But compare that to (as it would have to correctly be specified):

interface ActionBean<T extends ActionBeanContext> {
    T getContext();
    void setContext(T ctx);
}

If you haven't spent any time with generics, that's rather a lot to take in.  Is this problem of overriding the getContext() method (once in a base class) so bad that we'd want to impose this on new users?

-t

On Oct 12, 2006, at 2:40 PM, Ben Gunter wrote:

I suggested this very thing in STS-206 on June 17. If you want to vote for it, you can. Tim posted some comments there giving reasons he might not want to do that.

http://stripes.mc4j.org/jira/browse/STS-206

I did not suggest adding a type parameter to the ActionBean interface, only to the abstract base class that implements it. But I think ActionBean could be changed to ActionBean<T extends ActionBeanContext> and still be backward compatible so that's a good idea. Even better, Stripes could look at the type parameter to determine what ActionBeanContext subclass to instantiate.

So yeah, I do think this is a good idea.

-Ben

Sebastian Wiemer wrote:
Ok i see, the annotation is not really necessary ;)    But how about another suggestion. How to extend the ActionBean interface like    public interface ActionBean {   public T getContext();   public void setContext( T context );  }    This would allow stripes to provide a base class like    public abstract
 class StripesActionBean implements ActionBean {   private T actionBeanContext;   public T getContext() { return( this.actionBeanContext ); }   public void setContext( T context ) { this.actionBeanContext = context; }  }    Therefore no more need to implements getContext() and setContext() in all   ActionBeans of your application.    Just to an  public class MyActionBean extends StripesActionBean {   // no more getContext() setContext() anymore ;)     public Resolution foo() {    getContext().getMySpecialValue();   }  }    And stripes will still have to initiate the corret generic type of   ActionBeanContext an LifecycleStage.ActionBeanResolution    Isn't that much more cleaner since you never have to cast any context   anymore ? Btw. i think this would also solve Gary Moselene's problem, doesn't   it ?  Did i miss something ?          Am Donnerstag, 12. Oktober 2006 13:30 schrieb Ben Gunter:    
I thought about that, too, but I think in most cases an annotation would  just duplicate what is already made clear by the getContext() return  type. Unless you are really masochistic your bean will declare a field  with the same type as your specific ActionBeanContext subclass.  (Otherwise you'd have to cast it every time you use whatever methods you  added to it.) So why not just declare getContext()'s return type as your  subclass and be done with it?    The case in which it doesn't work quite so nicely is when an ActionBean  type BeanB extends ActionBean type BeanA, and BeanB uses  ActionBeanContext ContextB, which extends BeanA's ContextA. Then an  annotation might be a little bit cleaner than overriding getContext() to  return ContextB. But you would probably want to override getContext()  anyway so you could do this    getContext().callMethodFromContextB();    instead of this    ((ContextB) context).callMethodFromContextB();   
 Just my two cents.    -Ben    [hidden email] wrote:      
Nice idea,    but wouldn't it be saver, and maybe clearer, to use an class level  annotation for such ActionBeans ?  One benefit would be to be able to define subclassed/specialized  ActionBeanContexts without having to change  to getContext() notation.    Just an idea ?  -Sebastian                         Tim Fennell               [hidden email]                                                          An Gesendet von:              Stripes Users List               stripes-users-bou           [hidden email]               forge.net           
                                     Kopie                                                                          Thema 12.10.2006 03:35           Re: [Stripes-users] Auto discovery of  ActionBeanContext.Class                  Bitte antworten                      an                 Stripes Users                     List               [hidden email]              Exactly.  Makes me wonder why I didn't think of this myself and a lot  earlier :p  -t    On Oct 11, 2006, at 9:15 PM, Ben Gunter wrote:          So then, doesn't this strategy make it unnecessary (although still        possible) to explicitly configure an ActionBeanContext subclass? If        so, then that very much fits the Stripes philosophy! :)          Tim Fennell wrote:              You know (and I'm not joking) this is why I love users with              high   
           expectations!  I'd simply never thought about doing it the  way you              suggest.  So if I understand you correctly you'd like it to              work like              this:                1. If the return type of getContext() on the ActionBean              subclass is a              subclass of ActionBeanContext (and not the class itself)              instantiate              that class                2. If the return type is ActionBeanContext, look for a              configured class                3. Finally, fall back to ActionBeanContext.class                Should be easy enough, I'll log it in JIRA.                -t                  On Oct 11, 2006, at 5:36 PM, Gary Moselen wrote:                        Hello,                      We have got a number of ActionBeanContext subclasses                    which are used                    for                    different logical modules of our system. The way we  have it set up now                   
 seems to work only be coincidence. In web.xml we have                    multiple entries                    for ActionBeanContext.Class.                            ActionBeanContext.Class                        com.FooContext                            ActionBeanContext.Class                        com.BarContext                            ActionBeanContext.Class                        com.BazContext                         From the documentation this doesn't seem like the                    intended use (there                    should be only one ActionBeanContext.Class configured                    globally?).  In                    other respects Stripes will just discover the  ActionBean classes that                    are available on the class path so we can have a module                    system that                    configures itself based on what modules are available  on the                    classpath.                    This
 is what we get Hibernate/JAXB to do as well. So we                    can deploy                    just                    the Core module and only the Core ActionBeans and Core                    Hibernate                    entities etc are found on the class path so everything                    configures                    itself.                      Having to specify the specific Context classes in  web.xml breaks this                    for us.                      I have looked at the ActionBeanContextFactory.Class                    configuration                    and I                    could probably write a factory that did what I wanted                    using reflection                    to eliminate any hard dependencies, but it seems like a                    neater                    solution                    would be to have Stripes discover ActionBeanContext                    classes                    depending on 
                   the type expected by the ActionBean.                      The set up now seems a little weird, because we just  tell it about                    these                    Context classes but we don't associate them with an                    ActionBean. When                    Stripes hits an ActionBean it knows which one we wanted                    even though we                    never associated it with it (I guess by reflecting on  the getActionBeanContext()?). Could Stripes go the extra step and                    eliminate                    this need for the configuration in web.xml?                      thanks,                    Gary                           ----------------------------------------------------------------------                      ---                    Using Tomcat but need to do more? Need to support web                    services,                    security?                    Get stuff done
 quickly with pre-integrated technology  to make your                    job easier                    Download IBM WebSphere Application Server v.1.0.1 based                    on Apache                    Geronimo                    http://sel.as-us.falkag.net/sel?                    cmd=lnk&kid=120709&bid=263057&dat=121642                    _______________________________________________                    Stripes-users mailing list                    [hidden email]                     https://lists.sourceforge.net/lists/listinfo/stripes-users                   -------------------------------------------------------------------------                Using Tomcat but need to do
 more? Need to support web  services, security?              Get stuff done quickly with pre-integrated technology to make              your job easier              Download IBM WebSphere Application Server v.1.0.1 based on              Apache Geronimo               http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642                _______________________________________________              Stripes-users mailing list              [hidden email]              https://lists.sourceforge.net/lists/listinfo/stripes-users           -------------------------------------------------------------------------  Using
 Tomcat but need to do more? Need to support web services, security?        Get stuff done quickly with pre-integrated technology to make your        job easier        Download IBM WebSphere Application Server v.1.0.1 based on Apache        Geronimo         http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_  ______________________________________________ Stripes-users mailing list        [hidden email]        https://lists.sourceforge.net/lists/listinfo/stripes-users  -------------------------------------------------------------------------  Using Tomcat but need to do more? Need to support web services,
 security?  Get stuff done quickly with pre-integrated technology to make your job  easier  Download IBM WebSphere Application Server v.1.0.1 based on Apache  Geronimo  http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642  _______________________________________________  Stripes-users mailing list  [hidden email]  https://lists.sourceforge.net/lists/listinfo/stripes-users        -------------------------------------------------------------------------  Using Tomcat but need to do more? Need to support web services, security?  Get stuff done quickly with pre-integrated technology to make your job  easier Download
 IBM WebSphere Application Server v.1.0.1 based on Apache  Geronimo  http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642  _______________________________________________  Stripes-users mailing list  [hidden email]  https://lists.sourceforge.net/lists/listinfo/stripes-users        
-------------------------------------------------------------------------  Using Tomcat but need to do more? Need to support web services, security?  Get stuff done quickly with pre-integrated technology to make your job  easier Download IBM WebSphere Application Server v.1.0.1 based on Apache  Geronimo 
 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642  _______________________________________________  Stripes-users mailing list  [hidden email]  https://lists.sourceforge.net/lists/listinfo/stripes-users      
-------------------------------------------------------------------------  Using Tomcat but need to do more? Need to support web services, security?  Get stuff done quickly with pre-integrated technology to make your job easier  Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo  http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642  _______________________________________________  Stripes-users mailing list  [hidden email]  https://lists.sourceforge.net/lists/listinfo/stripes-users    
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Stripes-users mailing list


------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________ Stripes-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/stripes-users
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users


Get your email and more, right on the new Yahoo.com
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Antwort: Re: Auto discovery of ActionBeanContext.Class

Tim Fennell-2
In reply to this post by Dmitri Colebatch-2
So I think there are two distinct topics under discussion here:

1) How to make it possible not to have to configure ActionBeanContext.Class

In principle I like this idea, and I think (as said before) the way to
do it is by inferring the type from the concrete getContext() method in
the class.  I was coming around to the argument for genericizing the
ActionBean interface, but now think this is a bad idea(tm).  Apart from
making it less approachable to newcomers, it can make things more
confusing period.  For example, while you might think to do the
following, it won't compile:

public static class Context1 extends ActionBeanContext {}
public static class Context2 extends Context1 {}

public static class FooBean implements ActionBean<Context1> {
    public void setContext(Context1 ctx) { }
    public Context1 getContext() { return null; }
}

public static class Foo2Bean extends FooBean implements
ActionBean<Context2> { }

So overall, I feel like genericizing ActionBean adds to the complexity
of things and doesn't really help that much in return.  I'm going to
log a bug for the whole infer context type from getContext() since that
would seem to solve the use case neatly enough.

2) Adding a BaseActionBean

My main objection to this has and will continue to be that it could
cause bad PR for Stripes and may confuse users.  On the first count,
you see people complain mindlesslly that "in framework X you have to
extend a base class".  Now while adding a support base class wouldn't
mean that, it'd be easy enough to mis-interpret at first glance.

Even if we did add a BaseActionBean we'd have to be exceedingly careful
not to add much useful functionality to it otherwise it would become a
de-facto replacement for the ActionBean interface....

I actually kinda like that the current setup forces people to think
about creating their own base class sooner rather than later (how many
times can you write getContext/setContext() before it becomes
tiresome?).  If we added a base class it'd be very easy to ignore your
own inheritance hierarchy....

-t


On 2006-10-12 18:33:53 -0400, "Dmitri Colebatch"
<[hidden email]> said:

> Sorry - I've now read (and voted for) the bug... Tim, unless I'm
> missing something, what's suggested in the bug isn't asking for a
> change to the ActionBean interface.  I don' understand what your
> concern is - I would envisage that the quickstart guide would stay as
> is, and the BaseActionBean in the bug would be a useful thing for
> people to use once they need it.
>
> cheers
> dim
>
> On 10/13/06, Dmitri Colebatch
> <[hidden email]> wrote:
>> I must be missing something, what's wrong with this:
>>
>> public class BaseActionBean<C extends ActionBeanContext> implements ActionBean
>> {
>> private C context;
>>
>> public void setContext(ActionBeanContext context)
>> {
>> this.context = (C) context;
>> }
>>
>> public C getContext()
>> {
>> return context;
>> }
>> }
>>
>> Simply add that class to stripes as is and you have a best of both
>> worlds - no change to the ActionBean interface, but you also provide a
>> useful base class that (I believe) satisfies the requirements raised
>> in this thread.
>>
>> cheers
>> dim
>>
>> On 10/13/06, Tim Fennell
>> <[hidden email]> wrote:
>>> My concern over this is that ActionBean is pretty much the first class any
>>> new user encounters with Stripes.  As such, seeing a nice plain interface
>>> like:
>>>
>>> interface ActionBean {
>>> ActionBeanContext getContext();
>>> void setContext(ActionBeanContext ctx);
>>> }
>>>
>>> is good because it's really not much to understand at first blush.  But
>>> compare that to (as it would have to correctly be specified):
>>>
>>> interface ActionBean<T extends ActionBeanContext> {
>>> T getContext();
>>> void setContext(T ctx);
>>> }
>>>
>>> If you haven't spent any time with generics, that's rather a lot to take in.
>>> Is this problem of overriding the getContext() method (once in a base
>>> class) so bad that we'd want to impose this on new users?
>>>
>>> -t
>>>
>>>
>>> On Oct 12, 2006, at 2:40 PM, Ben Gunter wrote:
>>> I suggested this very thing in STS-206 on June 17. If you want to vote for
>>> it, you can. Tim posted some comments there giving reasons he might not want
>>> to do that.
>>>
>>> http://stripes.mc4j.org/jira/browse/STS-206
>>>
>>> I did not suggest adding a type parameter to the ActionBean interface, only
>>> to the abstract base class that implements it. But I think ActionBean could
>>> be changed to ActionBean<T extends ActionBeanContext> and still be backward
>>> compatible so that's a good idea. Even better, Stripes could look at the
>>> type parameter to determine what ActionBeanContext subclass to instantiate.
>>>
>>> So yeah, I do think this is a good idea.
>>>
>>> -Ben
>>>
>>> Sebastian Wiemer wrote:
>>> Ok i see, the annotation is not really necessary ;)
>>
>> But how about another
>>> suggestion. How to extend the ActionBean interface like
>>
>> public interface
>>> ActionBean {
>> public T getContext();
>> public void setContext( T context
>>> );
>> }
>>
>> This would allow stripes to provide a base class like
>>
>> public abstract
>>> class StripesActionBean implements ActionBean {
>> private T
>>> actionBeanContext;
>> public T getContext() { return( this.actionBeanContext
>>> ); }
>> public void setContext( T context ) { this.actionBeanContext =
>>> context; }
>> }
>>
>> Therefore no more need to implements getContext() and
>>> setContext() in all
>> ActionBeans of your application.
>>
>> Just to an
>> public
>>> class MyActionBean extends StripesActionBean {
>> // no more getContext()
>>> setContext() anymore ;)
>>
>> public Resolution foo() {
>>> getContext().getMySpecialValue();
>> }
>> }
>>
>> And stripes will
>>> still have to initiate the corret generic type of
>> ActionBeanContext an
>>> LifecycleStage.ActionBeanResolution
>>>
>>
>> Isn't that much more cleaner since you never have to cast any context
>>>
>> anymore ? Btw. i think this would also solve Gary Moselene's problem,
>>> doesn't
>> it ?
>> Did i miss something ?



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users