[
https://issues.apache.org/jira/browse/WICKET-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871237#action_12871237
]
bernard commented on WICKET-2881:
---------------------------------
Hi Juergen,
Thanks very much again for the additional information. In principle, I had
already implemented what you are suggesting, with info from
http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
As you can see from my attached directory structure and sample markup file, my
HTML file structure matches the Java package structure, so I don't need a new
ResourceStreamLocator, only the part
resourceSettings.addResourceFolder("wicket");
where "wicket" matches web.xml filter-mapping so that the the filter mapping
hides the "wicket" folder from direct web access.
I don't want to distract too much from my goal which is to code resource URLs
that are resolved offline, and therefore something with the effect of the
suggested change in RelativePathPrefixHandler. BTW the suggested change does
not look as if it would have a functional impact on normal Wicket behavior.
I need support for this otherwise I don't know how to get HTML refactoring
across all HTML files.
In other words being able to "Control where HTML files are loaded from" is only
half of what I need.
> Cannot substitute RelativePathPrefixHandler
> -------------------------------------------
>
> Key: WICKET-2881
> URL: https://issues.apache.org/jira/browse/WICKET-2881
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.8
> Environment: All
> Reporter: bernard
>
> In IPageSettings
> Get the (modifiable) list of IComponentResolvers.
> List<IComponentResolver> getComponentResolvers();
> This looks very useful and easy indeed, and in Application.init() one can
> find and remove
> RelativePathPrefixHandler and replace it with a different
> AbstractMarkupFilter implementation e.g. XRelativePathPrefixHandler.
> But even while the List.remove(Object o) returns true, and the handler
> appears to be removed, it is still active.
> I don't know why and what holds on to it or what creates a new
> RelativePathPrefixHandler.
> If I add my XRelativePathPrefixHandler, it is not used.
> Consider
> public class MarkupParser
> public final void appendMarkupFilter(final IMarkupFilter filter)
> {
> appendMarkupFilter(filter, RelativePathPrefixHandler.class);
> }
> So RelativePathPrefixHandler seems to be something special and I am afraid of
> other potential complications in case replacement would work.
> Can Wicket be fixed to make a replacement as easy as it appears to be?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
