[ 
https://issues.apache.org/jira/browse/WICKET-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885051#action_12885051
 ] 

Hudson commented on WICKET-2485:
--------------------------------

Integrated in Apache Wicket 1.5.x #128 (See 
[http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.5.x/128/])
    fixed WICKET-2485: issue fixed in 1.5 
Issue: WICKET-2485


> IComponentResolvers are not supported inside wicket:enclosure
> -------------------------------------------------------------
>
>                 Key: WICKET-2485
>                 URL: https://issues.apache.org/jira/browse/WICKET-2485
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.4.1
>         Environment: Java 6
> JDO implementation: DataNucleus
> IOC: exPOJO
>            Reporter: Chris Colman
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.2, 1.5-M1
>
>         Attachments: enclosurebug.zip
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Wicket has a very powerful IComponentResolver interface that allows a 
> developer to supply their own IComponentResolver implementation which allows 
> component based assembly of pages from a prebuilt collection of panels 
> without needing to make hard coded instantiations of the entire set of panels 
> into *every* page class that *may* use them. This flexibility is incredibly 
> powerful and means that a great amount of page assembly can take place purely 
> in the markup.
> Unfortunately any components embedded within a <wicket:enclosure> markup 
> </wicket:enclosure> tag (and possibly other 'wrapping' style tags like 
> wicket:border) will not trigger the normal 'component resolution' process 
> that calls the IComponentResolver implementation and so the children cause a 
> 'component not found' page crash unless they are explicitly added to the page 
> that will contain them.
> This is extremely undesirable because there can be potentially many, many 
> choices of components/panels that can be enclosed. For reasons of 
> flexibility, code maintainability, efficient CPU and memory usage it is 
> undesirable to add the entire collection of child component candidates to 
> every page that could get instantiated with an enclosure in it.
> This bug is trivial to reproduce - set up an IComponentResolver that resolves 
> a simple panel, do not add that panel explicitly to a page, but refer to it 
> inside a wicket:enclosure tag in the page markup. Display the page in a 
> browser.
> I think this would be a fairly straightforward fix for someone who has a good 
> understanding of the wicket framework lifecycles. I had a few attempts at 
> rectifying the issue but after much trial and error seem unable to locate the 
> appropriate place for the 'component resolution' to be triggered.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to