WICKET-5226 breaks many wicket-cdi applications
Hi all,
The changes made for WICKET-5226 (no longer injecting anonymous inner
classes) breaks our applications badly, and I suspect we are not the only
one. The following pattern is quite common:
add(new LinkVoid(rest) {
@Inject
private AccountRestResourceClient accountClient;
@Override
public void onClick() {}
}
In Wicket 6.9.0, this no longer works: accountClient will not get injected
because the Link is an anonymous inner class. To make things worse, even
in concrete classes, you can't rely on injection to work, because someone
could subclass your class as an anonymous inner class and injection will
again not work.
This change was made because Weld 2.0 throws an exception when trying
to create an InjectionTarget for anonymous classes. This will be reduced to
a log-warning in 2.0.2: https://issues.jboss.org/browse/WELD-1441
As there is no workaround for this problem and it is likely to break all
applications using wicket-cdi, I'm starting a vote to revert the changes
made for 5226 and release 6.9.1:
[ ] Yes, revert 5226 and release 6.9.1
[ ] No, revert 5226 but not release 6.9.1
[ ] No, keep as is
See WICKET-5264
Best regards,
Emond
Re: WICKET-5226 breaks many wicket-cdi applications
On Wed, Jul 3, 2013 at 11:09 AM, Emond Papegaaij emond.papega...@topicus.nl
wrote:
Hi all,
The changes made for WICKET-5226 (no longer injecting anonymous inner
classes) breaks our applications badly, and I suspect we are not the only
one. The following pattern is quite common:
add(new LinkVoid(rest) {
@Inject
private AccountRestResourceClient accountClient;
Nothing wrong with this code but this is the first time I see this pattern.
@Override
public void onClick() {}
}
In Wicket 6.9.0, this no longer works: accountClient will not get injected
because the Link is an anonymous inner class. To make things worse, even
in concrete classes, you can't rely on injection to work, because someone
could subclass your class as an anonymous inner class and injection will
again not work.
This change was made because Weld 2.0 throws an exception when trying
to create an InjectionTarget for anonymous classes. This will be reduced to
a log-warning in 2.0.2: https://issues.jboss.org/browse/WELD-1441
https://issues.jboss.org/browse/WFLY-1378?focusedCommentId=12776674page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12776674
talks
about wrongusage of BeanManager.createInjectionTarget() in wicket-cdi.
As there is no workaround for this problem and it is likely to break all
applications using wicket-cdi, I'm starting a vote to revert the changes
made for 5226 and release 6.9.1:
[ x ] Yes, revert 5226 and release 6.9.1
wicket-cdi-1.1 also does this + some more blacklisting. Any reviews are
welcome!
[ ] No, revert 5226 but not release 6.9.1
[ ] No, keep as is
See WICKET-5264
Best regards,
Emond
Re: WICKET-5226 breaks many wicket-cdi applications
Here's my vote:
[X] Yes, revert 5226 and release 6.9.1
Emond
On Wednesday 03 July 2013 10:09:33 Emond Papegaaij wrote:
Hi all,
The changes made for WICKET-5226 (no longer injecting anonymous
inner
classes) breaks our applications badly, and I suspect we are not the
only
one. The following pattern is quite common:
add(new LinkVoid(rest) {
@Inject
private AccountRestResourceClient accountClient;
@Override
public void onClick() {}
}
In Wicket 6.9.0, this no longer works: accountClient will not get injected
because the Link is an anonymous inner class. To make things worse,
even
in concrete classes, you can't rely on injection to work, because
someone
could subclass your class as an anonymous inner class and injection will
again not work.
This change was made because Weld 2.0 throws an exception when
trying
to create an InjectionTarget for anonymous classes. This will be reduced
to
a log-warning in 2.0.2: https://issues.jboss.org/browse/WELD-1441
As there is no workaround for this problem and it is likely to break all
applications using wicket-cdi, I'm starting a vote to revert the changes
made for 5226 and release 6.9.1:
[ ] Yes, revert 5226 and release 6.9.1
[ ] No, revert 5226 but not release 6.9.1
[ ] No, keep as is
See WICKET-5264
Best regards,
Emond
Re: WICKET-5226 breaks many wicket-cdi applications
Here are the commits for WELD-1441:
https://github.com/weld/core/commit/569c8efc5f0dd1dcc9c942fd3dd8c1f65a216b9e
https://github.com/weld/core/commit/9e248b5306b382f88f41cca1325178ed6fbe4306
What bothers me is
https://github.com/weld/core/commit/569c8efc5f0dd1dcc9c942fd3dd8c1f65a216b9e#L1R55
It throws CreationException for abstract classes and non-static-inner ones.
Anonymous are not even mentioned in this ticket and its commits. And Weld
2.0 does fail when processing an anonymous class!
I'm just saying that after reverting this change Wicket+Weld 2.0.2 users
will see their apps failing again, no matter whether they use your pattern
for DI in anonymous classes or not. Weld 2.0.1 throws exception no matter
whether there are @Inject-ed members in the anonymous class or not.
On Wed, Jul 3, 2013 at 11:53 AM, Emond Papegaaij emond.papega...@topicus.nl
wrote:
Here's my vote:
[X] Yes, revert 5226 and release 6.9.1
Emond
On Wednesday 03 July 2013 10:09:33 Emond Papegaaij wrote:
Hi all,
The changes made for WICKET-5226 (no longer injecting anonymous
inner
classes) breaks our applications badly, and I suspect we are not the
only
one. The following pattern is quite common:
add(new LinkVoid(rest) {
@Inject
private AccountRestResourceClient accountClient;
@Override
public void onClick() {}
}
In Wicket 6.9.0, this no longer works: accountClient will not get
injected
because the Link is an anonymous inner class. To make things worse,
even
in concrete classes, you can't rely on injection to work, because
someone
could subclass your class as an anonymous inner class and injection will
again not work.
This change was made because Weld 2.0 throws an exception when
trying
to create an InjectionTarget for anonymous classes. This will be reduced
to
a log-warning in 2.0.2: https://issues.jboss.org/browse/WELD-1441
As there is no workaround for this problem and it is likely to break all
applications using wicket-cdi, I'm starting a vote to revert the changes
made for 5226 and release 6.9.1:
[ ] Yes, revert 5226 and release 6.9.1
[ ] No, revert 5226 but not release 6.9.1
[ ] No, keep as is
See WICKET-5264
Best regards,
Emond
JQuery 1.10.1 dependency also breaks many applications
While I typically agree that using the latest stable versions of things is a good thing™, in this case the almighty gods that maintain jquery have decided to move deprecated APIs from versions prior to 1.9 into a migration plugin. In my opinion they did a major booboo to say the least, and more accurately they fucked up majorly–YOU DON'T REMOVE PUBLIC API IN A MINOR RELEASE! Upgrading to wicket 6.9 breaks all our applications that use any jquery plugin that was developed in the last decade. I think we should not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've caught that though), unless... we forcefully include the jquery migration plugin [1] as well in 6.9 (also available for jquery 2.x). We can make it so that the migration plugin is enabled by default for wicket 6.x applications, and in 7.x by default disabled. As we are already considering 6.9.1, I think we should fix this issue as well in 6.9.1. [ ] Release 6.9.1 with downgrade to jquery 1.8.3 [ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin [ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery 1.10.1 and migration plugin [ ] Don't fix jquery issues WDYT? Martijn [1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: WICKET-5226 breaks many wicket-cdi applications
On Wednesday 03 July 2013 12:07:07 Martin Grigorov wrote:
Here are the commits for WELD-1441:
https://github.com/weld/core/commit/569c8efc5f0dd1dcc9c942fd3dd8c1f6
5a216b9e
https://github.com/weld/core/commit/9e248b5306b382f88f41cca1325178e
d6fbe4306
What bothers me is
https://github.com/weld/core/commit/569c8efc5f0dd1dcc9c942fd3dd8c1f6
5a216b9e
#L1R55 It throws CreationException for abstract classes and non-static-
inner
ones. Anonymous are not even mentioned in this ticket and its commits.
And
Weld 2.0 does fail when processing an anonymous class!
Wicket will never call produce(), as that's the method to get
(create/resolve) an instance of the bean.
I'm just saying that after reverting this change Wicket+Weld 2.0.2 users
will see their apps failing again, no matter whether they use your pattern
for DI in anonymous classes or not. Weld 2.0.1 throws exception no
matter
whether there are @Inject-ed members in the anonymous class or not.
Weld 2.0.1 is broken and broken frameworks break your application. Weld
2.0.2 users should be fine. We should however look at the wicket code and
see if we can cache the InjectionTarget instances. According to the weld
devs, get a new target over and over again for the same class is a bad
idea. But that's something that can go into 6.10
Emond
On Wed, Jul 3, 2013 at 11:53 AM, Emond Papegaaij
emond.papega...@topicus.nl
wrote:
Here's my vote:
[X] Yes, revert 5226 and release 6.9.1
Emond
On Wednesday 03 July 2013 10:09:33 Emond Papegaaij wrote:
Hi all,
The changes made for WICKET-5226 (no longer injecting anonymous
inner
classes) breaks our applications badly, and I suspect we are not the
only
one. The following pattern is quite common:
add(new LinkVoid(rest) {
@Inject
private AccountRestResourceClient accountClient;
@Override
public void onClick() {}
}
In Wicket 6.9.0, this no longer works: accountClient will not get
injected
because the Link is an anonymous inner class. To make things
worse,
even
in concrete classes, you can't rely on injection to work, because
someone
could subclass your class as an anonymous inner class and
injection will
again not work.
This change was made because Weld 2.0 throws an exception when
trying
to create an InjectionTarget for anonymous classes. This will be
reduced
to
a log-warning in 2.0.2: https://issues.jboss.org/browse/WELD-1441
As there is no workaround for this problem and it is likely to break
all
applications using wicket-cdi, I'm starting a vote to revert the
changes
made for 5226 and release 6.9.1:
[ ] Yes, revert 5226 and release 6.9.1
[ ] No, revert 5226 but not release 6.9.1
[ ] No, keep as is
See WICKET-5264
Best regards,
Emond
Re: JQuery 1.10.1 dependency also breaks many applications
[X] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery 1.10.1 and migration plugin IMHO fixes in patch releases should be as small as possible and as clean as possible. Reverting a change that broke things should fix those things again. Using a different strategy (the migration plugin) might break in other ways we do not yet know and we do not have the time to look for these breakages. For 6.10 we have plenty of time to test and the migration plugin should be fine. Best regards, Emond On Wednesday 03 July 2013 11:12:50 Martijn Dashorst wrote: While I typically agree that using the latest stable versions of things is a good thing™, in this case the almighty gods that maintain jquery have decided to move deprecated APIs from versions prior to 1.9 into a migration plugin. In my opinion they did a major booboo to say the least, and more accurately they fucked up majorly–YOU DON'T REMOVE PUBLIC API IN A MINOR RELEASE! Upgrading to wicket 6.9 breaks all our applications that use any jquery plugin that was developed in the last decade. I think we should not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've caught that though), unless... we forcefully include the jquery migration plugin [1] as well in 6.9 (also available for jquery 2.x). We can make it so that the migration plugin is enabled by default for wicket 6.x applications, and in 7.x by default disabled. As we are already considering 6.9.1, I think we should fix this issue as well in 6.9.1. [ ] Release 6.9.1 with downgrade to jquery 1.8.3 [ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin [ ] Don't fix jquery issues WDYT? Martijn [1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin
Re: JQuery 1.10.1 dependency also breaks many applications
On Wed, Jul 3, 2013 at 12:12 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
While I typically agree that using the latest stable versions of
things is a good thing™, in this case the almighty gods that maintain
jquery have decided to move deprecated APIs from versions prior to 1.9
into a migration plugin. In my opinion they did a major booboo to say
the least, and more accurately they fucked up majorly–YOU DON'T REMOVE
PUBLIC API IN A MINOR RELEASE!
Upgrading to wicket 6.9 breaks all our applications that use any
jquery plugin that was developed in the last decade. I think we should
not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've
caught that though), unless... we forcefully include the jquery
migration plugin [1] as well in 6.9 (also available for jquery 2.x).
We can make it so that the migration plugin is enabled by default for
wicket 6.x applications, and in 7.x by default disabled.
As we are already considering 6.9.1, I think we should fix this issue
as well in 6.9.1.
[ ] Release 6.9.1 with downgrade to jquery 1.8.3
[ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin
[ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery
1.10.1 and migration plugin
[X] Don't fix jquery issues
MyApp#init() {
getJavaScriptLibrarySettings().setJQueryReference(new
JavaScriptResourceReference(...,
anyVersionThatWorksForMeUntilIUpgradeMyAppAndPlugins))
}
WDYT?
Martijn
[1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: JQuery 1.10.1 dependency also breaks many applications
i would propose to upgrade jquery with wicket7, not before. [X] Release 6.9.1 with downgrade to jquery 1.8.3, 7.0.0 with jquery 1.10.1 and migration plugin cheers, Michael Am 03.07.2013 um 11:12 schrieb Martijn Dashorst martijn.dasho...@gmail.com : [ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery 1.10.1 and migration plugin
Re: JQuery 1.10.1 dependency also breaks many applications
As we are already considering 6.9.1, I think we should fix this issue
as well in 6.9.1.
[ ] Release 6.9.1 with downgrade to jquery 1.8.3
[ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin
[ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery
1.10.1 and migration plugin
[X] Don't fix jquery issues
MyApp#init() {
getJavaScriptLibrarySettings().setJQueryReference(new
JavaScriptResourceReference(...,
anyVersionThatWorksForMeUntilIUpgradeMyAppAndPlugins))
}
How can the user know what version of jquery API wicket is compatible with?
Re: JQuery 1.10.1 dependency also breaks many applications
Upgrading to wicket 6.9 breaks all our applications Same here :/. With the removal of methods jQuery 1.9.x was a major change! [X] Release 6.9.1 with downgrade to jquery 1.8.3 Sven On 07/03/2013 11:12 AM, Martijn Dashorst wrote: While I typically agree that using the latest stable versions of things is a good thing™, in this case the almighty gods that maintain jquery have decided to move deprecated APIs from versions prior to 1.9 into a migration plugin. In my opinion they did a major booboo to say the least, and more accurately they fucked up majorly–YOU DON'T REMOVE PUBLIC API IN A MINOR RELEASE! Upgrading to wicket 6.9 breaks all our applications that use any jquery plugin that was developed in the last decade. I think we should not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've caught that though), unless... we forcefully include the jquery migration plugin [1] as well in 6.9 (also available for jquery 2.x). We can make it so that the migration plugin is enabled by default for wicket 6.x applications, and in 7.x by default disabled. As we are already considering 6.9.1, I think we should fix this issue as well in 6.9.1. [ ] Release 6.9.1 with downgrade to jquery 1.8.3 [ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin [ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery 1.10.1 and migration plugin [ ] Don't fix jquery issues WDYT? Martijn [1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin
Re: JQuery 1.10.1 dependency also breaks many applications
MyApp#init() {
getJavaScriptLibrarySettings().setJQueryReference(new
JavaScriptResourceReference(...,
anyVersionThatWorksForMeUntilIUpgradeMyAppAndPlugins)) }
Problem is when you're using libraries which are using
JQueryResourceReference.get() hard coded in #getDependencies() :/.
Sven
On 07/03/2013 11:20 AM, Martin Grigorov wrote:
On Wed, Jul 3, 2013 at 12:12 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
While I typically agree that using the latest stable versions of
things is a good thing™, in this case the almighty gods that maintain
jquery have decided to move deprecated APIs from versions prior to 1.9
into a migration plugin. In my opinion they did a major booboo to say
the least, and more accurately they fucked up majorly–YOU DON'T REMOVE
PUBLIC API IN A MINOR RELEASE!
Upgrading to wicket 6.9 breaks all our applications that use any
jquery plugin that was developed in the last decade. I think we should
not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've
caught that though), unless... we forcefully include the jquery
migration plugin [1] as well in 6.9 (also available for jquery 2.x).
We can make it so that the migration plugin is enabled by default for
wicket 6.x applications, and in 7.x by default disabled.
As we are already considering 6.9.1, I think we should fix this issue
as well in 6.9.1.
[ ] Release 6.9.1 with downgrade to jquery 1.8.3
[ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin
[ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery
1.10.1 and migration plugin
[X] Don't fix jquery issues
MyApp#init() {
getJavaScriptLibrarySettings().setJQueryReference(new
JavaScriptResourceReference(...,
anyVersionThatWorksForMeUntilIUpgradeMyAppAndPlugins))
}
WDYT?
Martijn
[1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: JQuery 1.10.1 dependency also breaks many applications
On Wed, Jul 3, 2013 at 12:23 PM, Thomas Matthijs li...@selckin.be wrote:
As we are already considering 6.9.1, I think we should fix this issue
as well in 6.9.1.
[ ] Release 6.9.1 with downgrade to jquery 1.8.3
[ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin
[ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery
1.10.1 and migration plugin
[X] Don't fix jquery issues
MyApp#init() {
getJavaScriptLibrarySettings().setJQueryReference(new
JavaScriptResourceReference(...,
anyVersionThatWorksForMeUntilIUpgradeMyAppAndPlugins))
}
How can the user know what version of jquery API wicket is compatible with?
The best is to run the JS unit
testshttps://github.com/apache/wicket/tree/master/wicket-core/src/test/js
with
the version of jQuery you'd like to use.
I have ran them with 1.7.2, 1.8.2/3, 1.9.1, 1.10.0, 2.0.1
Re: JQuery 1.10.1 dependency also breaks many applications
On Wed, Jul 3, 2013 at 12:25 PM, Sven Meier s...@meiers.net wrote:
MyApp#init() {
getJavaScriptLibrarySettings()**.setJQueryReference(new
JavaScriptResourceReference(..**.,
**anyVersionThatWorksForMeUntilI**UpgradeMyAppAndPlugins))
}
Problem is when you're using libraries which are using
JQueryResourceReference.get() hard coded in #getDependencies() :/.
Time to improve - use the settings.
This is the main reason why DynamicJQueryRR has no static members ...
Sven
On 07/03/2013 11:20 AM, Martin Grigorov wrote:
On Wed, Jul 3, 2013 at 12:12 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
While I typically agree that using the latest stable versions of
things is a good thing™, in this case the almighty gods that maintain
jquery have decided to move deprecated APIs from versions prior to 1.9
into a migration plugin. In my opinion they did a major booboo to say
the least, and more accurately they fucked up majorly–YOU DON'T REMOVE
PUBLIC API IN A MINOR RELEASE!
Upgrading to wicket 6.9 breaks all our applications that use any
jquery plugin that was developed in the last decade. I think we should
not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've
caught that though), unless... we forcefully include the jquery
migration plugin [1] as well in 6.9 (also available for jquery 2.x).
We can make it so that the migration plugin is enabled by default for
wicket 6.x applications, and in 7.x by default disabled.
As we are already considering 6.9.1, I think we should fix this issue
as well in 6.9.1.
[ ] Release 6.9.1 with downgrade to jquery 1.8.3
[ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin
[ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery
1.10.1 and migration plugin
[X] Don't fix jquery issues
MyApp#init() {
getJavaScriptLibrarySettings()**.setJQueryReference(new
JavaScriptResourceReference(..**.,
anyVersionThatWorksForMeUntilI**UpgradeMyAppAndPlugins))
}
WDYT?
Martijn
[1]
http://jquery.com/upgrade-**guide/1.9/#jquery-migrate-**pluginhttp://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: JQuery 1.10.1 dependency also breaks many applications
[X] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery
1.10.1 and migration plugin
We should use the time we have to check if the migration plugin does what
is expected before releasing 6.10.0. 6.9.0 is a bad release for heavy
JavaScript user.
__
Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay)
http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr
On Wed, Jul 3, 2013 at 11:27 AM, Martin Grigorov mgrigo...@apache.orgwrote:
On Wed, Jul 3, 2013 at 12:23 PM, Thomas Matthijs li...@selckin.be wrote:
As we are already considering 6.9.1, I think we should fix this issue
as well in 6.9.1.
[ ] Release 6.9.1 with downgrade to jquery 1.8.3
[ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin
[ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery
1.10.1 and migration plugin
[X] Don't fix jquery issues
MyApp#init() {
getJavaScriptLibrarySettings().setJQueryReference(new
JavaScriptResourceReference(...,
anyVersionThatWorksForMeUntilIUpgradeMyAppAndPlugins))
}
How can the user know what version of jquery API wicket is compatible
with?
The best is to run the JS unit
testshttps://github.com/apache/wicket/tree/master/wicket-core/src/test/js
with
the version of jQuery you'd like to use.
I have ran them with 1.7.2, 1.8.2/3, 1.9.1, 1.10.0, 2.0.1
Thoughts on component ids
Hi Wicket Developers, I have a few thoughts regarding component ids. First, requiring the component to know, at constructor time, the wicket:id of the tag it will be added to makes creating components difficult and clumsy. What do you think about changing this pattern: add(new MyComponent(theIdInMarkup)); to this: add(theIdInMarkup, new MyComponent()); This allows us to separate the construction of the components from the populating of the markup. I can think of one downside, Component#replaceWith() will need some re-working. Second, regarding the request listener urls: Would it be feasible to encode the IRequestListener URLs and form component names using the output markup ids rather than the component ids? This would require all all components to have a output markup id, but would not require all components to actually output the output markup id. Reasoning: the component ids are often much, much longer than the generated output markup id. Also, component ids are like variable names - private and internal to the application. I dont want to expose inner working and terminology in the form of the component id name hierarchy to my customers. I want the freedom to use all sorts of offensive language in my component ids :-) We could change urls like: ?5-1.ILinkListener-body-content-someMenu-menuItems-link-2 to ?5-1.ILinkListener-id1-id4-id6-id23-id30-id89 I assume (without looking at the code) that using the whole path in these urls and form component names is to make finding the target component more efficient. If it is not used to speed up finding the target component, then we could simply set the URL to: ?5-1.ILinkListener-id89 Since the output markup id should always be unique in the page, which the component id is only unique in the parent. What do you think? Thanks, Jesse
Re: JQuery 1.10.1 dependency also breaks many applications
[x ] Release 6.9.1 with downgrade to jquery 1.8.3: and stay stick to 1.8.3 also for future versions of Wicket 6.x While I typically agree that using the latest stable versions of things is a good thing™, in this case the almighty gods that maintain jquery have decided to move deprecated APIs from versions prior to 1.9 into a migration plugin. In my opinion they did a major booboo to say the least, and more accurately they fucked up majorly–YOU DON'T REMOVE PUBLIC API IN A MINOR RELEASE! Upgrading to wicket 6.9 breaks all our applications that use any jquery plugin that was developed in the last decade. I think we should not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've caught that though), unless... we forcefully include the jquery migration plugin [1] as well in 6.9 (also available for jquery 2.x). We can make it so that the migration plugin is enabled by default for wicket 6.x applications, and in 7.x by default disabled. As we are already considering 6.9.1, I think we should fix this issue as well in 6.9.1. [ ] Release 6.9.1 with downgrade to jquery 1.8.3 [ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin [ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery 1.10.1 and migration plugin [ ] Don't fix jquery issues WDYT? Martijn [1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin
AjaxFallbackDefaultDataTable/DataTable design
Hello, I implemented add/edit/remove on AjaxFallbackDefaultDataTable which updates only the affected row. The problem is that for adding a new row I need to call a method on DataGridView, which is not possible for two reasons: it is a protected method, and the datagrid is a private field in DataTable. So the only possibility is to copy paste about 8 classes or use reflection, you can see yourself - http://pastebin.com/QxrfAD6V Wouldn't it be possible to somehow make it more flexible? It would be maybe OK to copy paste AjaxFallbackDefaultDataTable and DataTable, but all the toolbars is not. Thanks, Vojtech
Re: JQuery 1.10.1 dependency also breaks many applications
Ah we are taking here about the removal of the deprecated api not the code for other browsers. That was 2.0 yes. Couldn't look it up that easy on vacation.. But then I guess we need to stick to 1.8.x On 3 Jul 2013 12:05, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Wed, Jul 3, 2013 at 11:47 AM, Johan Compagner jcompag...@gmail.com wrote: Why not just go to the latest 1.9.x? I thought that was .10 but without all the removed api? 1.9 has removed the api. Martijn On 3 Jul 2013 11:13, Martijn Dashorst martijn.dasho...@gmail.com wrote: While I typically agree that using the latest stable versions of things is a good thing™, in this case the almighty gods that maintain jquery have decided to move deprecated APIs from versions prior to 1.9 into a migration plugin. In my opinion they did a major booboo to say the least, and more accurately they fucked up majorly–YOU DON'T REMOVE PUBLIC API IN A MINOR RELEASE! Upgrading to wicket 6.9 breaks all our applications that use any jquery plugin that was developed in the last decade. I think we should not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've caught that though), unless... we forcefully include the jquery migration plugin [1] as well in 6.9 (also available for jquery 2.x). We can make it so that the migration plugin is enabled by default for wicket 6.x applications, and in 7.x by default disabled. As we are already considering 6.9.1, I think we should fix this issue as well in 6.9.1. [ ] Release 6.9.1 with downgrade to jquery 1.8.3 [ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin [ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery 1.10.1 and migration plugin [ ] Don't fix jquery issues WDYT? Martijn [1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Thoughts on component ids
On Wed, Jul 3, 2013 at 11:35 AM, Jesse Long j...@unknown.za.net wrote: First, requiring the component to know, at constructor time, the wicket:id of the tag it will be added to makes creating components difficult and clumsy. What is clumsy about it? What is difficult to creating components currently? What do you think about changing this pattern: add(new MyComponent(theIdInMarkup)); to this: add(theIdInMarkup, new MyComponent()); This allows us to separate the construction of the components from the populating of the markup. What is the benefit of this? What are the upsides? I can think of one downside, Component#replaceWith() will need some re-working. I can think of one other: a minor breakage in a little used part of our API. Martijn
Re: Thoughts on component ids
On 03/07/2013 14:07, Martijn Dashorst wrote:
On Wed, Jul 3, 2013 at 11:35 AM, Jesse Long j...@unknown.za.net wrote:
First, requiring the component to know, at constructor time, the wicket:id
of the tag it will be added to makes creating components difficult and
clumsy.
What is clumsy about it? What is difficult to creating components currently?
I have a base page. It has a div that usually contains some certain
information. Sometimes, in response to form submits etc, this div will
be replaced by something else. I cant do:
this.replaceMySpecialDiv(new MyPanel(Oh damn, what was the component id
here again?));
Also, I practice Only the abc.java may be required to know the
component ids in abc.html. Having subclasses of the base page need to
know the component id is untidy.
it would be better:
this.replaceMySpecialDiv(new MyPanel());
protected void replaceMySpecialDiv(Component c)
{
replace(component id ... I am in BasePage.java, so I am allowed to
know component ids in BasePage.html, c);
}
You end up with public static final String SOMETHING_COMPONENT_ID
which gets passed into component constructors. The next evolution is to
create a needless subclass that does little other than always pass the
same component id to the super class, like:
public class MySpecialDivPanel
extends Panel
{
public MySpecialDivPanel(IModel.)
{
super(hardcoded component id, model);
}
}
Look at wicket-bootstrap.
https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/navbar/NavbarButton.java
super(Navbar.componentId(), ..
Its clumsy.
What do you think about changing this pattern:
add(new MyComponent(theIdInMarkup));
to this:
add(theIdInMarkup, new MyComponent());
This allows us to separate the construction of the components from the
populating of the markup.
What is the benefit of this? What are the upsides?
Upside is less clumsy.
I can think of one downside,
Component#replaceWith() will need some re-working.
I can think of one other: a minor breakage in a little used part of our API.
:-) very important point. However, I'm not pushing this for 6.9.1. I'm
happy to wait for 6.9.2 :-)
No harm in discussing it though. I think its about as disruptive as the
changes proposed in Wicket 2. It need not be black and white, we may be
able to accommodate both approaches. Either way, if the only down side
is API breakage, and generally accepted as a good thing, then maybe we
can implement it one day when something else causes API breakage.
Cheers,
Jesse
wicket pull request: Cdi 1.1 experimental 0.3-SNAPSHOT
GitHub user jsarman opened a pull request: https://github.com/apache/wicket/pull/49 Cdi 1.1 experimental 0.3-SNAPSHOT Major changes to internals. Now supports @Conversational(auto,propagation) annotation to allow pages to override global configuration. Added WicketCdiFilter to allow the Cdi functionality to be set before the apps are loaded. This allows for configuration of global settings in web.xml and for Injection at Application initialization. One can now put @Inject in the WebApplication class and use the variable in the init function or anywhere else. Added several tests for ConversationPropagation use cases. Reintroduced the original Configuration option as deprecated methods to allow easier transition from cdi 1.0 implementation. The Propagation and Auto can be programmatically changed at runtime if the calling code is in a non-transient conversation. Any changes to the global defaults are stored in a ConversationManager which is ConversationScoped. Adding the test helped to weed out many potential problems. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jsarman/wicket cdi-1.1-experimental Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/49.patch
