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]