I'm ready to commit this, but I guess I will wait until Don cuts the
new build. This is how it works:

1. Static content lookup was refactored to DefaultStaticContentLoader
which implements StaticContentLoader.
2. DefaultStaticContentLoader  does everything FilterDipatcher did
before, but it also searches for resources inside a folder called
"static". So users don't have to call the folder "struts". New folders
can be added passing parameters to FilterDispatcher, like before, but
the urls have to starts with "/static" so we have some way to identify
them.
3. New extension point added "struts.staticContentLoader" to provide a
custom loader

So the 2 uses cases are:

1. User wants to add a new resource called "test.js" to her plugin.
She adds this file under "/static/test.js" and builds the url like:
    <s:url value="/static/test.js" ..>

2. User wants to add a new resource called "test.js" to her plugin
under folder "/super_folder/test.js". She adds a parameter to the
filter:
  <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
  <init-param>
       <param-name>pathPrefixes</param-name>
       <param-value>/super_folder</param-value>
  </init-param>

  and builds the url like:
  <s:url value="/static/test.js" ..>


musachy


On Wed, Apr 30, 2008 at 10:35 PM, Jeromy Evans
<[EMAIL PROTECTED]> wrote:
> Musachy Barroso wrote:
>
> > I am refactoring that out of FilterDispatcher so it becomes another
> > extension point.
> >
> > musachy
> >
> >
> >
>  +1
>
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

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

Reply via email to