You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Oli Evans (JIRA)" <ji...@apache.org> on 2007/09/04 17:50:44 UTC
[jira] Created: (WICKET-927) Deprecate Fragment constructors that
dont take a markup provider
Deprecate Fragment constructors that dont take a markup provider
----------------------------------------------------------------
Key: WICKET-927
URL: https://issues.apache.org/jira/browse/WICKET-927
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.0-beta3
Reporter: Oli Evans
Priority: Minor
Fix For: 1.3.0-final
>From the wicket dev mailing list:
seems this is confusing a lot of users and it doesnt work the greatest, so
here is a vote
so the vote is to deprecate the constructor variants that do not take a
markup provider as an arg.
-igor
On 8/29/07, Oli Evans <ol...@needleandthread.org> wrote:
> >
> > I just lost a few hours on a problem where an ajax operation on a Panel
> > nested in a Fragment was failing as my nested panel could not find its
> > associated markup. It seems this was because a Fragment will only
> > reliably find its markup if you explicitly provide it with the Component
> > that contains its markup in the Fragment constructor.
> >
> > If you don't, Fragment.getAssociatedMarkupStream() will find its
> > markupProvider field is null, and so have to take a guess at where its
> > markup might be. If your fragment usage happens to be as a direct child
> > of the component that defines the fragment markup then it will all work
> > out, but if you have nested it in something like a ListView then it will
> > fail.
> >
> > ...So watch out kids, if you use fragments, use a constructor that tells
> > it where its markup is. Would you like to have to guess who your real
> > parents are? I think not.
> >
> > Oli
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-927) Deprecate Fragment constructors that
dont take a markup provider
Posted by "Oli Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oli Evans updated WICKET-927:
-----------------------------
Fix Version/s: (was: 1.3.0-final)
> Deprecate Fragment constructors that dont take a markup provider
> ----------------------------------------------------------------
>
> Key: WICKET-927
> URL: https://issues.apache.org/jira/browse/WICKET-927
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.0-beta3
> Reporter: Oli Evans
> Priority: Minor
>
> From the wicket dev mailing list:
> seems this is confusing a lot of users and it doesnt work the greatest, so
> here is a vote
> so the vote is to deprecate the constructor variants that do not take a
> markup provider as an arg.
> -igor
> On 8/29/07, Oli Evans <ol...@needleandthread.org> wrote:
> > >
> > > I just lost a few hours on a problem where an ajax operation on a Panel
> > > nested in a Fragment was failing as my nested panel could not find its
> > > associated markup. It seems this was because a Fragment will only
> > > reliably find its markup if you explicitly provide it with the Component
> > > that contains its markup in the Fragment constructor.
> > >
> > > If you don't, Fragment.getAssociatedMarkupStream() will find its
> > > markupProvider field is null, and so have to take a guess at where its
> > > markup might be. If your fragment usage happens to be as a direct child
> > > of the component that defines the fragment markup then it will all work
> > > out, but if you have nested it in something like a ListView then it will
> > > fail.
> > >
> > > ...So watch out kids, if you use fragments, use a constructor that tells
> > > it where its markup is. Would you like to have to guess who your real
> > > parents are? I think not.
> > >
> > > Oli
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-927) Deprecate Fragment constructors that
dont take a markup provider
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-927:
---------------------------------
Assignee: Igor Vaynberg
> Deprecate Fragment constructors that dont take a markup provider
> ----------------------------------------------------------------
>
> Key: WICKET-927
> URL: https://issues.apache.org/jira/browse/WICKET-927
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.0-beta3
> Reporter: Oli Evans
> Assignee: Igor Vaynberg
> Priority: Minor
>
> From the wicket dev mailing list:
> seems this is confusing a lot of users and it doesnt work the greatest, so
> here is a vote
> so the vote is to deprecate the constructor variants that do not take a
> markup provider as an arg.
> -igor
> On 8/29/07, Oli Evans <ol...@needleandthread.org> wrote:
> > >
> > > I just lost a few hours on a problem where an ajax operation on a Panel
> > > nested in a Fragment was failing as my nested panel could not find its
> > > associated markup. It seems this was because a Fragment will only
> > > reliably find its markup if you explicitly provide it with the Component
> > > that contains its markup in the Fragment constructor.
> > >
> > > If you don't, Fragment.getAssociatedMarkupStream() will find its
> > > markupProvider field is null, and so have to take a guess at where its
> > > markup might be. If your fragment usage happens to be as a direct child
> > > of the component that defines the fragment markup then it will all work
> > > out, but if you have nested it in something like a ListView then it will
> > > fail.
> > >
> > > ...So watch out kids, if you use fragments, use a constructor that tells
> > > it where its markup is. Would you like to have to guess who your real
> > > parents are? I think not.
> > >
> > > Oli
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-927) Deprecate Fragment constructors that
dont take a markup provider
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-927:
---------------------------------
Fix Version/s: 1.3.0-beta4
> Deprecate Fragment constructors that dont take a markup provider
> ----------------------------------------------------------------
>
> Key: WICKET-927
> URL: https://issues.apache.org/jira/browse/WICKET-927
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.0-beta3
> Reporter: Oli Evans
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.3.0-beta4
>
>
> From the wicket dev mailing list:
> seems this is confusing a lot of users and it doesnt work the greatest, so
> here is a vote
> so the vote is to deprecate the constructor variants that do not take a
> markup provider as an arg.
> -igor
> On 8/29/07, Oli Evans <ol...@needleandthread.org> wrote:
> > >
> > > I just lost a few hours on a problem where an ajax operation on a Panel
> > > nested in a Fragment was failing as my nested panel could not find its
> > > associated markup. It seems this was because a Fragment will only
> > > reliably find its markup if you explicitly provide it with the Component
> > > that contains its markup in the Fragment constructor.
> > >
> > > If you don't, Fragment.getAssociatedMarkupStream() will find its
> > > markupProvider field is null, and so have to take a guess at where its
> > > markup might be. If your fragment usage happens to be as a direct child
> > > of the component that defines the fragment markup then it will all work
> > > out, but if you have nested it in something like a ListView then it will
> > > fail.
> > >
> > > ...So watch out kids, if you use fragments, use a constructor that tells
> > > it where its markup is. Would you like to have to guess who your real
> > > parents are? I think not.
> > >
> > > Oli
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-927) Deprecate Fragment constructors that
dont take a markup provider
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-927.
----------------------------------
Resolution: Fixed
> Deprecate Fragment constructors that dont take a markup provider
> ----------------------------------------------------------------
>
> Key: WICKET-927
> URL: https://issues.apache.org/jira/browse/WICKET-927
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.0-beta3
> Reporter: Oli Evans
> Assignee: Igor Vaynberg
> Priority: Minor
>
> From the wicket dev mailing list:
> seems this is confusing a lot of users and it doesnt work the greatest, so
> here is a vote
> so the vote is to deprecate the constructor variants that do not take a
> markup provider as an arg.
> -igor
> On 8/29/07, Oli Evans <ol...@needleandthread.org> wrote:
> > >
> > > I just lost a few hours on a problem where an ajax operation on a Panel
> > > nested in a Fragment was failing as my nested panel could not find its
> > > associated markup. It seems this was because a Fragment will only
> > > reliably find its markup if you explicitly provide it with the Component
> > > that contains its markup in the Fragment constructor.
> > >
> > > If you don't, Fragment.getAssociatedMarkupStream() will find its
> > > markupProvider field is null, and so have to take a guess at where its
> > > markup might be. If your fragment usage happens to be as a direct child
> > > of the component that defines the fragment markup then it will all work
> > > out, but if you have nested it in something like a ListView then it will
> > > fail.
> > >
> > > ...So watch out kids, if you use fragments, use a constructor that tells
> > > it where its markup is. Would you like to have to guess who your real
> > > parents are? I think not.
> > >
> > > Oli
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.