Re: Standalone Tiles: Status and Call for Help

[Craig McClanahan <cr...@apache.org>]

On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
>
>
> On Mar 21, 2006, at 4:45 PM, Gary VanMatre wrote:
>
> > I suppose that the choice of the context object could favor action
> > versus shale for a test framework.
> >
> > Since I'm in the JSF fan club, I'd argue that we could implement
> > the ExternalContext interface since the JSF API will soon be a given.
>
> I haven't thought about implementing it directly.  That's
> interesting.  I'd proceed cautiously though.  My thinking (hope this
> is not news to anyone) is that Standalone Tiles will eventually just
> be "Tiles" :-)  As such I hope it is useful to everyone who is
> currently using Tiles, including Struts Action, WebWork, etc.  I
> wouldn't want to do anything that would make this impossible, or even
> difficult.  At the same time I don't want to reinvent (or subclass)
> the wheel so I'm open to ideas.


For a library claiming to be "standalone", I would be a little cautious
about depending on either set of mock object APIs.  That being said, the
Shale test framework mock objects for servlet and JSP stuff can be used even
without JSF in the picture, so it might be a practical choice after all.
But you certainly would not want to program directly to any JSF APIs here.

Greg
>
> PS: Not to open up another tanker of worms, but is it possible to be
> in the the JSF and action fan club at the same time?  Hmmm.
> Conflicted, I am.


It *looks* quite possible to get *some* combinations of benefits, with a
couple of different approaches:

APPROACH 1:

For example, Shale offers an applicaton controller (implemented as a Filter)
that lets you use Commons Chain to define the global pre- and post-
processing that is done on every request (the sort of change you would
implement by modifying RequestProcessor in 1.1/1.2, or the global chain
implementation in 1.3).  On my list of things to investigate is whether that
could be substituted out for a gadget that uses XWork (the action processing
framework that underlies WebWork) to gain access to the cool intercepter
stuff.

The other place that you'd want to hook in is the equivalent of where your
action's execution method gets called, so you can decorate individual logic
paths with local customizations.  Turns out that JSF lets you customize that
as well, so we can do the same sort of trick here.

Jason/Patrick/Don/Ted/Martin -- are any of you guys going to be at TSSJS
later this week?  I'd sure like to sit down and walk through whether this is
as feasible in code as it appears to be on the back of a napkin.

APPROACH 2:

Use the struts-faces library, and focus on just using the components parts
of JSF while using the framework part from Struts.  If you look at the
internal architecture it ends up looking a little odd (the JSF front
controller is in front of the Struts front controller), but it can actually
work.  This is also a reasonable approach if you are required to migrate an
existing Struts based app to JSF and cannot take the time to do it all over
again.

Craig

Re: Standalone Tiles: Status and Call for Help

[Paul Benedict <pa...@yahoo.com>]

>> there's no current implementatino of things like MockPageContext

Craig, there is one in the Spring Framework library. :) Spring contains mocks
of the servlet api. The library doesn't depend on Spring, but they have 
their own mocks. Spring uses the MockPageContext to write unit tests for 
their tag libraries. Greg I recommend you look into this.

Paul

--- Craig McClanahan <cr...@apache.org> wrote:

> On 3/22/06, Greg Reddin <gr...@apache.org> wrote:
> >
> >
> > On Mar 21, 2006, at 6:04 PM, Craig McClanahan wrote:
> >
> > > For a library claiming to be "standalone", I would be a little
> > > cautious
> > > about depending on either set of mock object APIs.
> >
> > Certainly, no such dependencies should be in the core software, but
> > dependencies in the test cases are acceptable, right?  I suppose we
> > could modify the existing tests to use mock implementations of the
> > context once we get that figured out.  Even so, context
> > implementations that work with Servlet API, Faces, Portlet, etc. will
> > need tests.  Does all that stuff need to be optional?
> 
> 
> I was rambling a bit in that paragraph (and I seem to have changed my mind
> about half way through :-) ... let me try to be a little clearer.
> 
> The Shale test framework classes include mock implementations of essentially
> all APIs in the servlet spec (as well as JSF, but that's not really relevant
> here).  As such, it can be used as a source of things like
> MockServletContext, MockHttpServletRequest, and so on.  It *should* be
> possible to use this jar file for Tiles tests, even if you don't have
> jsf-api.jar in the classpath, as long as you don't try to use things like
> MockFacesContext.  The end result is we should be able to construct JUnit
> based tests for nearly everything in standalone Tiles, without the
> complexity of Cactus tests.  (For in container testing, I prefer to set up a
> "real" app and then exercise it with things like HtmlUnit.)
> 
> The only place it might fall down a little for you is in testing custom tags
> ... there's no current implementatino of things like MockPageContext.
> That's a solvable problem, though, by just writing a few more classes.
> 
> Greg
> 
> 
> Craig
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Standalone Tiles: Status and Call for Help

[Greg Reddin <gr...@apache.org>]

On Mar 22, 2006, at 11:45 AM, Craig McClanahan wrote:

> The Shale test framework classes include mock implementations of  
> essentially
> all APIs in the servlet spec (as well as JSF, but that's not really  
> relevant
> here).  As such, it can be used as a source of things like
> MockServletContext, MockHttpServletRequest, and so on.  It *should* be
> possible to use this jar file for Tiles tests, even if you don't have
> jsf-api.jar in the classpath, as long as you don't try to use  
> things like
> MockFacesContext.  The end result is we should be able to construct  
> JUnit
> based tests for nearly everything in standalone Tiles, without the
> complexity of Cactus tests.  (For in container testing, I prefer to  
> set up a
> "real" app and then exercise it with things like HtmlUnit.)
>
> The only place it might fall down a little for you is in testing  
> custom tags
> ... there's no current implementatino of things like MockPageContext.
> That's a solvable problem, though, by just writing a few more classes.

