[jira] Commented: (WICKET-2485) IComponentResolvers are not supported inside wicket:enclosure

["Chris Colman (JIRA)" <ji...@apache.org>]

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

Chris Colman commented on WICKET-2485:
--------------------------------------

Excellent! Once again, thanks Igor for a great framework.

]
https://issues.apache.org/jira/browse/WICKET-2485
a
set
flexibility is
markup
process
cause
the
is
to
but
the
has a
to



> 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.