Well, I have the 1.1.2 stuff for StrategyFactory done.  However, it is
required for what I need to do for the new ExceptionPresenter "framework."
So, I guess I'll try to get a 1.1.2 release out the door quickly (I'm the
HiveMind chair now, so I guess that's on me; Howard, I might need some help
from you).  Then, we can get this stuff into Tapestry.  To recap, here's
what I'm going to do:

1.  Create a new ExceptionPresenter service that's strategy-based...

<configuration id="ExceptionPresenterStrategies"
schema-id="hivemind.lib.StrategyRegistry" />

<service-point id="ExceptionPresenterTerminator"
interface="ExceptionPresenter">
  <invoke-factory service-id="hivemind.lib.StrategyFactory">
    <construct configuration-id="ExceptionPresenterStrategies"
parameterIndex="1"/>
  </invoke-factory>
</service-point>

2.  Register the current implementation as the "strategy" for
java.lang.Throwable...
 
<service-point id="DefaultExceptionPresenter"
interface="ExceptionPresenter">
  <invoke-factory>
    <construct class="ExceptionPresenterImpl" >
      <set-object property="exceptionPageName" 
                  value="infrastructure:exceptionPageName"/>
      <set-object property="requestExceptionReporter"
                  value="infrastructure:requestExceptionReporter"/>
      <set-object property="responseRenderer"
                  value="infrastructure:responseRenderer"/>
    </construct>
  </invoke-factory>
</service-point>

<contribution configuration-id="ExceptionPresenterStrategies">
  <strategy class="java.lang.Throwable"
object="service:DefaultExceptionPresenter"/>
</contribution>

3.  Create a new ExceptionPresenterFilter interface...

package org.apache.tapestry.error.ExceptionPresenter;

public interface ExceptionPresenterFilter
{
  public void presentException(IRequestCycle requestCycle, Throwable cause,
ExceptionPresenter next);
}

4.  Change the current tapestry.error.ExceptionPresenter service point to be
pipeline-based...

<configuration id="ExceptionPresenterFilters"
schema-id="hivemind.lib.Pipeline" />

<service-point id="ExceptionPresenter" interface="ExceptionPresenter">
  <invoke-factory service-id="hivemind.lib.PipelineFactory">
    <create-pipeline filter-interface="ExceptionPresenterFilter"
                     configuration-id="ExceptionPresenterFilters"
                     terminator="service:ExceptionPresenterTerminator" />
  </invoke-factory>
</service-point>

This way, it is 100% backward compatible.  For those folks who were
overriding the tapestry.error.ExceptionPresenter service point completely,
it will still work.  For those who wish to try the new stuff, they can by
either plugging in a filter or creating a strategy.  It's up to them.


-----Original Message-----
From: James Carman [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 14, 2006 10:39 AM
To: 'Tapestry development'
Subject: RE: ExceptionPresenter...

I'm working on it now and have it working with test cases.  We'll have to
release 1.1.2 with it in there.

-----Original Message-----
From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 14, 2006 10:38 AM
To: Tapestry development
Subject: Re: ExceptionPresenter...

ExceptionPresenter is the appropriate "hook" for any kind of exception
related logic.

I see what you mean about a parameterIndex for the StrategyFactory.

On 6/14/06, James Carman <[EMAIL PROTECTED]> wrote:
>
> All,
>
> Is ExceptionPresenter the best place to put generalized exception-handling
> logic?  I have an idea to refactor it even further than making it a
> pipeline.  It could be even better if we could make the endpoint of the
> pipeline a "strategy" using HiveMind's StrategyFactory (hivemind.lib
> module).  We'd need to beef it up a bit, because it uses the type of the
> first method argument to find the appropriate strategy to use and
> ExceptionPresenter's first argument is IRequestCycle.  We need to allow
> the
> "parameterIndex" to be customized.  The overall ExceptionPresenter service
> point would still be a pipeline, but the terminator would be a service
> point
> which is a strategy-based service.  The default strategy for Object (the
> catch-all) would probably be what it does now.  That would allow folks to
> hook in a strategy for Throwable to short-circuit it.  What do you think?
>
> James
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to