Ok, thanks for the clarification.  I'm cool with that.

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Standalone Tiles: Status and Call for Help

[Craig McClanahan <cr...@apache.org>]

On 3/22/06, Greg Reddin <gr...@apache.org> wrote:
>
>
> On Mar 21, 2006, at 6:04 PM, Craig McClanahan wrote:
>
> > For a library claiming to be "standalone", I would be a little
> > cautious
> > about depending on either set of mock object APIs.
>
> Certainly, no such dependencies should be in the core software, but
> dependencies in the test cases are acceptable, right?  I suppose we
> could modify the existing tests to use mock implementations of the
> context once we get that figured out.  Even so, context
> implementations that work with Servlet API, Faces, Portlet, etc. will
> need tests.  Does all that stuff need to be optional?


I was rambling a bit in that paragraph (and I seem to have changed my mind
about half way through :-) ... let me try to be a little clearer.

The Shale test framework classes include mock implementations of essentially
all APIs in the servlet spec (as well as JSF, but that's not really relevant
here).  As such, it can be used as a source of things like
MockServletContext, MockHttpServletRequest, and so on.  It *should* be
possible to use this jar file for Tiles tests, even if you don't have
jsf-api.jar in the classpath, as long as you don't try to use things like
MockFacesContext.  The end result is we should be able to construct JUnit
based tests for nearly everything in standalone Tiles, without the
complexity of Cactus tests.  (For in container testing, I prefer to set up a
"real" app and then exercise it with things like HtmlUnit.)

The only place it might fall down a little for you is in testing custom tags
... there's no current implementatino of things like MockPageContext.
That's a solvable problem, though, by just writing a few more classes.

Greg


Craig

Re: Standalone Tiles: Status and Call for Help

[Greg Reddin <gr...@apache.org>]

On Mar 21, 2006, at 6:04 PM, Craig McClanahan wrote:

> For a library claiming to be "standalone", I would be a little  
> cautious
> about depending on either set of mock object APIs.

Certainly, no such dependencies should be in the core software, but  
dependencies in the test cases are acceptable, right?  I suppose we  
could modify the existing tests to use mock implementations of the  
context once we get that figured out.  Even so, context  
implementations that work with Servlet API, Faces, Portlet, etc. will  
need tests.  Does all that stuff need to be optional?

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Standalone Tiles: Status and Call for Help

[Martin Cooper <ma...@apache.org>]

On 3/21/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
> >
> >
> > On Mar 21, 2006, at 4:45 PM, Gary VanMatre wrote:
> >
> > > I suppose that the choice of the context object could favor action
> > > versus shale for a test framework.
> > >
> > > Since I'm in the JSF fan club, I'd argue that we could implement
> > > the ExternalContext interface since the JSF API will soon be a given.
> >
> > I haven't thought about implementing it directly.  That's
> > interesting.  I'd proceed cautiously though.  My thinking (hope this
> > is not news to anyone) is that Standalone Tiles will eventually just
> > be "Tiles" :-)  As such I hope it is useful to everyone who is
> > currently using Tiles, including Struts Action, WebWork, etc.  I
> > wouldn't want to do anything that would make this impossible, or even
> > difficult.  At the same time I don't want to reinvent (or subclass)
> > the wheel so I'm open to ideas.
>
>
> For a library claiming to be "standalone", I would be a little cautious
> about depending on either set of mock object APIs.  That being said, the
> Shale test framework mock objects for servlet and JSP stuff can be used
> even
> without JSF in the picture, so it might be a practical choice after all.
> But you certainly would not want to program directly to any JSF APIs here.


I've heard a lot of good things about EasyMock, although I haven't used it
myself.

http://www.easymock.org/

Greg
> >
> > PS: Not to open up another tanker of worms, but is it possible to be
> > in the the JSF and action fan club at the same time?  Hmmm.
> > Conflicted, I am.
>
>
> It *looks* quite possible to get *some* combinations of benefits, with a
> couple of different approaches:
>
> APPROACH 1:
>
> For example, Shale offers an applicaton controller (implemented as a
> Filter)
> that lets you use Commons Chain to define the global pre- and post-
> processing that is done on every request (the sort of change you would
> implement by modifying RequestProcessor in 1.1/1.2, or the global chain
> implementation in 1.3).  On my list of things to investigate is whether
> that
> could be substituted out for a gadget that uses XWork (the action
> processing
> framework that underlies WebWork) to gain access to the cool intercepter
> stuff.
>
> The other place that you'd want to hook in is the equivalent of where your
> action's execution method gets called, so you can decorate individual
> logic
> paths with local customizations.  Turns out that JSF lets you customize
> that
> as well, so we can do the same sort of trick here.
>
> Jason/Patrick/Don/Ted/Martin -- are any of you guys going to be at TSSJS
> later this week?  I'd sure like to sit down and walk through whether this
> is
> as feasible in code as it appears to be on the back of a napkin.


Sadly, no. My employer appears to be increasingly stingy on conferences this
year. ;-(

--
Martin Cooper


APPROACH 2:
>
> Use the struts-faces library, and focus on just using the components parts
> of JSF while using the framework part from Struts.  If you look at the
> internal architecture it ends up looking a little odd (the JSF front
> controller is in front of the Struts front controller), but it can
> actually
> work.  This is also a reasonable approach if you are required to migrate
> an
> existing Struts based app to JSF and cannot take the time to do it all
> over
> again.
>
> Craig
>
>