Re: proposal: behavior bundles
On Thu, Jul 17, 2014 at 9:08 AM, Garret Wilson gar...@globalmentor.com wrote: On 7/17/2014 8:25 AM, Martin Grigorov wrote: ... For some reason this feature doesn't seem that usable to me... Could you be more specific about why you don't find this feature doesn't seem useful? None of your comments below were about the feature itself---they were about ancillary implementation details, such as whether the assert keyword should be used. This feature proposal is based upon the following assumptions: * Many developers will want to use the Wicket framework with third-party frameworks that require certain attributes and/or CSS classes in certain circumstances. * Adding third-party library support shouldn't require subclasses a lot of components. (Otherwise, I'd have a PureCSSButton, and I'd have to instantiate PureCSSButtons throughout the code... until I changed frameworks, at which point I'd have to change them all to BootStrapButtons.) * Third-party library support should be isolated from main UI code and from business logic. That is, I shouldn't have have to go add PureCSSAttributeBehaviors to all my buttons throughout the code, intermingled with my CSS framework-agnostic code. If one of those assumptions are invalid, let me know. Otherwise, do you have an alternative approach for me to easily add Pure CSS support for all my buttons (for example) in one locations without going through all my UI code, and then tomorrow to switch to using the Bootstrap framework (with its different required attributes for buttons and such) without changing all my code? If there is an alternative, great. But I don't see how you can say there is no need for such a feature. there is no need for the wrapper you provide. everything you want is already possible using IComponentInstantiationListener - which you already use. there are a few issues with the convenience wrapper: * you are forcing developers to share the behavior instance across multiple components this may be undesirable in some cases and inconvenient because it forces the behavior design to be stateless or store data using metadata instead of fields. while ok for simple things like appending a class it makes developing more complex behaviors difficult. * the mapping is not flexible enough suppose you want a link that opts out of this behavior for whatever reason. maybe you do it by implementing some interface on the link. now all methods in the behavior have to check for this interface. much easier to check for the interface and just not add the behavior. * the wrapper doesnt provide any real value its just a convenience and one that doesnt work for the 90% case. how many lines of code does it save? not many. we dont add such wrappers because they blow up the api surface area. -igor Garret
Re: [VOTE] Release Apache Wicket 6.16.0
+1 to release -igor On Thu, Jun 12, 2014 at 1:18 AM, Martin Grigorov mgrigo...@apache.org wrote: [X] Yes, release Apache Wicket 6.16.0 tested our main app, random wicket examples, local build Martin Grigorov Wicket Training and Consulting On Tue, Jun 10, 2014 at 3:37 PM, Sven Meier s...@meiers.net wrote: [X] Yes, release Apache Wicket 6.16.0 +1, tested with our main application. Regards Sven On 06/06/2014 03:43 PM, Martijn Dashorst wrote: This is a vote to release Apache Wicket 6.16.0 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.16.0 [ ] No, don't release Apache Wicket 6.16.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.16.0 Staging repository: https://repository.apache.org/content/repositories/ orgapachewicket-1019/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. The signatures for the source release artefacts: apache-wicket-6.16.0.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlORjnoACgkQJBX8W/xy/UXfmgCaAj2rxkyNRwy5bAi6XNJfiOu5 vJ8AoJw+PTYTkpk1hqPdcsKG/6/ZDnWM =DsVi -END PGP SIGNATURE- apache-wicket-6.16.0.zip -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlORjnoACgkQJBX8W/xy/UVNcQCgw4jzblZPiVRzQ1uawDsbYQkI VhsAoMo02KXxRPdKL7I797ql25doUh8r =SFyR -END PGP SIGNATURE- Release Notes - Wicket - Version 6.16.0 ** Bug * [WICKET-4545] - MarkupNotFoundException for Fragment and TransparentWebMarkupContainer * [WICKET-5553] - When using an Ajax request to display initially hidden components inside inline enclosures, only the first one appears. * [WICKET-5560] - A 404 error occurs when using a CryptoMapper * [WICKET-5569] - Unable to find markup for children of deeply nested IComponentResolvers during Ajax response * [WICKET-5570] - Rescheduling the same ajax timer behavior causes memory leak in the browser * [WICKET-5573] - FilterToolbar generics broken * [WICKET-5581] - CachingResourceStreamLocator is not extension-aware * [WICKET-5582] - ServletWebResponse#encodeUrl() makes absolute Urls relative * [WICKET-5589] - Upgrade wicket-atmosphere to the latest version of atmosphere * [WICKET-5591] - Missing translation for HoursValidator.range (in DateTimeField) * [WICKET-5592] - Add a method to clear the cache of CachingResourceStreamLocator * [WICKET-5593] - AjaxFormValidatingBehavior attempts to update non-visible feedback panels * [WICKET-5595] - Atmosphere: updates infinitly with long polling transport * [WICKET-5596] - DropDownChoice#wantsOnSelectionChangedNotifications(T) not being called on unmounted page * [WICKET-5601] - AbstractSingleSelectChoice fails with NullPointerException when its choice renderer returns null from #getIdValue() ** Improvement * [WICKET-5563] - RestartResponseAtInterceptPageException - add public function to retrieve originalUrl * [WICKET-5574] - ComponentRenderer should use Application#createRequestCycle * [WICKET-5575] - Add support in FormTester#submit(String|Component) for Ajax submitters * [WICKET-5577] - Generation of wicket ids with prefix / suffix * [WICKET-5580] - Allow markup to find child fragments when wicket:child is inside a component tag * [WICKET-5585] - Wicket Extension Automplete does not work well with JavaScriptFilteredIntoFooterHeaderResponse * [WICKET-5586] - NextButton isEnabled() should bo logical conjunction of getWizardModel().isNextAvailable() and super.isEnabled() * [WICKET-5600] - Introduce CharSequenceResource similar to ByteArrayResource * [WICKET-5606] - SelectOptions with #setRecreateChoices(true) loses selection on form errors ** Task * [WICKET-5587] - Upgrade JQuery to latest releases - 1.11.1 2.1.1
Re: [VOTE] Release Apache Wicket 6.15.0
+1 to release -igor On Wed, Apr 16, 2014 at 3:56 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.15.0 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.15.0 [ ] No, don't release Apache Wicket 6.15.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.15.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-1014/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. The signatures for the source release artefacts: apache-wicket-6.15.0.tar.gz: -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlNPB8AACgkQJBX8W/xy/UUIlgCgsRqpylFm+JIHsfrTfcQI0YZA XmoAoKZbXv7LfEYmoj/t9wPdr05S5EX1 =Xbxq -END PGP SIGNATURE- apache-wicket-6.15.0.zip: -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlNPB8AACgkQJBX8W/xy/UUmHQCfRAFaprglWYJS0XMHy/H77y1j b1AAn1J7i5a+JFzFf3bXGQoiMShG92V5 =u4er -END PGP SIGNATURE- Release Notes - Wicket - Version 6.15.0 ** Sub-task * [WICKET-5510] - Avoid using jQuery.text() when possible. It is very slow in IE * [WICKET-5554] - Disable second level pages store because it is efficient only when manually configured ** Bug * [WICKET-5243] - JS: High stack size in Function Executor causes too much recursion * [WICKET-5284] - Too deep recursion in AbstractHierarchyIterator * [WICKET-5504] - AjaxRequestTarget.append/prependJavaScript cannot handle scripts with new-lines anymore * [WICKET-5505] - DefaultPropertyResolver does not respect JavaBean conventions * [WICKET-5506] - DefaultPropertyResolver should resolve the Property according to the getter first * [WICKET-5509] - Wicket examples' MailTemplate from Page is broken * [WICKET-5517] - IE11 returns false for Wicket.Browser.isIE() * [WICKET-5518] - FormComponent.updateCollectionModel does not handle unmodifiableList * [WICKET-5521] - Stateless forms does not work when RecreateMountedPagesAfterExpiry turned off * [WICKET-5522] - Failing HTTPS redirect to RequireHttps annotated pages with ONE_PASS_RENDER strategy * [WICKET-5523] - Ajax indicator not working when display is set to none in css * [WICKET-5532] - NPE calling PackageResource.getResourceStream() if there is no RequestCycle defined * [WICKET-5534] - DataTable component must throw an exception when attached to non-table element * [WICKET-5536] - Error message without parmeters filled. * [WICKET-5537] - Wicket.DOM.toggleClass is called with additional # inside AutoLabelResolver * [WICKET-5541] - NullPointerException in SubscribeAnnotationEventSubscriptionInvoker on remove of component from page * [WICKET-5545] - Cannot use redirect in ModalWindow's page#onInitialize() * [WICKET-5546] - Adding behavior in component instantiation listener causes Page.onInitialize() being called even if constructor throws an exception * [WICKET-5547] - Javadoc for ReuseIfModelsEqualStrategy should mention that models must implement hashCode() method * [WICKET-5548] - Websocket initialization URL is not valid when filter is not mapped to root. ** Improvement * [WICKET-5508] - Memory model improvements for Session fields * [WICKET-5512] - Allow using child selector for JS event bindings * [WICKET-5520] - improve reusability of DataTable and AbstractPageableView * [WICKET-5528] - Allow models of subtypes of Select type parameter in SelectOption constructor * [WICKET-5529] - Add WebSocketBehavior/Resource#onPush() callback method * [WICKET-5531] - Create new placeholder tag to indicate where header contributions should appear * [WICKET-5538] - When using Component.setDefaultModel, only detach the previous model if the new one is different * [WICKET-5549] - continueToOriginalDestination() fails after redirectToInterceptPage() on AjaxRequest ** New Feature * [WICKET-831] - Return response status 404 when a mapper cannot decode a request url * [WICKET-2542] - Provide ajax buttons for wizard ** Task * [WICKET-5514] - Update Wicket fragment example ** Wish * [WICKET-5516] - RadioChoice / add a getAdditionalAttributes() also for label-tag *
Re: [VOTE] Release Apache Wicket 7.0.0-M1
+1 to release -igor On Sun, Apr 20, 2014 at 1:44 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: WOW. This is the first of many votes to come for our first Wicket 7 release train. It took some work, but I managed to manipulate our projects, Maven and its release plugin to generate the right release version numbers for the right projects. Known issue: Wicket Atmosphere version mismatch between wicket 6 and 7 It appears that wicket-experimental/wicket-atmosphere has version 0.10 if we release 7.0.0-M1 **right now**. Now I don't have a clear view if atmosphere in master is up to date with 0.18 from Wicket 6.15. I think it ultimately doesn't **yet**. If 7.x/atmosphere:0.10 is on the same patch level as 6.x/atmosphere/0.10, then we have parity in versions. If 7.x/atmosphere:0.10 is on the same patch level as 6.x/atmosphere/0.18, we can fix the numbering scheme in 7.0.0-M2 So here it goes: This is a vote to release Apache Wicket 7.0.0-M1 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 7.0.0-M1 [ ] No, don't release Apache Wicket 7.0.0-M1, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/7.0.0-M1 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-1018 The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Release notes: - Wicket 7 requires Java 7 at a minimum - Wicket 7 requires at least a servlet 3 compatible container - Migration guide: http://s.apache.org/wicket7migrate The signatures for the source release artefacts: apache-wicket-7.0.0-M1.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlNUK4wACgkQJBX8W/xy/UXKbgCdHzMcgjCtDXTJsLLUwHEGNWUJ ZwwAoNCbquGqNMzYY9tMi+lflzH4MqcP =x14q -END PGP SIGNATURE- apache-wicket-7.0.0-M1.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlNUK4wACgkQJBX8W/xy/UXUfQCg1EU8S+Z5mdy7svWlK1WwMAG3 tWwAoJr6egOay7UNi8HCH2cOBZekOO0j =AVEj -END PGP SIGNATURE-
Re: Wicket 7: IChoiceRenderer restore or keep out?
On Wed, Mar 19, 2014 at 2:58 AM, Sven Meier s...@meiers.net wrote: Hi Martin, I'm +1 on releasing 7.x soon. ListMultipleChoice#getModelValue() and AbstractSingleSelectChoice#getModelValue() are still problematic though: Both call getChoices().indexOf(object), thus any non-primitive option has to implement #equals() :(. so thats where the code should be fixed, instead of unrolling changes that make perfect sense... the choice renderer can do this conversion, since it is also the place that does the complementary conversion already. the reliance on the index is a stupid one imho. in real world there is very rarely a usecase where a List is stable across requests. we should remove the usage of index altogether from these components. for usecases where the index is actually usable the renderer can use it since it has access to it since it has access to the list model. How about leaving IChoiceRenderer to do the actual rendering part (i.e. #getDisplayValue()) only ? The conversion choice-id (i.e. #getIdValue() and #getObject()) could be moved into a converter instead. this is not really a usecase for converters. they are meant to convert request values to objects. the problem is the choice renderer is already doing half of this conversion in getIdValue(), so it does not make sense to me to use the renderer for one half of the conversion and converter for the other half. this needs to be made consistent, either move all of it into renderer or move all of it into converter. the renderer seemed a more logical place to me for this particular component. @Igor? Regards Sven On 03/19/2014 10:27 AM, Martin Grigorov wrote: Sven, Igor, Do you have an agreement how IChoiceRenderer should look like in Wicket 7.x ? I really like to release 7.0.0-M1 so we got some user feedback. Martin Grigorov Wicket Training and Consulting On Wed, Feb 26, 2014 at 8:10 PM, tetsuo ronald.tet...@gmail.com wrote: Sorry for the rant... The transition from 1.4 to 1.5 was awful (full of such minor breaking changes), but not so afterwards, I know I'm overreacting. Probably it's because it happened (a colleague complaining about all the compiling errors when upgrading from 1.4) last week :/ And well... it's somewhat inevitable to avoid compiling errors when evolving a framework that is strongly type-safe (which is a great plus). Sorry again. But I still like my enums, please keep the interfaces :) On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov mgrigo...@apache.org wrote: On Wed, Feb 26, 2014 at 6:21 PM, tetsuo ronald.tet...@gmail.com wrote: Guillaume, you're right. Martin, sorry for the misunderstanding. Enums can't extend any classes besides Enum. But can implement interfaces. Thanks! Now it is clear to me. I use Enums in lots of places, not as enums, but as singletons, because they won't be serialized, won't carry unintended references, and use virtually no memory in pages. Converters, Renderers, Validators, Models (less so of the former, since it almost always needs state). If IBehavior still existed, and didn't have so many methods, I'd use enums to implement some of them, too. But my main complaint is not specific to this issue, however. I'm more concerned about frequent breaking API changes with no practical advantage. Javascript/JavaScript, addComponent/add(Component) and the like. I'm at the point that I'm starting to feel unconfortable recommending Wicket to people, because I know an year from now they will complain that they upgraded a library and a thousand compiling errors appeared. 98% of them are very simple errors, but it's a daunting task neverthless. Options: 1) Wicket devs stop developing Wicket so the API stays stable forever 2) application developers don't upgrade to next major version of Wicket 3) find the golden middle. I think we all agree that 3) is the best for all and that we (Wicket devs) try to follow it: - we use SemVer to make it easier for application developers to know when to expect API breaks and when to not expect such - we discuss most of the API breaks for major versions here in dev@. If there are issues identified on time we react! Even this change has been discussed before being made On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov mgrigo...@apache.org wrote: As Martijn explained all that is needed is: - s/implements/extends/ - remove the leading 'I' from IChoiceRenderer If the interface is preserved then all custom impls will have to add implementation of the new method introduced with WICKET-663. This IMO will lead to more work for the application developers. As I said: I am not against restoring the interface, just don't see its value. Martin Grigorov Wicket Training and Consulting On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet guillaume.s...@gmail.com wrote: On Wed, Feb 26, 2014 at 4:33 PM, tetsuo ronald.tet...@gmail.com wrote:
Re: Future of org.apache.wicket.util.iterator.ComponentHierarchyIterator
i think the visitors are a simpler solution. -igor On Mon, Mar 17, 2014 at 3:09 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Juergen has introduced component hierarchy iterators with https://issues.apache.org/jira/browse/WICKET-3789 to simplify the hierarchy traversal via IVisitor. Unfortunately AbstractHierarchyIterator has a bug that doesn't allow its usage in a page with many components - it uses a recursion [1]. AbstractHierarchyIterator#hasNext() uses #moveDown() and vice versa. At the moment org.apache.wicket.MarkupContainer#visitChildren() and org.apache.wicket.MarkupContainer#visitChildren(java.lang.Class?) use ComponentHierarchyIterator so they may not work for complex pages. Should we deprecate the iterators and remove their usage in Wicket codebase now and the classes themselves in Wicket 8 ? Or someone wants to improve the way the component iterators work and fix the problem ? 1. https://issues.apache.org/jira/browse/WICKET-5284. Martin Grigorov Wicket Training and Consulting
Re: Wicket 7: IChoiceRenderer restore or keep out?
On Wed, Feb 26, 2014 at 8:00 AM, Sven Meier s...@meiers.net wrote:
To add another point to the discussion:
IMHO (I)ChoiceRenderer in 7.x is broken anyway.
As long as the user has to implement #equals() in his model objects *or*
override #getModelValue(), the choice renderer API is not yet complete:
@Override
public String getModelValue()
{
final T object = getModelObject();
if (object != null)
{
// #indexOf() might be inefficient or fail depending on the
#equals() implementation
int index = getChoices().indexOf(object);
return getChoiceRenderer().getIdValue(object, index);
}
else
{
return ;
}
}
i am going to guess this doesnt often break because 99% of
implementations out there do not use the index parameter. personally i
think it should be removed from choice renderer, leave it to the user
to map. we can pass the entire collection of choices into methods on
choice renderer instead of passing in an index.
I wonder whether (I)ChoiceRenderer is taking the wrong direction: It's meant
to control the rendering of choices (hence its name).
Everything else could be made (or already is) adjustable via protected
methods in the choice component.
it has never been just the renderer because from the beginning it is
what maps objects to their ids, it only makes sense that it takes care
of the inverse mapping. mapping objects to ids is usually a function
of the data-store, so why have half of data-store specific code in
choice renderer, and half in the component hierarchy?
-igor
Regards
Sven
On 02/26/2014 04:44 PM, Martin Grigorov wrote:
As Martijn explained all that is needed is:
- s/implements/extends/
- remove the leading 'I' from IChoiceRenderer
If the interface is preserved then all custom impls will have to add
implementation of the new method introduced with WICKET-663. This IMO will
lead to more work for the application developers.
As I said: I am not against restoring the interface, just don't see its
value.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet
guillaume.s...@gmail.comwrote:
On Wed, Feb 26, 2014 at 4:33 PM, tetsuo ronald.tet...@gmail.com wrote:
Because... it's an unnecessary breaking change?
From what I understand of your previous post, you implements some of
your converters in Enums, which you can do because IChoiceRenderer is
currently an interface. And you won't be able to do it if it's a
class.
Am I right?
Re: [1/2] git commit: WICKET-3335 fragment and wicket:container support
no, its not. will fix...thanks for catching
-igor
On Tue, Feb 25, 2014 at 3:56 AM, Martin Grigorov mgrigo...@apache.org wrote:
On Mon, Feb 24, 2014 at 9:09 PM, ivaynb...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/master a79ed51e9 - cc5d56a50
WICKET-3335 fragment and wicket:container support
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/61b01295
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/61b01295
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/61b01295
Branch: refs/heads/master
Commit: 61b01295d0d52929178d058d48456cae4acbc3e7
Parents: a79ed51
Author: Igor Vaynberg igor.vaynb...@gmail.com
Authored: Mon Feb 24 11:09:12 2014 -0800
Committer: Igor Vaynberg igor.vaynb...@gmail.com
Committed: Mon Feb 24 11:09:12 2014 -0800
--
.../java/org/apache/wicket/MarkupContainer.java | 4 ++
.../wicket/markup/html/panel/Fragment.java | 10 +++-
.../wicket/queueing/ComponentQueueingTest.java | 53
3 files changed, 56 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/61b01295/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
index 087d655..1aba865 100644
--- a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
+++ b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
@@ -2169,6 +2169,10 @@ public abstract class MarkupContainer extends
Component implements IterableComp
if (tag instanceof WicketTag)
{
WicketTag wicketTag = (WicketTag)tag;
+ if (wicketTag.isContainerTag())
+ {
+ return true;
+ }
if (wicketTag.getAutoComponentFactory() != null)
{
return true;
http://git-wip-us.apache.org/repos/asf/wicket/blob/61b01295/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
b/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
index 078aa44..676cca5 100644
---
a/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
+++
b/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
@@ -17,8 +17,12 @@
package org.apache.wicket.markup.html.panel;
import org.apache.wicket.Component;
+import org.apache.wicket.IQueueRegion;
import org.apache.wicket.MarkupContainer;
import org.apache.wicket.markup.IMarkupFragment;
+import org.apache.wicket.markup.MarkupElement;
+import org.apache.wicket.markup.MarkupFragment;
+import org.apache.wicket.markup.WicketTag;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.model.IModel;
import org.apache.wicket.util.lang.Args;
@@ -46,7 +50,7 @@ import org.apache.wicket.util.lang.Args;
*
* @author Juergen Donnerstag
*/
-public class Fragment extends WebMarkupContainer
+public class Fragment extends WebMarkupContainer implements IQueueRegion
{
private static final long serialVersionUID = 1L;
@@ -130,4 +134,8 @@ public class Fragment extends WebMarkupContainer
return associatedMarkupId;
}
+ @Override
+ public IMarkupFragment getDequeueMarkup() {
+ return newMarkupSourcingStrategy().getMarkup(this, null);
Is it important to use newMarkupSourcingStrategy() here ?
Can we use org.apache.wicket.Component#getMarkupSourcingStrategy() ?
+ }
}
http://git-wip-us.apache.org/repos/asf/wicket/blob/61b01295/wicket-core/src/test/java/org/apache/wicket/queueing/ComponentQueueingTest.java
--
diff --git
a/wicket-core/src/test/java/org/apache/wicket/queueing/ComponentQueueingTest.java
b/wicket-core/src/test/java/org/apache/wicket/queueing/ComponentQueueingTest.java
index 34f1317..96f0c77 100644
---
a/wicket-core/src/test/java/org/apache/wicket/queueing/ComponentQueueingTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/queueing/ComponentQueueingTest.java
@@ -33,6 +33,7 @@ import org.apache.wicket.markup.html.internal.Enclosure;
import org.apache.wicket.markup.html.link.Link;
import org.apache.wicket.markup.html.list.ListItem;
import org.apache.wicket.markup.html.list.ListView
Re: Markup driven component tree
tests fixed, merged into master. -igor On Tue, Feb 18, 2014 at 5:29 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 17, 2014 at 5:48 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: i think the implementation is good enough to be merged into master now. it supports: I am still not able to fix the tests I will need more time to get acquaint with the new code to be able to maintain it * dequeuing algorithm that delegates to components so subclasses can override (this is how repeaters and borders support it) * support for all major constructs: panels, borders, repeaters * support for auto component hierarchy - they are dequeued and queued up children are placed as the children of auto components - this makes things like enclosures trivial to implement where as before they were fairy complex * performance comparable to adding, still some room for improvement with clever/efficient data structures maybe, but i dont think its needed... I see regression here last time I ran the performance test it needed 9s to run and used 88Mb memory now the time is 11s and the memory is 201Mb todo: * fragments - should be trivial, possibly as trivial as letting it implement IQueueRegion * check markup inheritance works on pages, panels, fragments. * examples * update to the guide -igor On Fri, Feb 14, 2014 at 8:36 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i am reworking the implementation a bit to properly support borders and repeaters by delegating to components...will check it in when i have it working... -igor On Fri, Feb 14, 2014 at 7:26 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 10, 2014 at 6:01 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Mon, Feb 10, 2014 at 6:26 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 10, 2014 at 9:43 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just pushed my new idea into sandbox/component-queueing-2 the way this works now is instead of doing it in onInitialize() and in onConfigure() and all the other places dequeuing now works progressively. upon a change (container.queue() or component.add()) a dequeue will be tried. it even works well with resolved components like enclosures. for such components the markup of page/panel is traversed in onInitialize() and all auto components are placed into the queue. later as components are added/queued these components will be placed into the correct place in the hierarchy. if queue() is used children of these components will be placed under them in correct hierarchy place. this is a big win for using queueing over adding. repeaters also work. the repeater items themselves have to be added to the repeater, but item's children can be queued. this is not a problem since items are mostly added by framework classes. Borders do not yet work mainly because i havent tried to make them work. the tricky part there is to keep the border and BorderBody queues separate. I've added some code to support it but it needs more work. See my response to the commit notification email of my changes. Basic usage of Border is now supported. I have added a test with nested Borders and it fails. Please check org.apache.wicket.queueing.ComponentQueueingTest#dequeueWithNestedBorders Also we have BorderBehavior and BorderPanel. I think (almost) no one uses those but they exist. imho we can nuke these two things from 7. they dont look very useful. probably added just because we could. InlineEnclosures do not yet work because the code for figuring out the value of the child attribute is really convoluted for the simple thing its supposed to do and i didnt bother parsing it. Should be very similar to how EnclosureHandler works. Done. thanks. the performance is good. there is ComponentQueueingPerformanceTest with a disabled test. give it a go and let me know the results. on my box queuing had under 10% overhead, which is acceptable. I also have some ideas on how to optimize that further by trading cpu for a bit more memory, but not sure In my branch on this topic I used HashMap instead of array. The lookup is faster. Not sure how much memory overhead there is. yeah. havent had time to profile it yet. there are some memory efficient hashmaps floating around, maybe we can adapt one of them. I've added ComponentQueue2 based on HashMap with the same initial capacity (8) and loadFactor 1. wicket-util has MicroMap for 1entry and MiniMap for fixed size entries but it doesn't use hash function so it iterates over the entries as we do over the array in ComponentQueue(1). With ComponentQueue2 the map will start with capacity 8 and will double when the ninth is to be added
Re: git commit: WICKET-3335 test fixes
On Fri, Feb 21, 2014 at 5:09 AM, Martin Grigorov mgrigo...@apache.org wrote:
On Fri, Feb 21, 2014 at 9:18 AM, ivaynb...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/sandbox/component-queueing-2 63d15c5c3 - 1fd9d57c0
WICKET-3335 test fixes
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/1fd9d57c
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/1fd9d57c
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/1fd9d57c
Branch: refs/heads/sandbox/component-queueing-2
Commit: 1fd9d57c0954f393e7cf6b6391d2f69c2815674d
Parents: 63d15c5
Author: Igor Vaynberg igor.vaynb...@gmail.com
Authored: Thu Feb 20 23:09:43 2014 -0800
Committer: Igor Vaynberg igor.vaynb...@gmail.com
Committed: Thu Feb 20 23:18:25 2014 -0800
--
.../java/org/apache/wicket/DequeueContext.java | 44 +-
.../java/org/apache/wicket/MarkupContainer.java | 48
.../wicket/markup/html/border/Border.java | 12 +++--
.../markup/repeater/AbstractRepeater.java | 4 +-
.../markupFragments/MarkupFragmentTest.java | 2 +
5 files changed, 85 insertions(+), 25 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/1fd9d57c/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
b/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
index 99c102d..a5bb925 100644
--- a/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
+++ b/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
@@ -1,9 +1,26 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version
2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
package org.apache.wicket;
import org.apache.wicket.markup.ComponentTag;
import org.apache.wicket.markup.IMarkupFragment;
import org.apache.wicket.markup.MarkupElement;
import org.apache.wicket.util.collections.ArrayListStack;
+import org.apache.wicket.util.lang.Args;
/**
* Context for component dequeueing. Keeps track of markup position and
container stack.
@@ -71,7 +88,7 @@ public final class DequeueContext
}
/**
-* Peeks markup tag that would be retrieved by call to {@link
#popTag()}
+* Peeks markup tag that would be retrieved by call to {@link
#takeTag()}
*
* @return
*/
@@ -85,27 +102,30 @@ public final class DequeueContext
*
* @return
*/
- public ComponentTag popTag()
+ public ComponentTag takeTag()
{
- ComponentTag taken = next;
- tags.push(taken);
- next = nextTag();
+ ComponentTag taken=next;
+ if (taken.isOpen() !taken.hasNoCloseTag())
+ {
+ tags.push(taken);
+ }
+ else if (tags.size() 0 taken.closes(tags.peek()))
+ {
+ tags.pop();
+ }
+ next=nextTag();
return taken;
}
/**
-* Skips to the closing tag of the tag retrieved from last call to
{@link #popTag()}
+* Skips to the closing tag of the tag retrieved from last call to
{@link #takeTag()}
*/
public void skipToCloseTag()
{
- if (tags.peek().isOpen())
- {
while (!next.closes(tags.peek()))
{
next = nextTag();
}
- tags.pop();
- }
}
private ComponentTag nextTag()
@@ -117,7 +137,7 @@ public final class DequeueContext
{
ComponentTag tag = (ComponentTag)element;
ComponentTag open = tag.isClose() ?
tag.getOpenTag() : tag
Re: [2/2] git commit: WICKET-3335 nested borders working. everything should be working. needs more cleanup and javadoc
On Tue, Feb 18, 2014 at 4:53 AM, Martin Grigorov mgrigo...@apache.org wrote:
On Sat, Feb 15, 2014 at 9:40 AM, ivaynb...@apache.org wrote:
WICKET-3335 nested borders working. everything should be working. needs
more cleanup and javadoc
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/384d748c
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/384d748c
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/384d748c
Branch: refs/heads/sandbox/component-queueing-2
Commit: 384d748c150031fa584aa44fce2f0a7e05e98531
Parents: 14797ed
Author: Igor Vaynberg igor.vaynb...@gmail.com
Authored: Sat Feb 15 00:40:48 2014 -0800
Committer: Igor Vaynberg igor.vaynb...@gmail.com
Committed: Sat Feb 15 00:40:48 2014 -0800
--
.../java/org/apache/wicket/DequeueContext.java | 5 +-
.../java/org/apache/wicket/MarkupContainer.java | 11 +-
.../wicket/markup/html/border/Border.java | 102 ++-
.../wicket/queueing/ComponentQueueingTest.java | 24 ++---
.../org/apache/wicket/queueing/HasPath.java | 7 +-
.../queueing/nestedborders/OuterBorder.html | 2 +-
6 files changed, 128 insertions(+), 23 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/384d748c/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
b/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
index 8324161..4e62c3e 100644
--- a/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
+++ b/wicket-core/src/main/java/org/apache/wicket/DequeueContext.java
@@ -1,13 +1,14 @@
package org.apache.wicket;
import org.apache.wicket.markup.ComponentTag;
+import org.apache.wicket.markup.IMarkupFragment;
import org.apache.wicket.markup.Markup;
import org.apache.wicket.markup.MarkupElement;
import org.apache.wicket.util.collections.ArrayListStack;
public class DequeueContext
{
- private final Markup markup;
+ private final IMarkupFragment markup;
private int index;
private ComponentTag next;
private ArrayListStackComponentTag tags = new
ArrayListStack();
@@ -37,7 +38,7 @@ public class DequeueContext
}
}
- public DequeueContext(Markup markup, MarkupContainer root)
+ public DequeueContext(IMarkupFragment markup, MarkupContainer
root)
{
this.markup = markup;
containers.push(root);
http://git-wip-us.apache.org/repos/asf/wicket/blob/384d748c/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
index 72f7cc9..e213f35 100644
--- a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
+++ b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
@@ -2080,7 +2080,7 @@ public abstract class MarkupContainer extends
Component implements IterableComp
private void internalDequeue()
{
- Markup markup = getAssociatedMarkup();
+ IMarkupFragment markup = getDequeueMarkup();
if (markup == null)
{
// markup not found, skip dequeuing
@@ -2121,7 +2121,7 @@ public abstract class MarkupContainer extends
Component implements IterableComp
if (child != null)
{
- add(child);
+ addDequeuedComponent(child, tag);
if (child instanceof IQueueRegion)
{
((MarkupContainer)child).dequeue();
@@ -2159,6 +2159,11 @@ public abstract class MarkupContainer extends
Component implements IterableComp
}
}
+
+ protected IMarkupFragment getDequeueMarkup() {
+ return getAssociatedMarkup();
+ }
+
protected boolean supportsDequeueingFrom(ComponentTag tag) {
if (tag instanceof WicketTag) {
WicketTag wicketTag=(WicketTag)tag;
@@ -2172,7 +2177,7 @@ public abstract class MarkupContainer extends
Component implements IterableComp
return true;
}
- protected Component findComponentToDequeue(ComponentTag tag)
+ public Component findComponentToDequeue(ComponentTag tag)
{
return queue == null ? null : queue.remove(tag.getId());
}
http://git-wip
Re: Markup driven component tree
i think the implementation is good enough to be merged into master now. it supports: * dequeuing algorithm that delegates to components so subclasses can override (this is how repeaters and borders support it) * support for all major constructs: panels, borders, repeaters * support for auto component hierarchy - they are dequeued and queued up children are placed as the children of auto components - this makes things like enclosures trivial to implement where as before they were fairy complex * performance comparable to adding, still some room for improvement with clever/efficient data structures maybe, but i dont think its needed... todo: * fragments - should be trivial, possibly as trivial as letting it implement IQueueRegion * check markup inheritance works on pages, panels, fragments. * examples * update to the guide -igor On Fri, Feb 14, 2014 at 8:36 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i am reworking the implementation a bit to properly support borders and repeaters by delegating to components...will check it in when i have it working... -igor On Fri, Feb 14, 2014 at 7:26 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 10, 2014 at 6:01 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: On Mon, Feb 10, 2014 at 6:26 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 10, 2014 at 9:43 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just pushed my new idea into sandbox/component-queueing-2 the way this works now is instead of doing it in onInitialize() and in onConfigure() and all the other places dequeuing now works progressively. upon a change (container.queue() or component.add()) a dequeue will be tried. it even works well with resolved components like enclosures. for such components the markup of page/panel is traversed in onInitialize() and all auto components are placed into the queue. later as components are added/queued these components will be placed into the correct place in the hierarchy. if queue() is used children of these components will be placed under them in correct hierarchy place. this is a big win for using queueing over adding. repeaters also work. the repeater items themselves have to be added to the repeater, but item's children can be queued. this is not a problem since items are mostly added by framework classes. Borders do not yet work mainly because i havent tried to make them work. the tricky part there is to keep the border and BorderBody queues separate. I've added some code to support it but it needs more work. See my response to the commit notification email of my changes. Basic usage of Border is now supported. I have added a test with nested Borders and it fails. Please check org.apache.wicket.queueing.ComponentQueueingTest#dequeueWithNestedBorders Also we have BorderBehavior and BorderPanel. I think (almost) no one uses those but they exist. imho we can nuke these two things from 7. they dont look very useful. probably added just because we could. InlineEnclosures do not yet work because the code for figuring out the value of the child attribute is really convoluted for the simple thing its supposed to do and i didnt bother parsing it. Should be very similar to how EnclosureHandler works. Done. thanks. the performance is good. there is ComponentQueueingPerformanceTest with a disabled test. give it a go and let me know the results. on my box queuing had under 10% overhead, which is acceptable. I also have some ideas on how to optimize that further by trading cpu for a bit more memory, but not sure In my branch on this topic I used HashMap instead of array. The lookup is faster. Not sure how much memory overhead there is. yeah. havent had time to profile it yet. there are some memory efficient hashmaps floating around, maybe we can adapt one of them. I've added ComponentQueue2 based on HashMap with the same initial capacity (8) and loadFactor 1. wicket-util has MicroMap for 1entry and MiniMap for fixed size entries but it doesn't use hash function so it iterates over the entries as we do over the array in ComponentQueue(1). With ComponentQueue2 the map will start with capacity 8 and will double when the ninth is to be added, as in ComponentQueue. But it won't shrink until it becomes with size 0. org.apache.wicket.queueing.ComponentQueueingPerformanceTest gives almost the same results for both impls here: add duration: ~2500 queue duration: ~2400 memory wise Intellij IDEA reports: - with ComponentQueue: max memory 88Mb - with ComponentQueue2: max memory 154Mb so ComponentQueue is a winner here. I've added ComponentQueue2 just in case someone wants to try to optimize it -igor if its needed since the overhead is low and because its only present when queuing is used. also the measurements are not too accurate because most
Re: Markup driven component tree
i am reworking the implementation a bit to properly support borders and repeaters by delegating to components...will check it in when i have it working... -igor On Fri, Feb 14, 2014 at 7:26 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 10, 2014 at 6:01 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: On Mon, Feb 10, 2014 at 6:26 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 10, 2014 at 9:43 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i just pushed my new idea into sandbox/component-queueing-2 the way this works now is instead of doing it in onInitialize() and in onConfigure() and all the other places dequeuing now works progressively. upon a change (container.queue() or component.add()) a dequeue will be tried. it even works well with resolved components like enclosures. for such components the markup of page/panel is traversed in onInitialize() and all auto components are placed into the queue. later as components are added/queued these components will be placed into the correct place in the hierarchy. if queue() is used children of these components will be placed under them in correct hierarchy place. this is a big win for using queueing over adding. repeaters also work. the repeater items themselves have to be added to the repeater, but item's children can be queued. this is not a problem since items are mostly added by framework classes. Borders do not yet work mainly because i havent tried to make them work. the tricky part there is to keep the border and BorderBody queues separate. I've added some code to support it but it needs more work. See my response to the commit notification email of my changes. Basic usage of Border is now supported. I have added a test with nested Borders and it fails. Please check org.apache.wicket.queueing.ComponentQueueingTest#dequeueWithNestedBorders Also we have BorderBehavior and BorderPanel. I think (almost) no one uses those but they exist. imho we can nuke these two things from 7. they dont look very useful. probably added just because we could. InlineEnclosures do not yet work because the code for figuring out the value of the child attribute is really convoluted for the simple thing its supposed to do and i didnt bother parsing it. Should be very similar to how EnclosureHandler works. Done. thanks. the performance is good. there is ComponentQueueingPerformanceTest with a disabled test. give it a go and let me know the results. on my box queuing had under 10% overhead, which is acceptable. I also have some ideas on how to optimize that further by trading cpu for a bit more memory, but not sure In my branch on this topic I used HashMap instead of array. The lookup is faster. Not sure how much memory overhead there is. yeah. havent had time to profile it yet. there are some memory efficient hashmaps floating around, maybe we can adapt one of them. I've added ComponentQueue2 based on HashMap with the same initial capacity (8) and loadFactor 1. wicket-util has MicroMap for 1entry and MiniMap for fixed size entries but it doesn't use hash function so it iterates over the entries as we do over the array in ComponentQueue(1). With ComponentQueue2 the map will start with capacity 8 and will double when the ninth is to be added, as in ComponentQueue. But it won't shrink until it becomes with size 0. org.apache.wicket.queueing.ComponentQueueingPerformanceTest gives almost the same results for both impls here: add duration: ~2500 queue duration: ~2400 memory wise Intellij IDEA reports: - with ComponentQueue: max memory 88Mb - with ComponentQueue2: max memory 154Mb so ComponentQueue is a winner here. I've added ComponentQueue2 just in case someone wants to try to optimize it -igor if its needed since the overhead is low and because its only present when queuing is used. also the measurements are not too accurate because most of the time is spent initializing and tearing down a WicketTester instance. memory overhead is also low, two slots (one of which can/should be converted to a flag) are added to MarkupContainer. see ComponentQueuing test for some examples. i would appreciate some help getting Border and InlineEnclosure working if someone has time. look over this and lets discuss if/when we should merge it into master. -igor
Re: [VOTE] Release Apache Wicket 6.14.0 - second try
+1 -igor On Fri, Feb 14, 2014 at 7:45 AM, Jonas barney...@gmail.com wrote: [X] Yes, release Apache Wicket 6.14.0 (try 2) (non binding) Tested our main webapp, plus verified the jira tracks I've filed (WICKET-5469, WICKET-5493) cheers, Jonas On Fri, Feb 14, 2014 at 4:01 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.14.0 - try 2 This updated release includes a true fix for 5499, and a better error log in wicket-ajax.js when binding fails, and a minor improvement for some javadoc. Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.14.0 [ ] No, don't release Apache Wicket 6.14.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.14.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-1005/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. The signatures for the source release artefacts: apache-wicket-6.14.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlL+LS0ACgkQJBX8W/xy/UX/8ACgvodMozusdl4w0mZKl0DXjq0W +7wAoJ7tamy1sGeP6b5DSNrUVUq5pkp9 =BXJk -END PGP SIGNATURE- apache-wicket-6.14.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEABECAAYFAlL+LSwACgkQJBX8W/xy/UUDiACgjhnZzVRFf7rgKpP0XFmO3KAM /MsAnj5qOjKYrVoM15VLMngXF7ONM4AS =8NdL -END PGP SIGNATURE- Release Notes - Wicket - Version 6.14.0 ** Bug * [WICKET-4697] - Autolinking not working as soon as component gets a wicket:id * [WICKET-5043] - Page not mounted with WebApplication#mountPackage * [WICKET-5449] - Missing chapter 2 is causing off-by-one page names in the guides URL links * [WICKET-5460] - onBeforeRender called too early on stateless page * [WICKET-5462] - Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton * [WICKET-5464] - AbstractAjaxTimerBehavior does not work in combination with Wizards * [WICKET-5466] - ListenerInterfaceRequestHandler#respond throws ComponentNotFoundException as a side-effect * [WICKET-5467] - NumberTextField should support any as valid step attribute value * [WICKET-5468] - UrlRenderer#renderRelativeUrl potentially appends / after query parameters * [WICKET-5469] - ModalWindow unload warning always displayed (even if window is closed) * [WICKET-5472] - PackageResource#internalGetResourceStream() should return ProcessingResourceStream only when the resource is existing * [WICKET-5473] - Wicket does not handle non in-memory Httpsessions correctly * [WICKET-5477] - CSS class is not applied to TD for data filter * [WICKET-5478] - Wrong JavaDoc for WicketTester * [WICKET-5480] - AutoLabelResolver creates null pointer exception in 6.13 * [WICKET-5482] - Wicket-guice doesn't support @javax.inject.Named annotations * [WICKET-5484] - WebPageRenderer must not render full page in Ajax requests * [WICKET-5486] - WebPageRenderer should honor RedirectPolicy.ALWAYS_REDIRECT more consistently * [WICKET-5491] - Wicket.DateTime.getViewportHeight() returning undefined on IE8, positions calendar out of viewport * [WICKET-5492] - WebApplication ignores a SecurityException when reading the configuration type * [WICKET-5496] - Wrong translation of RangeValidator.minimum and RangeValidator.maximum * [WICKET-5497] - NPE in JsonUtils when the value is null * [WICKET-5499] - Page is not touched during initialization * [WICKET-5500] - Ignore the path parameters when reading the page class * [WICKET-5502] - Patch FileUploadBase to fix CVE-2014-0050 ** Improvement * [WICKET-5288] - Allow script-Tags act as WebMarkUpContainer to add Child-Components * [WICKET-5439] - Allow restarting
Re: Markup driven component tree
in the MarkupContainer#children data structure. So each field will add extra 8 bytes on 64bit machine (or 4 bytes with CompressedOops enabled). Serialization is the same - the object is written once, with several pointers. I am also not fully sure in the approach but I am experimenting and so far it works well. And it is configurable, by default disabled. We can advertise it as experimental ?! I will add more use cases/tests soon. And caching for the reflection stuff. On Thu, Jan 23, 2014 at 6:09 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: what about components added in onInitialize() or on onConfigure()? this will also lead to a higher memory/serialization space usage since by default you need a field to store the component ref. not sure its worth doing it this way... -igor On Wed, Jan 22, 2014 at 12:12 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Recently Fridolin Jackstadt shared his approach to autowire components - https://github.com/wicket-acc/wicket-autowire. I believe this approach can solve two issues: - duplicate construction of the component tree - once in the markup and second time in Java code - auto components available only in the render phase Here is how I see it: Any MarkupContainer that wants to use markup-driven-tree must declare the components as member fields: private SomeComponent aComponent; These fields will be instantiated like any other component in Wicket: aComponent = new SomeComponent(id, ...); The new thing is that they *won't* be added to a parent component explicitly/manually. On Page#onInitialize() the first thing to do it to walk over the component tree from the page's markup (just like the walk in the rendering related code) and resolve the missing bits. I.e. while walking thru the markup tree we will check the Java component tree (container.get(tagId)). If there is a miss then we search for a member field that is a component with the same id in the current MarkupContainer, its (Java) super classes and finally in its (Wicket) parent classes. This will solve issue #1 (identical trees in Java and markup) (P.S. Fridolin's code uses @AutoComponent annotation that facilitates searching by component id, but will duplicate the declaration of the id - once in the annotation and second time in 'new MyComponent(ID). This is an implementation detail.) The second part is not less hard - during the walk over the markup tree when an autocomponent (e.g. enclosure) is seen Wicket will use the registered IComponentResolvers to create the Java component and insert it in the Java tree. The tricky part here is that any manually added components (like in Wicket 6.x) to the parent of the autocomponent should be moved into the autocomponent. For example: div wicket:id=a wicket:enclosure child=b span wicket:id=b/span span wicket:id=c/span /wicket:enclosure /div If 'b' and 'c' are added manually to 'a' in the application's Java code: (a (b,c)) then after the resolving phase the tree will be: a (enclosure(b, c)) so b.getParent() in onInitialize() and later will return the Enclosure, not 'a'. I don't know very well the MarkupStream APIs but I think all this should be possible. WDYT about this approach ? Martin Grigorov Wicket Training and Consulting
Re: Markup driven component tree
On Mon, Feb 10, 2014 at 6:26 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Feb 10, 2014 at 9:43 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: i just pushed my new idea into sandbox/component-queueing-2 the way this works now is instead of doing it in onInitialize() and in onConfigure() and all the other places dequeuing now works progressively. upon a change (container.queue() or component.add()) a dequeue will be tried. it even works well with resolved components like enclosures. for such components the markup of page/panel is traversed in onInitialize() and all auto components are placed into the queue. later as components are added/queued these components will be placed into the correct place in the hierarchy. if queue() is used children of these components will be placed under them in correct hierarchy place. this is a big win for using queueing over adding. repeaters also work. the repeater items themselves have to be added to the repeater, but item's children can be queued. this is not a problem since items are mostly added by framework classes. Borders do not yet work mainly because i havent tried to make them work. the tricky part there is to keep the border and BorderBody queues separate. I've added some code to support it but it needs more work. See my response to the commit notification email of my changes. Also we have BorderBehavior and BorderPanel. I think (almost) no one uses those but they exist. imho we can nuke these two things from 7. they dont look very useful. probably added just because we could. InlineEnclosures do not yet work because the code for figuring out the value of the child attribute is really convoluted for the simple thing its supposed to do and i didnt bother parsing it. Should be very similar to how EnclosureHandler works. Done. thanks. the performance is good. there is ComponentQueueingPerformanceTest with a disabled test. give it a go and let me know the results. on my box queuing had under 10% overhead, which is acceptable. I also have some ideas on how to optimize that further by trading cpu for a bit more memory, but not sure In my branch on this topic I used HashMap instead of array. The lookup is faster. Not sure how much memory overhead there is. yeah. havent had time to profile it yet. there are some memory efficient hashmaps floating around, maybe we can adapt one of them. -igor if its needed since the overhead is low and because its only present when queuing is used. also the measurements are not too accurate because most of the time is spent initializing and tearing down a WicketTester instance. memory overhead is also low, two slots (one of which can/should be converted to a flag) are added to MarkupContainer. see ComponentQueuing test for some examples. i would appreciate some help getting Border and InlineEnclosure working if someone has time. look over this and lets discuss if/when we should merge it into master. -igor
Re: [VOTE] Release Apache Wicket 1.4.22
+1 -igor On Thu, Jan 30, 2014 at 5:00 AM, Martin Grigorov mgrigo...@apache.orgwrote: This vote is to release Apache Wicket 1.4.22 Git repo http://git-wip-us.apache.org/repos/asf/wicket.git Branch name build/wicket-1.4.22 Archived and signed Git repo https://dist.apache.org/repos/dist/dev/wicket/1.4.22/ Staging Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-1001/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12324070 This vote ends Tuesday, February 4 at 14:00 (GMT+2) Please test the release and offer your vote. The Wicket team!
Re: Eclipse formatting, was: Martin's wicket pull request
if the formatter config is correct i shouldnt have to just format
edited lines...
-igor
On Tue, Jan 28, 2014 at 4:30 AM, Sven Meier s...@meiers.net wrote:
Our format defines lineSplit=100, so that lines gets wrapped correctly.
If you're using Eclipse's Save Actions, do you have format edited lines
selected in the configuration?
Regards
Sven
On 01/28/2014 09:52 AM, Igor Vaynberg wrote:
apparently eclipse formatter setup in master is incorrect. i am
working on a new queuing implementation idea and keep getting crap
like this all over the code, any ideas? after running code cleanup on
the workspace all the files are modified and i have effectively lost
my changes...
-igor
diff --git a/wicket-core/src/main/java/org/apache/wicket/Application.java
b/wicket-core/src/main/java/org/apache/wicket/Application.java
index 7d8e52b..eab5a42 100644
--- a/wicket-core/src/main/java/org/apache/wicket/Application.java
+++ b/wicket-core/src/main/java/org/apache/wicket/Application.java
@@ -155,7 +155,8 @@ public abstract class Application implements
UnboundListener, IEventSink
* without being in a request/ being set in the thread local
(we need that e.g. for when we are
* in a destruction thread).
*/
- private static final MapString, Application
applicationKeyToApplication = Generics.newHashMap(1);
+ private static final MapString, Application
applicationKeyToApplication = Generics
+ .newHashMap(1);
/** Log. */
private static final Logger log =
LoggerFactory.getLogger(Application.class);
@@ -219,8 +220,8 @@ public abstract class Application implements
UnboundListener, IEventSink
Application application = ThreadContext.getApplication();
if (application == null)
{
- throw new WicketRuntimeException(There is no
application attached to current thread +
- Thread.currentThread().getName());
+ throw new WicketRuntimeException(There is no
application attached to current thread
+ + Thread.currentThread().getName());
On Thu, Nov 14, 2013 at 3:07 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
I did not realise this was waiting on me.
I guess the main problem with using the resources bundle approach is
that the formatting.xml remains necessary for compatibility with
IntelliJ (and perhaps Netbeans). So we can't just bundle up the
.settings folder and use that as the canonical version.
Martijn
On Tue, Nov 12, 2013 at 11:10 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
any progress Martijn?
-igor
On Sun, Nov 10, 2013 at 12:49 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
We can let the eclipse plugin automatically add the project settings
if we upload a jar to maven central with our configuration.
plugin
artifactIdmaven-eclipse-plugin/artifactId
version2.9/version
inheritedtrue/inherited
configuration
downloadSourcestrue/downloadSources
downloadJavadocfalse/downloadJavadoc
ajdtVersion${java.version}/ajdtVersion
additionalConfig
file
name.settings/edu.umd.cs.findbugs.plugin.eclipse.prefs/name
location/edu.umd.cs.findbugs.plugin.eclipse.prefs/location
/file
file
name.settings/org.eclipse.core.resources.prefs/name
location/org.eclipse.core.resources.prefs/location
/file
file
name.settings/org.eclipse.jdt.apt.core.prefs/name
location/org.eclipse.jdt.apt.core.prefs/location
/file
file
name.settings/org.eclipse.jdt.core.prefs/name
location/org.eclipse.jdt.core.prefs/location
/file
file
name.settings/org.eclipse.jdt.ui.prefs/name
location/org.eclipse.jdt.ui.prefs/location
/file
file
name.settings/org.eclipse.wst.validation.prefs/name
location/org.eclipse.wst.validation.prefs/location
/file
file
name.settings/org.maven.ide.eclipse.prefs/name
location/org.maven.ide.eclipse.prefs/location
/file
/additionalConfig
/configuration
dependencies
dependency
groupIdnl.topicus.onderwijs/groupId
artifactIdeclipse-settings/artifactId
version2012.2.2/version
/dependency
/dependencies
/plugin
On Sun, Nov 10, 2013 at 12:45 AM, Igor Vaynberg
igor.vaynb...@gmail.com wrote:
yes, making it a workspace default messes up other projects...
this way every time i import a project into the eclipse workspace i
have to go and manually set the formatter on every module, which as
you can imagine is not optimal
-igor
On Sat, Nov 9, 2013 at 1:40 PM, Martin Grigorov mgrigo...@apache.org
wrote:
But you have to import the xml just once, right ? It is not a big
deal.
Or the problem is that the xml messes up the other projects in your
workspace ?
On Sat, Nov 9, 2013 at 7:24 AM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
it is really frustrating that i have to do this manually now. before
all i had to do was checkout the project and it was all set. wicket
shares my workspace
Re: [Vote] Release Apache Wicket 1.5.11
+1 -igor On Thu, Jan 23, 2014 at 1:00 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: +1 On Mon, Jan 20, 2014 at 5:09 PM, Martin Grigorov mgrigo...@apache.orgwrote: This vote is to release Apache Wicket 1.5.11 Git repo http://git-wip-us.apache.org/repos/asf/wicket.git Branch name build/wicket-1.5.11 Archived and signed Git repo https://dist.apache.org/repos/dist/dev/wicket/1.5.11/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12324069 This vote ends Thursday, January 23 at 18:00 (GMT+2) Please test the release and offer your vote. The Wicket team! -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Markup driven component tree
what about components added in onInitialize() or on onConfigure()? this will also lead to a higher memory/serialization space usage since by default you need a field to store the component ref. not sure its worth doing it this way... -igor On Wed, Jan 22, 2014 at 12:12 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Recently Fridolin Jackstadt shared his approach to autowire components - https://github.com/wicket-acc/wicket-autowire. I believe this approach can solve two issues: - duplicate construction of the component tree - once in the markup and second time in Java code - auto components available only in the render phase Here is how I see it: Any MarkupContainer that wants to use markup-driven-tree must declare the components as member fields: private SomeComponent aComponent; These fields will be instantiated like any other component in Wicket: aComponent = new SomeComponent(id, ...); The new thing is that they *won't* be added to a parent component explicitly/manually. On Page#onInitialize() the first thing to do it to walk over the component tree from the page's markup (just like the walk in the rendering related code) and resolve the missing bits. I.e. while walking thru the markup tree we will check the Java component tree (container.get(tagId)). If there is a miss then we search for a member field that is a component with the same id in the current MarkupContainer, its (Java) super classes and finally in its (Wicket) parent classes. This will solve issue #1 (identical trees in Java and markup) (P.S. Fridolin's code uses @AutoComponent annotation that facilitates searching by component id, but will duplicate the declaration of the id - once in the annotation and second time in 'new MyComponent(ID). This is an implementation detail.) The second part is not less hard - during the walk over the markup tree when an autocomponent (e.g. enclosure) is seen Wicket will use the registered IComponentResolvers to create the Java component and insert it in the Java tree. The tricky part here is that any manually added components (like in Wicket 6.x) to the parent of the autocomponent should be moved into the autocomponent. For example: div wicket:id=a wicket:enclosure child=b span wicket:id=b/span span wicket:id=c/span /wicket:enclosure /div If 'b' and 'c' are added manually to 'a' in the application's Java code: (a (b,c)) then after the resolving phase the tree will be: a (enclosure(b, c)) so b.getParent() in onInitialize() and later will return the Enclosure, not 'a'. I don't know very well the MarkupStream APIs but I think all this should be possible. WDYT about this approach ? Martin Grigorov Wicket Training and Consulting
Re: Markup driven component tree
On Thu, Jan 23, 2014 at 8:20 AM, Martin Grigorov mgrigo...@apache.org wrote: Once the markup driven construction is done (just before onInitialize()) the application will have to use the old good add()/addOrReplace(). yeah, but onInitialize() is there to partially replace the constructor as a place to add components. The components are already in the MarkupContainer#children data structure. So each field will add extra 8 bytes on 64bit machine (or 4 bytes with CompressedOops enabled). yes, thats the 8 bytes i was talking about. considering some pages have easily over a hundred components that adds up. Serialization is the same - the object is written once, with several pointers. no, serialization will suffer from the same 8 bytes per component reference issue. that means thats a bunch more bytes to shuffle to and from disk and also across network when clustered. I am also not fully sure in the approach but I am experimenting and so far it works well. And it is configurable, by default disabled. We can advertise it as experimental ?! something like this cannot be enabled/disabled. if a component library uses it then it will fail on applications where this is disabled. also, what happens in situations where ids are not unique? then those cannot be put into the hierarchy? its common to have structure like this: a wicket:id=removespan wicket:id=label/span/aa wicket:id=addspan wicket:id=label/a another exception is the repeater, unless you create a custom subclass of Item which no one ever does. seems to me there are too many gotchas for all but the most trivial cases. couple this together with the fact that it has to be enabled as mentioned above would put me at -0.5 for this for now. -igor I will add more use cases/tests soon. And caching for the reflection stuff. On Thu, Jan 23, 2014 at 6:09 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what about components added in onInitialize() or on onConfigure()? this will also lead to a higher memory/serialization space usage since by default you need a field to store the component ref. not sure its worth doing it this way... -igor On Wed, Jan 22, 2014 at 12:12 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Recently Fridolin Jackstadt shared his approach to autowire components - https://github.com/wicket-acc/wicket-autowire. I believe this approach can solve two issues: - duplicate construction of the component tree - once in the markup and second time in Java code - auto components available only in the render phase Here is how I see it: Any MarkupContainer that wants to use markup-driven-tree must declare the components as member fields: private SomeComponent aComponent; These fields will be instantiated like any other component in Wicket: aComponent = new SomeComponent(id, ...); The new thing is that they *won't* be added to a parent component explicitly/manually. On Page#onInitialize() the first thing to do it to walk over the component tree from the page's markup (just like the walk in the rendering related code) and resolve the missing bits. I.e. while walking thru the markup tree we will check the Java component tree (container.get(tagId)). If there is a miss then we search for a member field that is a component with the same id in the current MarkupContainer, its (Java) super classes and finally in its (Wicket) parent classes. This will solve issue #1 (identical trees in Java and markup) (P.S. Fridolin's code uses @AutoComponent annotation that facilitates searching by component id, but will duplicate the declaration of the id - once in the annotation and second time in 'new MyComponent(ID). This is an implementation detail.) The second part is not less hard - during the walk over the markup tree when an autocomponent (e.g. enclosure) is seen Wicket will use the registered IComponentResolvers to create the Java component and insert it in the Java tree. The tricky part here is that any manually added components (like in Wicket 6.x) to the parent of the autocomponent should be moved into the autocomponent. For example: div wicket:id=a wicket:enclosure child=b span wicket:id=b/span span wicket:id=c/span /wicket:enclosure /div If 'b' and 'c' are added manually to 'a' in the application's Java code: (a (b,c)) then after the resolving phase the tree will be: a (enclosure(b, c)) so b.getParent() in onInitialize() and later will return the Enclosure, not 'a'. I don't know very well the MarkupStream APIs but I think all this should be possible. WDYT about this approach ? Martin Grigorov Wicket Training and Consulting
Re: Markup driven component tree
On Thu, Jan 23, 2014 at 8:53 AM, Martin Grigorov mgrigo...@apache.org wrote: On Thu, Jan 23, 2014 at 6:36 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: On Thu, Jan 23, 2014 at 8:20 AM, Martin Grigorov mgrigo...@apache.org wrote: Once the markup driven construction is done (just before onInitialize()) the application will have to use the old good add()/addOrReplace(). yeah, but onInitialize() is there to partially replace the constructor as a place to add components. It is perfectly fine to add components later. If markup-driven construction cannot find a component it doesn't blow immediately. It just ignores the rest of the markup stream below the missing component. If there is a missing component during rendering then an exception is thrown. The components are already in the MarkupContainer#children data structure. So each field will add extra 8 bytes on 64bit machine (or 4 bytes with CompressedOops enabled). yes, thats the 8 bytes i was talking about. considering some pages have easily over a hundred components that adds up. Serialization is the same - the object is written once, with several pointers. no, serialization will suffer from the same 8 bytes per component reference issue. that means thats a bunch more bytes to shuffle to and from disk and also across network when clustered. Well, I see no other way to find a reference to a component :-/ If a page has 1000 components then this is 8k more. 1000 components is a lot. Most pages have much less. I have to check again but recently while working on Memcached based IDataStore I think a pretty simple page serialized was about 60k. I am also not fully sure in the approach but I am experimenting and so far it works well. And it is configurable, by default disabled. We can advertise it as experimental ?! something like this cannot be enabled/disabled. if a component library uses it then it will fail on applications where this is disabled. yes, this is true a workaround here is each MarkupContainer can declare whether it supports markup-driven tree by overriding org.apache.wicket.MarkupContainer#isMarkupDrivenComponentTreeEnabled i.e. the library component can always return true also, what happens in situations where ids are not unique? then those cannot be put into the hierarchy? its common to have structure like this: a wicket:id=removespan wicket:id=label/span/aa wicket:id=addspan wicket:id=label/a This should work fine at the moment. Each MarkupContainer instance resolves its own fields/components. I'll add test tomorrow to verify. not sure what you mean by works fine. @Auto WebMarkupContainer a,b,c,d; a=new Link(remove); b=new Label(label, remove); c=new Link(add); d=new Label(label, add); how does wicket know the difference between b and d? this will get worse with subclasses as now you have to be aware to not add any component with the same id used in the class hierarchy... -igor another exception is the repeater, unless you create a custom subclass of Item which no one ever does. another test to add ! seems to me there are too many gotchas for all but the most trivial cases. couple this together with the fact that it has to be enabled as mentioned above would put me at -0.5 for this for now. -igor I will add more use cases/tests soon. And caching for the reflection stuff. On Thu, Jan 23, 2014 at 6:09 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: what about components added in onInitialize() or on onConfigure()? this will also lead to a higher memory/serialization space usage since by default you need a field to store the component ref. not sure its worth doing it this way... -igor On Wed, Jan 22, 2014 at 12:12 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Recently Fridolin Jackstadt shared his approach to autowire components - https://github.com/wicket-acc/wicket-autowire. I believe this approach can solve two issues: - duplicate construction of the component tree - once in the markup and second time in Java code - auto components available only in the render phase Here is how I see it: Any MarkupContainer that wants to use markup-driven-tree must declare the components as member fields: private SomeComponent aComponent; These fields will be instantiated like any other component in Wicket: aComponent = new SomeComponent(id, ...); The new thing is that they *won't* be added to a parent component explicitly/manually. On Page#onInitialize() the first thing to do it to walk over the component tree from the page's markup (just like the walk in the rendering related code) and resolve the missing bits. I.e. while walking thru the markup tree we will check the Java component tree (container.get(tagId)). If there is a miss then we search for a member field that is a component with the same id
Re: [jira] [Resolved] (WICKET-5462) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton
indeed, 6.13 hasnt been marked as released in jira yet... On Mon, Jan 6, 2014 at 11:47 AM, Sven Meier s...@meiers.net wrote: Fix Version/s: 7.0.0 6.13.0 That should be 6.14.0, no? Sven On 01/06/2014 07:27 PM, Igor Vaynberg (JIRA) wrote: [ https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5462. --- Resolution: Fixed Fix Version/s: 7.0.0 6.13.0 Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton --- Key: WICKET-5462 URL: https://issues.apache.org/jira/browse/WICKET-5462 Project: Wicket Issue Type: Bug Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: The state of Wicket 6.13
+1 to rebase On Sun, Jan 5, 2014 at 8:39 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: All, Since a long time I have tried to coerce the Maven release plugin to actually build a release. It appears that newer versions of git have altered the output format on which the m-r-p depends to commit the pom changes (release poms) and then tag that result. This caused a bug hunt and trial/error period of weeks to finally just now when I was able to build a 6.13.0 release. Now this is the state of 4 weeks ago, and I wonder if it is more proper to rebase to now and cut a release from that. Personally I would do just that (rebase to now and release that). Opinions? Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Passing Component or Class to IAuthorizationStrategy#isInstantiationAuthorized()
this is a security check, so the whole idea is that it is ran before any of the user's code in the constructor which may have side-effects. eg a constructor marking a record as ready to be deleted because a delete panel was instantiated. the class itself should be enough. even if you get an instance you cant use anything in it because its partially constructed. the question is if we do pass an instance how many users will bother reading javadoc? and out of those how many really understand how objects are constructed? i think we should close the issue as wont-fix, reading it It would be easier to decide if instantiation is authorized if one could access some properties of the component being constructed. which is exactly what you cannot/must not do because the object is only partially initialized, thus proving my point above. the ComponentInstantiationListener is a very special case where we make an exception. the entire point of this interface is to work with a partially constructed object and most users will never implement their own as opposed to the authorization strategy... -igor On Fri, Dec 20, 2013 at 12:53 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, The reporter of https://issues.apache.org/jira/browse/WICKET-5454 asked to pass the Component instance to IAuthorizationStrategy#isInstantiationAuthorized() instead of just its class. I have no idea why the API has been designed this way but Carl-Eric gave a good explanation - the component is not yet fully constructed. The thing that bothers me is why it is OK to use the instance in my custom IComponentInstantiationListener and it is not OK to do the same in IAuthorizationStrategy#isInstantiationAuthorized() ? If there is a javadoc explaining the possible problem (as for IComponentInstantiationListener#onInstantiation()) then it is OK. Even more - at https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L276you can see that right ater rejecting the *Class* we pass the *instance* to the UnauthorizedComponentInstantiationListener! Martin Grigorov Wicket Training and Consulting
Re: Passing Component or Class to IAuthorizationStrategy#isInstantiationAuthorized()
i am guessing that the id of the component would be useful for logging in some cases, but i think it should just be passed in as an extra argument if thats the case. something to fix in 7.0... -igor On Fri, Dec 20, 2013 at 11:44 AM, Martin Grigorov mgrigo...@apache.org wrote: and what about IUnauthorizedComponentInstantiationListener ? it receives the partially constructed object in case of rejection its javadoc states: The partially constructed component (only the id is guaranteed to be valid) but even Wicket sources use it (partially) wrong later: org.apache.wicket.authroles.authentication.AuthenticatedWebApplication#onUnauthorizedInstantiation casts the instance to a Page and passes it to org.apache.wicket.authroles.authentication.AuthenticatedWebApplication#onUnauthorizedPage(Page) Here we use just page.getClass() but specialization of this class may try to use the page instance for anything Martin Grigorov Wicket Training and Consulting On Fri, Dec 20, 2013 at 6:14 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: this is a security check, so the whole idea is that it is ran before any of the user's code in the constructor which may have side-effects. eg a constructor marking a record as ready to be deleted because a delete panel was instantiated. the class itself should be enough. even if you get an instance you cant use anything in it because its partially constructed. the question is if we do pass an instance how many users will bother reading javadoc? and out of those how many really understand how objects are constructed? i think we should close the issue as wont-fix, reading it It would be easier to decide if instantiation is authorized if one could access some properties of the component being constructed. which is exactly what you cannot/must not do because the object is only partially initialized, thus proving my point above. the ComponentInstantiationListener is a very special case where we make an exception. the entire point of this interface is to work with a partially constructed object and most users will never implement their own as opposed to the authorization strategy... -igor On Fri, Dec 20, 2013 at 12:53 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, The reporter of https://issues.apache.org/jira/browse/WICKET-5454 asked to pass the Component instance to IAuthorizationStrategy#isInstantiationAuthorized() instead of just its class. I have no idea why the API has been designed this way but Carl-Eric gave a good explanation - the component is not yet fully constructed. The thing that bothers me is why it is OK to use the instance in my custom IComponentInstantiationListener and it is not OK to do the same in IAuthorizationStrategy#isInstantiationAuthorized() ? If there is a javadoc explaining the possible problem (as for IComponentInstantiationListener#onInstantiation()) then it is OK. Even more - at https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L276you can see that right ater rejecting the *Class* we pass the *instance* to the UnauthorizedComponentInstantiationListener! Martin Grigorov Wicket Training and Consulting
Re: Future of wicket-cdi
i agree we should restart with the original implementation and incrementally introduce the new features - thats what i proposed in the original pull request. i am not a big fan of having the application instance managed. what is the value of this? it can be injected using noncontextual just like everything else... -igor On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij emond.papega...@gmail.com wrote: Hi all, You probably noticed the the flood of emails regarding wicket-cdi these last few days, which IMHO is good, because it means wicket-cdi is alive. However, the current status is that the current (old) implementation of wicket-cdi works badly with CDI 1.1 and the experimental (new) version is broken in various ways. This is not good, as there is no good implementation to use for CDI 1.1 users. I've reviewed parts of the code in wicket-cdi-1.1 and noticed the following problems: - Featuritis: it supports all kinds of usecases nobody is every going to use, such as: partly managed applications, per-conversation auto-conversions, per-conversation propagation, package ignores, switched to enable/disable injection on almost everyting. - Buggy: auto-conversations are broken for everything but pages, injection in anonymous classes was broken, probably more. - Too much state: configuration options are copied all over the place, objects with different lifecycles share state. - Too much injection: everything is injected, which makes it almost impossible to see what's linked to what. I've also noticed some very nices features: - CDI 1.1 support with conversations via the Weld API - Management of the application and the Wicket-cdi configuration by cdi. - Better implementation of NonContextual injection, using caches. - Better testcases The experimental code is in such a state that is it almost impossible to cleanup. On the other hand, I do not want to loose some of the new features. Therefore, I propose the following: restart the wicket-cdi-1.1 implementation, starting from the current wicket-cdi implementation and reintroducing the features one-by-one. Also, I would like to remove some of the existing features, like most of the toggle-switches, and I would like to make the new CdiWebApplicationFactory mandatory to always have the application be managed. All this will still be experimental in wicket 6, but perhaps it can be made the default in 7. As we at Topicus are currently starting the migration from JBoss 7.1 to WildFly 8, I can work on this 1 or 2 days a week. Let me know what you think, Emond
Re: Future of wicket-cdi
On Wed, Nov 13, 2013 at 1:43 PM, John Sarman johnsar...@gmail.com wrote: So let me filter through injection of App. CdiWicketFilter gets injected factory. @Inject CdiWebApplicationFactory applicationFactory; the Factory get injected the following @Inject @Any InstanceWebApplication applications; @Inject CdiConfiguration cdiConfiguration; If there is only one application in a war then the web.xml only needs filter filter-nameCdiApplication/filter-name filter-classorg.apache.wicket.cdi.CdiWicketFilter/filter-class /filter if multiple then additional init-param param-nameapplicationName/param-name param-valueCdiExample/param-value /init-param and @WicketApp(CdiExample) added. i dont see this as an advantage. specifying a class name is trivial. further you are assuming i am running inside a container that has its filter's managed by cdi, this is not always the case so using your cdi filter would fail. one would have to fall back on wicket-filter and specify the cdi application factory that you provide, but that class itself assumes it is managed by cdi, so it wont work either. so you did not leave an escape hatch for people using simple containers. my original code may not be cdi-pretty but it works for all containers out there - cdi managed or not. No need to start up CDI in init() we do not start up cdi in init, we configure how it interacts with the wicket application. settings such things as conversation propagation mode, etc. Start using CDI. For apps that may want to add CDI they just filter filter-nameCdiApplication/filter-name filter-classorg.apache.wicket.cdi.CdiWicketFilter/filter-class /filter Start using CDI. So I still defend injection of the Cdi Wicket integration code. Also if it is removed then code will have to be added to differentiate which cdi implementation is being used. Currently CDI does this so long as two different CDI implementation jars aren't add, which would be ambiguous. this will still work. you can still inject the configuration using noncontextual and pull the right instance. or use jdk's ServiceLoader to find all implementors. my problem with this is that there is a specific lifecycle to the application that is not managed by cdi. it is not safe to use the application instance after it has been created, you have to wait until wicket calls certain methods on it. by making it managed you are giving the impression that it is safe to inject the instance and use it in various places. it is not, not until it has been properly configured. i do not want to debug cases where my configuration changes to the application disappear because my code got that injected the application and configured it got called before internalInit(). either create a subcpass with @PostConstruct that configures the application - which wont work - people dont like using subclasses - or create a provider. -igor On Wed, Nov 13, 2013 at 4:31 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: i agree we should restart with the original implementation and incrementally introduce the new features - thats what i proposed in the original pull request. i am not a big fan of having the application instance managed. what is the value of this? it can be injected using noncontextual just like everything else... -igor On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij emond.papega...@gmail.com wrote: Hi all, You probably noticed the the flood of emails regarding wicket-cdi these last few days, which IMHO is good, because it means wicket-cdi is alive. However, the current status is that the current (old) implementation of wicket-cdi works badly with CDI 1.1 and the experimental (new) version is broken in various ways. This is not good, as there is no good implementation to use for CDI 1.1 users. I've reviewed parts of the code in wicket-cdi-1.1 and noticed the following problems: - Featuritis: it supports all kinds of usecases nobody is every going to use, such as: partly managed applications, per-conversation auto-conversions, per-conversation propagation, package ignores, switched to enable/disable injection on almost everyting. - Buggy: auto-conversations are broken for everything but pages, injection in anonymous classes was broken, probably more. - Too much state: configuration options are copied all over the place, objects with different lifecycles share state. - Too much injection: everything is injected, which makes it almost impossible to see what's linked to what. I've also noticed some very nices features: - CDI 1.1 support with conversations via the Weld API - Management of the application and the Wicket-cdi configuration by cdi. - Better implementation of NonContextual injection, using caches. - Better testcases The experimental code is in such a state that is it almost impossible to cleanup. On the other hand, I do not want to loose some of the new features. Therefore, I propose
Re: Future of wicket-cdi
On Wed, Nov 13, 2013 at 2:42 PM, John Sarman johnsar...@gmail.com wrote:
snip
further you are assuming i am running inside a container that has its
filter's managed by cdi, this is not always the case so using your cdi
filter would fail. one would have to fall back on wicket-filter and
I am 100% assuming that since you just included wicket-weld in the build.
Therefore you do have a managed container at that point.
we deploy in tomcat. we include weld as a war-dependency, not as
tomcat dependency, therefore in our deployments filters are not
injected. i assume this is how most people deploying to tomcat or
jetty have it set up. are we dropping support for those people?
specify the cdi application factory that you provide, but that class
itself assumes it is managed by cdi, so it wont work either. so you
did not leave an escape hatch for people using simple containers.
my original code may not be cdi-pretty but it works for all
containers out there - cdi managed or not.
I couldn't have got anywhere without your code. I was pretty to me m_BLAH
m_BLAT is ugly.
I'm an ole school constructor versus setter myself, Object is ready at
Construction. But with CDI I get that guarantee with the no arg, easier to
Mock.
unfortunately WebApplication instances are not ready at construction,
that is the problem.
No need to start up CDI in init()
we do not start up cdi in init, we configure how it interacts with the
wicket application. settings such things as conversation propagation
mode, etc.
Yeah but that starts it otherwise the Injectors are not set up and it
wouldn't work(inject).
in our deployment we have a servlet listener that bootstraps cdi so
its available to other servlets, not just wicket. in
application.init() you simply configure wicket to use cdi by giving it
the bean manager. this approach also works in environments with no
JNDI where you cannot simply pull a bean manager out of some store but
have to use a custom mechanism to retrieve it. imagine an application
with an embedded servlet container.
snip
my problem with this is that there is a specific lifecycle to the
application that is not managed by cdi. it is not safe to use the
application instance after it has been created, you have to wait until
wicket calls certain methods on it.
Yeah, I do wait. That's why I used the Factory. Only thing that is done is
some member variables are populated. I did not override Wicket management,
just injected some dependencies.
you wait, but the users may not. now that application instance is
managed by cdi why cant i do something like this:
class WebConfigurator {
@Inject WebApplication application;
private void configure(@Observes ContainerStartEvent) {
application.getMarkupSettings().setFoo(bar);
}
}
after all, this would be the CDI-way of configuring the web
application instance. but this does not work because webapplication
instance is managed by wicket and not by cdi. so if this code runs
before the filter my settings would be overwritten by internalInit()
call.
this is the impedance mismatch i do not like. artifacts whose
lifecycle is managed by wicket should not also be managed by cdi, or
if they are there should be a provider that creates instances and
knows how to correctly configure it.
so in the case above when my configurator is called the provider
should bootstrap the wicket application, call internalinit(), and have
it all ready for my code.
by making it managed you are giving the impression that it is safe to
inject the instance and use it in various places. it is not, not until
it has been properly configured. i do not want to debug cases where my
configuration changes to the application disappear because my code got
that injected the application and configured it got called before
internalInit(). either create a subcpass with @PostConstruct that
configures the application - which wont work - people dont like using
subclasses - or create a provider.
Like I said Cdi injects some members, the Factory returns the application
to WicketFilter and the same lifecycle commences.
see point above, by making it managed you are making it available for
other code to consume as injectable.
-igor
Re: Future of wicket-cdi
On Wed, Nov 13, 2013 at 4:18 PM, John Sarman johnsar...@gmail.com wrote:
So maybe we should just remove all the scoped classes. Add the code to
automagically find a cdi impl, weld etc.
yeah, we can use jdk's ServiceLoader to see whats on the classpath.
Create custom factory that
CdiConfiguration is set up via parameters in web.xml.
im not sure this is necessary, it will make it more difficult for
deployments where its hard to find the bean manager (ie its not in a
well known place in jndi). the only part this saves is calling new
CdiConfiguration()configure(this) in application init, right? i
actually like that part because it makes it clear what options i set -
propagation, etc.
Then after
instantiating the App pass it to the NonContextual for injection.
see below
Rewrite
the tests to work with new technique. This allows app injection with Wicket
in charge, before init. And everything works the same. That may be a
better roadmap for the rewrite. Also that does eliminate the need for the
weld listener.
Time to start planning on a rewrite, I am not married to the Injection,
just like to add @Resource(mailSessionJNDI) to my Application and use it in
init().
the application is already injected, thats why i dont understand why
you had a problem with the original way of doing things...
public class MyApplication extends WebApplication {
@Resource resource;
public void init() {
// do some configuration
new CdiConfiguration().configure(this);
// after the line above the application is injected and resource
is now available. by default injectApplication bit in CdiConfiguration
is set to true and it passes the instance through NonContextual.
resource.doSomething();
}
}
-igor
On Wed, Nov 13, 2013 at 6:40 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
On Wed, Nov 13, 2013 at 2:42 PM, John Sarman johnsar...@gmail.com wrote:
snip
further you are assuming i am running inside a container that has its
filter's managed by cdi, this is not always the case so using your cdi
filter would fail. one would have to fall back on wicket-filter and
I am 100% assuming that since you just included wicket-weld in the build.
Therefore you do have a managed container at that point.
we deploy in tomcat. we include weld as a war-dependency, not as
tomcat dependency, therefore in our deployments filters are not
injected. i assume this is how most people deploying to tomcat or
jetty have it set up. are we dropping support for those people?
specify the cdi application factory that you provide, but that class
itself assumes it is managed by cdi, so it wont work either. so you
did not leave an escape hatch for people using simple containers.
my original code may not be cdi-pretty but it works for all
containers out there - cdi managed or not.
I couldn't have got anywhere without your code. I was pretty to me
m_BLAH
m_BLAT is ugly.
I'm an ole school constructor versus setter myself, Object is ready at
Construction. But with CDI I get that guarantee with the no arg, easier
to
Mock.
unfortunately WebApplication instances are not ready at construction,
that is the problem.
No need to start up CDI in init()
we do not start up cdi in init, we configure how it interacts with the
wicket application. settings such things as conversation propagation
mode, etc.
Yeah but that starts it otherwise the Injectors are not set up and it
wouldn't work(inject).
in our deployment we have a servlet listener that bootstraps cdi so
its available to other servlets, not just wicket. in
application.init() you simply configure wicket to use cdi by giving it
the bean manager. this approach also works in environments with no
JNDI where you cannot simply pull a bean manager out of some store but
have to use a custom mechanism to retrieve it. imagine an application
with an embedded servlet container.
snip
my problem with this is that there is a specific lifecycle to the
application that is not managed by cdi. it is not safe to use the
application instance after it has been created, you have to wait until
wicket calls certain methods on it.
Yeah, I do wait. That's why I used the Factory. Only thing that is done
is
some member variables are populated. I did not override Wicket
management,
just injected some dependencies.
you wait, but the users may not. now that application instance is
managed by cdi why cant i do something like this:
class WebConfigurator {
@Inject WebApplication application;
private void configure(@Observes ContainerStartEvent) {
application.getMarkupSettings().setFoo(bar);
}
}
after all, this would be the CDI-way of configuring the web
application instance. but this does not work because webapplication
instance is managed by wicket and not by cdi. so if this code runs
before the filter my settings would be overwritten by internalInit()
call
Re: Eclipse formatting, was: Martin's wicket pull request
any progress Martijn?
-igor
On Sun, Nov 10, 2013 at 12:49 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
We can let the eclipse plugin automatically add the project settings
if we upload a jar to maven central with our configuration.
plugin
artifactIdmaven-eclipse-plugin/artifactId
version2.9/version
inheritedtrue/inherited
configuration
downloadSourcestrue/downloadSources
downloadJavadocfalse/downloadJavadoc
ajdtVersion${java.version}/ajdtVersion
additionalConfig
file
name.settings/edu.umd.cs.findbugs.plugin.eclipse.prefs/name
location/edu.umd.cs.findbugs.plugin.eclipse.prefs/location
/file
file
name.settings/org.eclipse.core.resources.prefs/name
location/org.eclipse.core.resources.prefs/location
/file
file
name.settings/org.eclipse.jdt.apt.core.prefs/name
location/org.eclipse.jdt.apt.core.prefs/location
/file
file
name.settings/org.eclipse.jdt.core.prefs/name
location/org.eclipse.jdt.core.prefs/location
/file
file
name.settings/org.eclipse.jdt.ui.prefs/name
location/org.eclipse.jdt.ui.prefs/location
/file
file
name.settings/org.eclipse.wst.validation.prefs/name
location/org.eclipse.wst.validation.prefs/location
/file
file
name.settings/org.maven.ide.eclipse.prefs/name
location/org.maven.ide.eclipse.prefs/location
/file
/additionalConfig
/configuration
dependencies
dependency
groupIdnl.topicus.onderwijs/groupId
artifactIdeclipse-settings/artifactId
version2012.2.2/version
/dependency
/dependencies
/plugin
On Sun, Nov 10, 2013 at 12:45 AM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
yes, making it a workspace default messes up other projects...
this way every time i import a project into the eclipse workspace i
have to go and manually set the formatter on every module, which as
you can imagine is not optimal
-igor
On Sat, Nov 9, 2013 at 1:40 PM, Martin Grigorov mgrigo...@apache.org wrote:
But you have to import the xml just once, right ? It is not a big deal.
Or the problem is that the xml messes up the other projects in your
workspace ?
On Sat, Nov 9, 2013 at 7:24 AM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
it is really frustrating that i have to do this manually now. before
all i had to do was checkout the project and it was all set. wicket
shares my workspace with other projects so the workspace-default is
not going to work.
can we drop the format def on wicket.apache.org and configure the
maven plugin to set it up:
http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html
-igor
On Fri, Nov 8, 2013 at 12:56 AM, Martin Grigorov mgrigo...@apache.org
wrote:
I'll test this soon.
I'll update the docs for IDEA too if needed.
On Thu, Nov 7, 2013 at 11:02 AM, Sven Meier s...@meiers.net wrote:
Thanks, I've added a hint to the Idea instructions.
Regards
Sven
On 11/06/2013 10:12 AM, Vojtěch Krása wrote:
You should also specify values for Class count to use import with '*'
and
Names count to use static import with '*', since these values are
not in EclipseCodeFormat.xml,
and differs between Idea and Eclipse by default.
V.
2013/11/6 Sven Meier s...@meiers.net
Hi all,
I removed all org.eclipse.jdt.[core|ui].prefs from the repo as
discussed.
EclipseCodeFormat.xml is updated now to our latest and greatest code
format
(which might differ between 6.x and master).
Eclipse users should run mvn eclipse:eclipse to regenerate
org.eclipse.jdt.core.prefs, then (re-)import EclipseCodeFormat.xml and
use
it as the default for your Wicket workspace(s).
I've added a paragraph about the recommended Eclipse setup here:
http://wicket.apache.org/learn/ides.html
Could an Idea user please confirm that the format plugin (
http://plugins.jetbrains.com/plugin/6546) works as expected?
Regards
Sven
On 11/05/2013 12:05 PM, Martin Grigorov wrote:
On Tue, Nov 5, 2013 at 1:01 PM, Sven Meier s...@meiers.net wrote:
IMHO we should have one authoritative source for our source format
only.
Whether this is EclipseCodeFormat.xml or something else can be
dicussed
on
the other mail thread.
Currently all org.eclipse.jdt.core.prefs have already diverged from
EclipseCodeFormat.xml (perhaps they even differ between each
other?),
so
I'm +1 to remove those settings from the repo as Martin has
suggested.
I can live with having to configure my Wicket workspace(s) once by
importing EclipseCodeFormat.xml.
So if no one objects, I'll update EclipseCodeFormat.xml from the
current
settings in wicket-core and apply Martin's patch afterwards.
I'm +1.
With the plugin that Rusi suggested in the other thread I can import
EclipseCodeFormat.xml in Intellij IDEA and hopefully the
formatting
will
be the same for all of us.
Sven
On 11/04/2013 04:42 PM, Martin Funk wrote:
not quite
if the org.eclipse.jdt.ui.prefs are not present eclipse will fall
back
Re: remove recently merged cdi 1.1 from 6.x
the point on INonContextualManager was to internalize NonContextual - in case cdi implementation provides a better way to perform non-contextual injection. now that NonContextualManager is @ApplicationScoped and CdiConfiguration does not have a setter for it this functionality is lost. and even if cdi configuration had a setter, there is no longer a guarantee that someone did not inject one and use it before a new one was set on the configuration. that is why these things were not managed by cdi in the initial code... -igor On Mon, Nov 11, 2013 at 11:16 AM, John Sarman johnsar...@gmail.com wrote: Also Noncontextual.of is never used anywhere except in the Wicket CDI api, so I disagree. It solely used by the NonContextualManager which is ApplicationScoped and the BeanManager is injected. The CdiCleanup also uses it and is passed the BeanManager during configuration, both cases do not make it unnice since it is an internal api. On Mon, Nov 11, 2013 at 2:11 PM, John Sarman johnsar...@gmail.com wrote: Actually I just changed them back to the way Igor originally implemented it. On Mon, Nov 11, 2013 at 2:10 PM, Emond Papegaaij emond.papega...@gmail.com wrote: Hi John, There is nothing wrong with looking up the BeanManager in a static context. It's just that the current implementation of CDI.current().getBeanManager() is broken in Weld. I expect this to be fixed soon. The workaround moves the lookup to a single place and tries a portable JNDI lookup first. This will work in all EE containers. More importantly, the user doesn't notice the workaround at all. Your commit changes the signature of NonContextual.of. You are now required to pass in the BeanManager, which is not very nice, because NonContextual is to do CDI injection in places where CDI can't do it for you. In these places, you often don't have a BeanManager available. I think the workaround should stay until the bug is fixed in Weld. Best regards, Emond On Mon, Nov 11, 2013 at 7:45 PM, John Sarman johnsar...@gmail.com wrote: Edmond, I updated the cdi code to not ever use the CDI.current(). I reworked your test earlier to just inject the BeanManager and that properly allows the multiple wars to see the InjectableTargets from a shared lib. I could only conclude that CDI.current should not be called from a static method, so instead of joining the weld team or submitting an issue, I just removed that possibility from the code. That latest code is in https://github.com/jsarman/wicket master branch. This also removed the need for the BeanManagerLookup workaround. On Mon, Nov 11, 2013 at 8:49 AM, John Sarman johnsar...@gmail.com wrote: Nevermind, I should not write emails this early, without an unsend. Servlet A should see same BeanManager as Servlet B, if both servlets are deployed from same war file. That is ApplicationScoped. On Mon, Nov 11, 2013 at 8:47 AM, John Sarman johnsar...@gmail.com wrote: Ok, I read through your test code, so if you are saying that servlet a gets same beanmanager as servlet b then yeah thats bad. On Mon, Nov 11, 2013 at 8:44 AM, John Sarman johnsar...@gmail.com wrote: I was looking at your bug, but in the case you specified where the cached BeanManager is passed, seems to be the correct behavior because the CdiConfiguration is ApplicationScoped. The CDI class states this: /** * Get the CDI BeanManager for the current context * * @return */ public abstract BeanManager getBeanManager(); So the cached BeanManager passed back is because it is accessed in an ApplicationScoped class. ApplicationScoped != Wickets Application scope. On Mon, Nov 11, 2013 at 8:26 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: You are right, InitialContext.lookup was returning null. I've fixed it by falling back to CDI.current().getBeanManager() in that case. The workaround is needed because of a very nasty bug in de Wildfly-Weld integration: https://issues.jboss.org/browse/WFLY-2481 Best regards, Emond On Monday 11 November 2013 08:18:20 John Sarman wrote: As far as the Test failing, I think the workaround code to use jndi first may have caused the test to fail. So far it seems that all the request pull 50 is not in the 6 branch. What forced the need for the workaround? John On Mon, Nov 11, 2013 at 8:00 AM, John Sarman johnsar...@gmail.com wrote: It is not a forced requirement, just an option for full cdi injection. On Mon, Nov 11, 2013 at 3:50 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: Hi John, I've just merged the pull request in the wicket-6.x branch (still under experimental). The version still is 0.2-SNAPSHOT, as the versions are automatically increased on release. The
Re: git commit: WICKET-5411 auto label auto update during ajax
i suppose that bit of js can be rewritten to use pure dom, but has
anyone actually ever implemented wicket-event.js and wicket-ajax.js
using anything other then jquery?
-igor
On Sat, Nov 9, 2013 at 1:34 PM, Martin Grigorov mgrigo...@apache.org wrote:
On Sat, Nov 9, 2013 at 8:49 AM, ivaynb...@apache.org wrote:
Updated Branches:
refs/heads/wicket-6.x 4e9a83fdc - a73209bea
WICKET-5411 auto label auto update during ajax
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/a73209be
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/a73209be
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/a73209be
Branch: refs/heads/wicket-6.x
Commit: a73209beab8814a06f2e085384ad87bdf1fda212
Parents: 4e9a83f
Author: Igor Vaynberg igor.vaynb...@gmail.com
Authored: Fri Nov 8 22:48:22 2013 -0800
Committer: Igor Vaynberg igor.vaynb...@gmail.com
Committed: Fri Nov 8 22:48:22 2013 -0800
--
.../form/AjaxFormComponentUpdatingBehavior.java | 2 +-
.../wicket/core/util/string/CssUtils.java | 14 ++
.../markup/html/form/AutoLabelResolver.java | 130 ++-
.../apache/wicket/markup/html/form/Form.java| 24 +++-
.../wicket/markup/html/form/FormComponent.java | 34 -
.../wicket/protocol/http/WebApplication.java| 36 +++--
6 files changed, 212 insertions(+), 28 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/a73209be/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
b/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
index 7eab478..bd8267c 100644
---
a/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
+++
b/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
@@ -160,8 +160,8 @@ public abstract class
AjaxFormComponentUpdatingBehavior extends AjaxEventBehavio
catch (RuntimeException e)
{
onError(target, e);
-
}
+ formComponent.updateAutoLabels(target);
}
/**
http://git-wip-us.apache.org/repos/asf/wicket/blob/a73209be/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
b/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
index a4944a3..7de8669 100644
---
a/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
+++
b/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
@@ -103,4 +103,18 @@ public final class CssUtils
}
response.write( /);
}
+
+ /**
+* Get a standardized key for a CSS class.
+*
+* @param scope
+*scope of CSS class
+* @param facet
+*facet of CSS class
+* @return CSS key
+*/
+ public static String key(Class? scope, String facet)
+ {
+ return scope.getSimpleName() + .CSS. + facet;
+ }
}
http://git-wip-us.apache.org/repos/asf/wicket/blob/a73209be/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
index 562e6ed..7892fa7 100644
---
a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
+++
b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
@@ -16,9 +16,14 @@
*/
package org.apache.wicket.markup.html.form;
+import java.io.Serializable;
+
import org.apache.wicket.Component;
import org.apache.wicket.MarkupContainer;
+import org.apache.wicket.MetaDataKey;
import org.apache.wicket.WicketRuntimeException;
+import org.apache.wicket.ajax.AjaxRequestTarget;
+import org.apache.wicket.core.util.string.CssUtils;
import org.apache.wicket.markup.ComponentTag;
import org.apache.wicket.markup.MarkupStream;
import org.apache.wicket.markup.html.TransparentWebMarkupContainer;
@@ -36,11 +41,14 @@ import org.slf4j.LoggerFactory;
* liOutputs the {@code for} attribute with the value equivalent to the
markup id of the
* referenced form component/li
Re: Eclipse formatting, was: Martin's wicket pull request
yes, making it a workspace default messes up other projects... this way every time i import a project into the eclipse workspace i have to go and manually set the formatter on every module, which as you can imagine is not optimal -igor On Sat, Nov 9, 2013 at 1:40 PM, Martin Grigorov mgrigo...@apache.org wrote: But you have to import the xml just once, right ? It is not a big deal. Or the problem is that the xml messes up the other projects in your workspace ? On Sat, Nov 9, 2013 at 7:24 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: it is really frustrating that i have to do this manually now. before all i had to do was checkout the project and it was all set. wicket shares my workspace with other projects so the workspace-default is not going to work. can we drop the format def on wicket.apache.org and configure the maven plugin to set it up: http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html -igor On Fri, Nov 8, 2013 at 12:56 AM, Martin Grigorov mgrigo...@apache.org wrote: I'll test this soon. I'll update the docs for IDEA too if needed. On Thu, Nov 7, 2013 at 11:02 AM, Sven Meier s...@meiers.net wrote: Thanks, I've added a hint to the Idea instructions. Regards Sven On 11/06/2013 10:12 AM, Vojtěch Krása wrote: You should also specify values for Class count to use import with '*' and Names count to use static import with '*', since these values are not in EclipseCodeFormat.xml, and differs between Idea and Eclipse by default. V. 2013/11/6 Sven Meier s...@meiers.net Hi all, I removed all org.eclipse.jdt.[core|ui].prefs from the repo as discussed. EclipseCodeFormat.xml is updated now to our latest and greatest code format (which might differ between 6.x and master). Eclipse users should run mvn eclipse:eclipse to regenerate org.eclipse.jdt.core.prefs, then (re-)import EclipseCodeFormat.xml and use it as the default for your Wicket workspace(s). I've added a paragraph about the recommended Eclipse setup here: http://wicket.apache.org/learn/ides.html Could an Idea user please confirm that the format plugin ( http://plugins.jetbrains.com/plugin/6546) works as expected? Regards Sven On 11/05/2013 12:05 PM, Martin Grigorov wrote: On Tue, Nov 5, 2013 at 1:01 PM, Sven Meier s...@meiers.net wrote: IMHO we should have one authoritative source for our source format only. Whether this is EclipseCodeFormat.xml or something else can be dicussed on the other mail thread. Currently all org.eclipse.jdt.core.prefs have already diverged from EclipseCodeFormat.xml (perhaps they even differ between each other?), so I'm +1 to remove those settings from the repo as Martin has suggested. I can live with having to configure my Wicket workspace(s) once by importing EclipseCodeFormat.xml. So if no one objects, I'll update EclipseCodeFormat.xml from the current settings in wicket-core and apply Martin's patch afterwards. I'm +1. With the plugin that Rusi suggested in the other thread I can import EclipseCodeFormat.xml in Intellij IDEA and hopefully the formatting will be the same for all of us. Sven On 11/04/2013 04:42 PM, Martin Funk wrote: not quite if the org.eclipse.jdt.ui.prefs are not present eclipse will fall back to the workspace setting esp. formatter. The formatter profile as I described it in the attachment to https://issues.apache.org/jira/browse/WICKET-5399 has to be imported into the workspace once. If one has to follow more than one code formatting rulesets, than they have to be set for each project. The setting of the formatter profile will be written to org.eclipse.jdt.ui.prefs. mf Am 04.11.2013 um 16:25 schrieb Sven Meier s...@meiers.net: Ok, removing org.eclipse.jdt.core.prefs and org.eclipse.jdt.ui.prefs is easy. But without these files the Eclipse project settings (Java Code Style - Formatter) have to be adjusted manually for each Wicket module after mvn eclipse:eclipse :(. Sven On 11/04/2013 09:58 AM, Martin Grigorov wrote: Hi, Can someone of other Wicket code developers take a look at https://github.com/apache/wicket/pull/56 ? This is a pull request with some changes/updates to Eclipse's .settings/ (required by newer versions of Eclipse ?!). I don't use Eclipse and I cannot decide whether the PR is good or not. https://github.com/apache/wicket/pull/57/commits is another PR from Martin Funk that has some improvements to Wicket's unit tests that I'd like to merge but I cannot because it depends on PR 56. Additionally I'd like to ask all Eclipse users to disable the auto format the whole file feature. https://github.com/mafulafunk/wicket/commit/ 0aac81f393047865088864c6b299ce1e022ce1fa (part of PR 57) has such formatting changes that we agreed should
remove recently merged cdi 1.1 from 6.x
not sure why this was merged into 6.x but there are a lot of problems with this contribution as can be seen here [1]. i think this should be removed from at least the release branch. -igor [1] https://github.com/apache/wicket/pull/50#issuecomment-28063112
Re: Eclipse formatting, was: Martin's wicket pull request
it is really frustrating that i have to do this manually now. before all i had to do was checkout the project and it was all set. wicket shares my workspace with other projects so the workspace-default is not going to work. can we drop the format def on wicket.apache.org and configure the maven plugin to set it up: http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html -igor On Fri, Nov 8, 2013 at 12:56 AM, Martin Grigorov mgrigo...@apache.org wrote: I'll test this soon. I'll update the docs for IDEA too if needed. On Thu, Nov 7, 2013 at 11:02 AM, Sven Meier s...@meiers.net wrote: Thanks, I've added a hint to the Idea instructions. Regards Sven On 11/06/2013 10:12 AM, Vojtěch Krása wrote: You should also specify values for Class count to use import with '*' and Names count to use static import with '*', since these values are not in EclipseCodeFormat.xml, and differs between Idea and Eclipse by default. V. 2013/11/6 Sven Meier s...@meiers.net Hi all, I removed all org.eclipse.jdt.[core|ui].prefs from the repo as discussed. EclipseCodeFormat.xml is updated now to our latest and greatest code format (which might differ between 6.x and master). Eclipse users should run mvn eclipse:eclipse to regenerate org.eclipse.jdt.core.prefs, then (re-)import EclipseCodeFormat.xml and use it as the default for your Wicket workspace(s). I've added a paragraph about the recommended Eclipse setup here: http://wicket.apache.org/learn/ides.html Could an Idea user please confirm that the format plugin ( http://plugins.jetbrains.com/plugin/6546) works as expected? Regards Sven On 11/05/2013 12:05 PM, Martin Grigorov wrote: On Tue, Nov 5, 2013 at 1:01 PM, Sven Meier s...@meiers.net wrote: IMHO we should have one authoritative source for our source format only. Whether this is EclipseCodeFormat.xml or something else can be dicussed on the other mail thread. Currently all org.eclipse.jdt.core.prefs have already diverged from EclipseCodeFormat.xml (perhaps they even differ between each other?), so I'm +1 to remove those settings from the repo as Martin has suggested. I can live with having to configure my Wicket workspace(s) once by importing EclipseCodeFormat.xml. So if no one objects, I'll update EclipseCodeFormat.xml from the current settings in wicket-core and apply Martin's patch afterwards. I'm +1. With the plugin that Rusi suggested in the other thread I can import EclipseCodeFormat.xml in Intellij IDEA and hopefully the formatting will be the same for all of us. Sven On 11/04/2013 04:42 PM, Martin Funk wrote: not quite if the org.eclipse.jdt.ui.prefs are not present eclipse will fall back to the workspace setting esp. formatter. The formatter profile as I described it in the attachment to https://issues.apache.org/jira/browse/WICKET-5399 has to be imported into the workspace once. If one has to follow more than one code formatting rulesets, than they have to be set for each project. The setting of the formatter profile will be written to org.eclipse.jdt.ui.prefs. mf Am 04.11.2013 um 16:25 schrieb Sven Meier s...@meiers.net: Ok, removing org.eclipse.jdt.core.prefs and org.eclipse.jdt.ui.prefs is easy. But without these files the Eclipse project settings (Java Code Style - Formatter) have to be adjusted manually for each Wicket module after mvn eclipse:eclipse :(. Sven On 11/04/2013 09:58 AM, Martin Grigorov wrote: Hi, Can someone of other Wicket code developers take a look at https://github.com/apache/wicket/pull/56 ? This is a pull request with some changes/updates to Eclipse's .settings/ (required by newer versions of Eclipse ?!). I don't use Eclipse and I cannot decide whether the PR is good or not. https://github.com/apache/wicket/pull/57/commits is another PR from Martin Funk that has some improvements to Wicket's unit tests that I'd like to merge but I cannot because it depends on PR 56. Additionally I'd like to ask all Eclipse users to disable the auto format the whole file feature. https://github.com/mafulafunk/wicket/commit/ 0aac81f393047865088864c6b299ce1e022ce1fa (part of PR 57) has such formatting changes that we agreed should not be together with functional changes because they add a lot of noise that makes the code review and git bisect sesssions a lot harder. Lately I have seen such changes in Sven's commits as well. Please configure Eclipse to not auto format or to format only the changed code, but not the whole file. If this is not possible with Eclipse then you can use git add -p to select only the functional changes in one commit and all formatting related ones in another one. Thanks! On Sun, Nov 3, 2013 at 11:40 PM, mafulafunk g...@git.apache.org wrote: GitHub user mafulafunk opened a pull request: https://github.com/apache/wicket/pull/57 Assert that instance of Ok,
Re: [VOTE] Release Apache Wicket 6.11.0
+1 -igor On Fri, Sep 20, 2013 at 4:16 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.11.0 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.11.0 [ ] No, don't release Apache Wicket 6.11.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.11.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-084/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. == The signatures for the source release artifacts: apache-wicket-6.11.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) iEYEABECAAYFAlI8IfcACgkQJBX8W/xy/UWlDACfViIXxB2UgETmPI0fm46hVPJ8 bIsAn17Qm4+R3tNheaXrSciu/0ysnWq4 =sv15 -END PGP SIGNATURE- apache-wicket-6.11.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) iEYEABECAAYFAlI8IfcACgkQJBX8W/xy/UWu5gCfZ6yyKAxzZ6z1CGmkHTJyk244 gTAAn3B9DQPGJfhpYdf5iXWsg+1oLzMH =J9Rq -END PGP SIGNATURE- == Release Notes - Wicket - Version 6.11.0 ** Bug * [WICKET-5313] - Wrong HTML attribute used in SizeTagModifier (wicket-bean-validation) * [WICKET-5315] - PriorityHeaderItem+OnDomReadyHeaderItem has no priority in Ajax response * [WICKET-5316] - Wicket Atmosphere CouldNotLockPageException * [WICKET-5319] - CryptoMapper encrypts external URLs in ResourceReferences making the resources inaccessible * [WICKET-5322] - Source code link doesn't work at wicket-library.com * [WICKET-5325] - ComponentRenderer.renderComponent does not render markup for ListView * [WICKET-5329] - Required flag initialized too early in PropertyValidator * [WICKET-5332] - Autocomplete throws error when initialized in an AjaxLazyLoadPanel * [WICKET-5334] - KittenCaptcha example is broken in IE10 * [WICKET-5335] - After selecting a file MultiFileUploadField does not render properly input field * [WICKET-5339] - Broadcast.EXACT does not notify Behaviors of target Component * [WICKET-5343] - AutoCompleteTextField suggestions popup position is wrong when its container has scrollbar * [WICKET-5345] - Url.canonical() breaks when there are two consecutive parent segments followed by a normal segment * [WICKET-5348] - JavaDoc for IColumn#getSortProperty() in misleading ** Improvement * [WICKET-5327] - CryptoMapper: insecure default encryption provider * [WICKET-5331] - Make html5 form validation configurable * [WICKET-5333] - wicket-bean-validation french translation * [WICKET-5341] - JavaDoc for IFormValidator * [WICKET-5354] - Make ResourceBundles and related classes easier for extension
Re: Broadcast.EXACT with Behavior
i think it makes sense to be able to target a component as the most fine grained receiver and letting all behaviors check in and see if they want to respond. -igor On Wed, Sep 4, 2013 at 3:13 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, https://issues.apache.org/jira/browse/WICKET-5339 requests to be able to broadcast events to component's behaviors when the type is EXACT. I've attached a patch that allows to send event to a specific behavior: send(someBehavior, Broadcast.EXACT, event) The reporter of the ticket asks for a bit different behavior : send(someComponent, Broadcast.EXACT, event) to send the event to the provided component and all its behaviors. Do you agree with his request or we will need a new Broadcast type for this ?
Re: Broadcast.EXACT with Behavior
yep -igor On Wed, Sep 4, 2013 at 9:40 AM, Martin Grigorov mgrigo...@apache.org wrote: that is: just notify the component and all its behaviors? On Sep 4, 2013 6:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i think it makes sense to be able to target a component as the most fine grained receiver and letting all behaviors check in and see if they want to respond. -igor On Wed, Sep 4, 2013 at 3:13 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, https://issues.apache.org/jira/browse/WICKET-5339 requests to be able to broadcast events to component's behaviors when the type is EXACT. I've attached a patch that allows to send event to a specific behavior: send(someBehavior, Broadcast.EXACT, event) The reporter of the ticket asks for a bit different behavior : send(someComponent, Broadcast.EXACT, event) to send the event to the provided component and all its behaviors. Do you agree with his request or we will need a new Broadcast type for this ?
Re: [VOTE] Accept the Wicket Free Guide as a part of Apache Wicket
[x] Yes, accept the Wicket Free Guide to incorporate into our project -igor On Sun, Aug 18, 2013 at 7:48 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Andrea del Bene has granted us the ability to include the Wicket Free Guide into our project and to conclude the IP-clearance we need to actually vote to have the guide accepted. The donated file is available as an attachment at [1]. The grant actually lists the google code repository for reference, so perhaps that one is more up to date. So here's the vote (runs for 72 hours): [ ] Yes, accept the Wicket Free Guide to incorporate into our project [ ] No, don't accept the Wicket Free Guide Martijn PS. It is the intention to build a HTML version of the document using some easy to maintain format, but the specifics of the conversion is not part of this vote. [1]: https://issues.apache.org/jira/browse/WICKET-5321
Re: [4/4] git commit: WICKET-4997: render bookmarkable urls for bookmarkable pages (not stateless)
so what happens to the pages that are both bookmarkable and not?
public class EditCustomerPage {
public EditCustomerPage(PageParameters params) {
this(getEntity(params, customer));
}
public EditCustomerPage(IModelCustomer customer) {
...
}
}
what url will i get now when i say urlFor(new
EditCustomerPage(customerModel)) ?
-igor
On Tue, Aug 20, 2013 at 5:39 AM, Emond Papegaaij emond.papega...@topicus.nl
wrote:
On Monday 19 August 2013 17:32:45 Martin Grigorov wrote:
Hi Emond,
I think this change is OK.
Maybe we can improve it a bit by using
Application.get().getPageSettings().
getRecreateMountedPagesAfterExpiry() in the checks above ?
With the new check as you can see the produced urls contain the class
name.
Some users don't like this.
Application.get().getPageSettings().getRecreateMountedPagesAfterExpiry()
return true by default. If someone doesn't like the extra info in the
produced urls then she can disable it this way.
I've thought some more about this, and I think the current behavior is ok.
If
you don't want bookmarkable urls, but your page has a bookmarkable
constructor, you should override isBookmarkable. The setting is more
about request handling than it is about rendering urls. The reason the
pageparameters are not rendered in the url is, that they would otherwise
be rendered as query parameters, overriding other (such as form)
parameters.
I'll merge the branch somewhere tomorrow and forward port it to 7 if
nobody objects.
Best regards,
Emond
Re: [VOTE] Release Apache Wicket 6.10.0 - take 3
+1 -igor On Mon, Aug 12, 2013 at 3:12 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.10.0, take 3 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.10.0 [ ] No, don't release Apache Wicket 6.10.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.10.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-088/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Here are the signatures for the source release artifacts: GPG Signature for apache-wicket-6.10.0.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) iEYEABECAAYFAlIIsPsACgkQJBX8W/xy/UX6iQCbB+DDYOI6rOcTIgMsSGTo4cdW vEcAoMFTfrgQavlBlisFew94EKb7uDoT =Ydfr -END PGP SIGNATURE- GPG Signature for apache-wicket-6.10.0.zip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) iEYEABECAAYFAlIIsPsACgkQJBX8W/xy/UW7/QCfbP1OiUaGPg4rRURDEij8mvEL CHkAoJqichnpRXpgMgwQIFjMGyLYXY9G =ag93 -END PGP SIGNATURE-
Re: [VOTE] Release Apache Wicket 6.10.0 - take 2
+1 to release. On Fri, Aug 9, 2013 at 5:52 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.10.0, take 2 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.10.0 [ ] No, don't release Apache Wicket 6.10.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.10.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-082/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Here are the signatures for the source release artifacts: GPG Signature for apache-wicket-6.10.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) iEYEABECAAYFAlIE4zoACgkQJBX8W/xy/UWMZgCfXzGY5fNPnXFuUi4Vpk1NHNOP M54An3h7XpaFcYtv59y5BBS3nJl5+Ecx =+zNc -END PGP SIGNATURE- GPG Signature for apache-wicket-6.10.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) iEYEABECAAYFAlIE4zoACgkQJBX8W/xy/UWB9gCeN+fADb9kBDKVKqNnX8sUoE4w SjcAniatO06JEGPiVPcpvnnXpH8uQFgJ =t+/c -END PGP SIGNATURE-
Re: [Wicket7] History API support for navigable AJAX pages/components?
On Sun, Aug 4, 2013 at 1:16 AM, Martin Grigorov mgrigo...@apache.orgwrote: On Sat, Aug 3, 2013 at 5:23 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: * we need to have two different disk stores - one for ajax versions and one for non-ajax. this is to ensure that the original rendered page instance is not evicted if its render is followed by a lot of ajax activity. if it is evicted then any non-ajax callbacks will break. we already have wicket-ajax header/url var to distinguish the two kinds of requests. Let me explain some details for the rest who didn't need to read the data store code recently. When a non-ajax request modifies the component tree or a model then the page is marked as touched and as dirty. Touched means that it will be stored in the data store at the end of the request cycle. Dirty means that a new pageId is assigned. The pageId is the number you see in the url. When an ajax request does the same the page is marked as touched only. Since the composite key to read a page from the data store is sessionId+pageId the non-ajax request adds a new entry in the store, while the ajax request overrides the previous entry with the same pageId. So I agree, we will need to modify the current code to use either two stores or one store with key sessionId+pageId+ajaxId. At the moment I also think that second store would be simpler solution. * for ajax links we would need to ignore the version encoded in the callback params and pass it instead in an additional url param from client to server and set it in a javascript block so it makes it from server to client. I can see how this won't work in case of two simultaneous Ajax requests on different Ajax channels. The second request will wait on PageAccessSynchronizer and won't know about the new Ajax version/id. One way to solve this is to use optimistic update of Wicket.Ajax.pageId (the Ajax id). im not sure this will be a problem, just like it isnt a problem when users create two non-ajax requests to the same page. page id is 5 request 1 starts ?wicket-page-id=5 request 2 starts ?wicket-page-id=5 request 1 hits server. pulls page id 5, tweaks it, sends page id 6 back to client request 1 hits server. pulls page id 5, tweaks it, sends page id 7 back to client so both requests work against the same page instance but return different page ids. -igor once these two things are in place we can figure out which history library to work in. the ajax response will need a target.setHistoryPoint(true) or something like that so we know to enable history for specific requests/responses. ive done some work on shuttling the page id in back and forth in ajax requests: https://gist.github.com/ivaynberg/6146817 Great! -igor A friend of mine recommended me Google Closure library http://docs.closure-library.googlecode.com/git/class_goog_History.html for history management. It is used by many Google apps, but I haven't seen a new third party blog/article about it since very long time. On Thu, Aug 1, 2013 at 1:32 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Assuming that there is a good JS library for managing the history events, what should Wicket do ? I guess the best reliable solution is to store the pages as we do now for non-Ajax requests. The problem is that this way the disk store will be filled up much faster. The page will be stored only if it is dirty, i.e. if there are changes in its tree. On Fri, Jul 26, 2013 at 1:00 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Fri, Jul 26, 2013 at 12:48 PM, Hendy Irawan he...@soluvas.com wrote: I wonder if Wicket 6/7 has or planned for good history API support, i.e. navigable ajax updates a la Twitter/Facebook? It will be very useful if we extract use cases for this functionality. If not then I'd like to propose... It'd make Wicket not only very relevant but a breakthrough in a *post*-HTML5 world. [~mgrigorov] responded: Do you know of a good JS History library ? All I have tried have issues for different browsers. What I ever used is Backbone. Which is a great all around library. Snippet from http://backbonejs.org/#Router : blockquote Web applications often provide linkable, bookmarkable, shareable URLs for important locations in the app. Until recently, hash fragments (#page) were used to provide these permalinks, but with the arrival of the History API, it's now possible to use standard URLs (/page). Backbone.Router provides methods for routing client-side pages, and connecting them to actions and events. For browsers which don't yet support the History API, the Router handles graceful fallback and transparent translation to the fragment version of the URL. /blockquote
Re: [Wicket7] History API support for navigable AJAX pages/components?
* we need to have two different disk stores - one for ajax versions and one for non-ajax. this is to ensure that the original rendered page instance is not evicted if its render is followed by a lot of ajax activity. if it is evicted then any non-ajax callbacks will break. we already have wicket-ajax header/url var to distinguish the two kinds of requests. * for ajax links we would need to ignore the version encoded in the callback params and pass it instead in an additional url param from client to server and set it in a javascript block so it makes it from server to client. once these two things are in place we can figure out which history library to work in. the ajax response will need a target.setHistoryPoint(true) or something like that so we know to enable history for specific requests/responses. ive done some work on shuttling the page id in back and forth in ajax requests: https://gist.github.com/ivaynberg/6146817 -igor On Thu, Aug 1, 2013 at 1:32 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, Assuming that there is a good JS library for managing the history events, what should Wicket do ? I guess the best reliable solution is to store the pages as we do now for non-Ajax requests. The problem is that this way the disk store will be filled up much faster. The page will be stored only if it is dirty, i.e. if there are changes in its tree. On Fri, Jul 26, 2013 at 1:00 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Fri, Jul 26, 2013 at 12:48 PM, Hendy Irawan he...@soluvas.com wrote: I wonder if Wicket 6/7 has or planned for good history API support, i.e. navigable ajax updates a la Twitter/Facebook? It will be very useful if we extract use cases for this functionality. If not then I'd like to propose... It'd make Wicket not only very relevant but a breakthrough in a *post*-HTML5 world. [~mgrigorov] responded: Do you know of a good JS History library ? All I have tried have issues for different browsers. What I ever used is Backbone. Which is a great all around library. Snippet from http://backbonejs.org/#Router : blockquote Web applications often provide linkable, bookmarkable, shareable URLs for important locations in the app. Until recently, hash fragments (#page) were used to provide these permalinks, but with the arrival of the History API, it's now possible to use standard URLs (/page). Backbone.Router provides methods for routing client-side pages, and connecting them to actions and events. For browsers which don't yet support the History API, the Router handles graceful fallback and transparent translation to the fragment version of the URL. /blockquote Breadcrumb components would benefit greatly from History API support (and is probably its main use case). Although any parameterizable page will benefit from this. For example we're developing an analytics app so the parameters include date range, precision, and selected sections. Those can be encoded in URI. Although while selecting these things we immediately perform AJAX updates, with bookmarkable URI it'd great. So the page stays stateless instead of stateful. Just like how Google Analytics does it. History API libraries include: 1. http://backbonejs.org/#Router 2. https://github.com/browserstate/history.js/ The second one is one of those which I have tried and didn't like. It behaved differently than native History API. http://tkyk.github.io/jquery-history-plugin/ - this is the one we use in our app at the moment but its maintainer stopped supporting it. I also created a ticket at https://issues.apache.org/jira/browse/WICKET-5290 I think there is a ticket about this already. Hendy -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Ajax behavior for JavaScript event delegation
binding on document is fine, you just have to make sure your code is fast
in case you are binding to things like mousemove.
-igor
On Tue, Jul 30, 2013 at 1:31 AM, Martin Grigorov mgrigo...@apache.orgwrote:
On Fri, Jul 12, 2013 at 5:21 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
On Fri, Jul 12, 2013 at 1:50 AM, Martin Grigorov mgrigo...@apache.org
wrote:
On Fri, Jul 12, 2013 at 8:59 AM, Igor Vaynberg
igor.vaynb...@gmail.com
wrote:
On Thu, Jul 11, 2013 at 7:22 AM, Martin Grigorov
mgrigo...@apache.org
wrote:
On Thu, Jul 11, 2013 at 4:48 PM, Sven Meier s...@meiers.net
wrote:
Hi,
The idea with plain JS solution I cannot visualize in my head yet.
EventDelegatingBehavior is just a collector of JavaScript snippets.
The
actual magic runs in the browser: a custom bubbling of events and
delegation to the actual behavior.
It should be possible to do this plain with JavaScript:
public class DelegatingAjax implements IAjax {
public ajax(IHeaderResponse response, Component component,
AjaxRequestAttributes attributes) {
CharSequence ajaxAttributes =
renderAjaxAttributes(**component,
attributes);
response.render(**OnDomReadyHeaderItem.**forScript(Wicket.Event.***delegate*(
+ ajaxAttributes + ););
}
}
This would be page-global though.
This is an important detail!
I'll consult with my frontend colleagues but so far I don't see
problems.
For every delegated component we can set special CSS class, e.g.
'wicket-delegated'.
The binding will be: $(document).on('click', '.wicket-delegated',
function(event) {})
i.e. we will take advantage of jQuery delegation/live support.
This way even newly added items in the repeaters will be
automatically
supported.
this is partially on the right track, but there are still some
optimization that can be made.
first, the ajax attributes need to be moved into a data attribute that
is written out on the tag. the final output of attaching a onclick
ajax behavior to a tag should end up looking like this:
a wicket:id=ajaxlink
data-w-click=u/?0.foo:bar.ILinkListener/c/default/pd/true/
(we will need to figure out how to encode ajax attributes into a
string)
example:
a id=c23 data-w-attrs='{u:someUrl,m:post}' ...
$('#c23').data(w-attrs) === {u: someUrl, m: post}
This works for valid JSON, but it doesn't for the enhancement we use -
the
functions for the call listeners.
i did say we need to figure out a way to encode it right above the
example
:)
then you can have the one global listener:
$(document).on(click, function(e) {
The problem here is that using 'document' will make the things actually
slower.
We need to find a simple way to be able to bind on a parent component.
In Sven's example - a table with many cells the most appropriate
element
is
the table itself.
umm, why does it make things slower exactly? this has virtually no
overhead, events bubble up anyways...so where does the slowness come
from?
All the talks about the deprecation of jQuery#live() say that binding on
the document is not a good idea (performance wise).
If it is not possible to bind on a context element then I see no much
benefit.
-igor
In event-delegating-behavior branch I need to traverse the parent
components and their behaviors to be able to find the appropriate
parent.
So we win some performance in JS execution but lose some in Java :-/
var element=$(this), attrs=element.attr(data-w-click);
if (attrs!e.handledByWicket)
Wicket.Ajax.call(attrs);
e.handledByWicket=true; // if there are more handlers above, do
not double process the event - read below
}
}
the advantage here is that we only have one javascript listener that
needs to be registered.
however, there are a few disadvantages:
* event propagation options wont work anymore, because the event has
to propagate all the way to the document in order to trigger.
* some libraries block events. for example if there is a panel with an
ajax link inside a third party modal window. the modal window lib may
prevent any clicks from propagating out of itself, which means the
handler on the document will never see them.
we can sort of solve this by having a behavior that would write out
the listener above, but attached to the component not the document.
that way, if we look at my example with the panel inside the modal,
the user can add this behavior to the panel that will be in the modal
and still be able to capture the event.
this does, however, make troubleshooting more difficult. why didnt my
ajax event trigger? you will have to be a lot more aware about what
javascript you have in the dom.
i think a short
its that time of year again, 42lines is hiring java devs
the company i work for ( 42lines.net ) is growing and we are looking for a few good devs. about our approach: * we are a distributed usa-based company * everyone telecommutes either from home or a coworking space of your choice (paid for by the company) * we use a variation of agile methodology (daily scrums, iterations, peer code reviews, etc) * we offer a great compensation package tech stack: * wicket * jpa/hibernate/querydsl * cdi/weld * resteasy * jquery / jquery mobile what we want from you: * first and foremost you are smart and you know how to apply those smarts to writing code * you work on PST/EST time * you have a decent internet connection capable of skype * you understand (not just know) java and oop * you are comfortable in sql, hibernate, and wicket there is lots more info, including how to apply, available here: https://www.42lines.net/2013/07/24/now-hiring-one-new-software-engineer/ cheers, -igor ps, if you have a question please email me personally.
Re: Ajax behavior for JavaScript event delegation
On Thu, Jul 11, 2013 at 7:22 AM, Martin Grigorov mgrigo...@apache.org wrote:
On Thu, Jul 11, 2013 at 4:48 PM, Sven Meier s...@meiers.net wrote:
Hi,
The idea with plain JS solution I cannot visualize in my head yet.
EventDelegatingBehavior is just a collector of JavaScript snippets. The
actual magic runs in the browser: a custom bubbling of events and
delegation to the actual behavior.
It should be possible to do this plain with JavaScript:
public class DelegatingAjax implements IAjax {
public ajax(IHeaderResponse response, Component component,
AjaxRequestAttributes attributes) {
CharSequence ajaxAttributes = renderAjaxAttributes(**component,
attributes);
response.render(**OnDomReadyHeaderItem.**forScript(Wicket.Event.***delegate*(
+ ajaxAttributes + ););
}
}
This would be page-global though.
This is an important detail!
I'll consult with my frontend colleagues but so far I don't see problems.
For every delegated component we can set special CSS class, e.g.
'wicket-delegated'.
The binding will be: $(document).on('click', '.wicket-delegated',
function(event) {})
i.e. we will take advantage of jQuery delegation/live support.
This way even newly added items in the repeaters will be automatically
supported.
this is partially on the right track, but there are still some
optimization that can be made.
first, the ajax attributes need to be moved into a data attribute that
is written out on the tag. the final output of attaching a onclick
ajax behavior to a tag should end up looking like this:
a wicket:id=ajaxlink
data-w-click=u/?0.foo:bar.ILinkListener/c/default/pd/true/
(we will need to figure out how to encode ajax attributes into a string)
then you can have the one global listener:
$(document).on(click, function(e) {
var element=$(this), attrs=element.attr(data-w-click);
if (attrs!e.handledByWicket)
Wicket.Ajax.call(attrs);
e.handledByWicket=true; // if there are more handlers above, do
not double process the event - read below
}
}
the advantage here is that we only have one javascript listener that
needs to be registered.
however, there are a few disadvantages:
* event propagation options wont work anymore, because the event has
to propagate all the way to the document in order to trigger.
* some libraries block events. for example if there is a panel with an
ajax link inside a third party modal window. the modal window lib may
prevent any clicks from propagating out of itself, which means the
handler on the document will never see them.
we can sort of solve this by having a behavior that would write out
the listener above, but attached to the component not the document.
that way, if we look at my example with the panel inside the modal,
the user can add this behavior to the panel that will be in the modal
and still be able to capture the event.
this does, however, make troubleshooting more difficult. why didnt my
ajax event trigger? you will have to be a lot more aware about what
javascript you have in the dom.
i think a short term goal might be to move the ajax attributes into a
dom attribute and change our ajax code to simply say
Wicket.Ajax.bind(click, component234);
this will register the listener like above on the element directly. so
no delegation yet but cleaner javascript/html. also the browser doesnt
have to parse as much javascript, so it will be a bit speedier.
potentially we can collect ids to further optimize js size:
Wicket.Ajax.bind({click, [c34, c32], blur: [c22,c98]);
-igor
Sven
On 07/11/2013 03:40 PM, Martin Grigorov wrote:
On Thu, Jul 11, 2013 at 4:30 PM, Nick Pratt nbpr...@gmail.com wrote:
I think this is great - we have some tables now with a ton of JS events
on
the child elements. Just to clarify, will this make the rendered page
smaller since there will only be a single JS handler for the event for
the
container rather than N JS handlers?
At the moment all attributes for an inner element are preserved.
'e' (the event name), 'c' (the component markup id), pd (prevent default),
sp (stop propagation) can be removed because they are not really used.
But every inner element can have its own call listeners, form submitters
can also have custom settings ('f', 'sc', 'mp', 'm'), so I think they have
to be preserved.
If you look in #updateAjaxAttributes() for your ajax behaviors in your
table cells you will probably notice that they have their own attributes.
Making it switchable (I think how Sven suggested) would be an
improvement -
we could leave it off by default, but provide a simple switch on a
per-container (or per-app) basis that would allow the dev to choose.
Yes, it looks as an improvement.
Moving the current code to such implementation is easy.
The idea with plain JS solution I cannot visualize in my head yet.
Regards
Nick
On Thu, Jul 11, 2013 at 4:59 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
At
Re: Ajax behavior for JavaScript event delegation
On Fri, Jul 12, 2013 at 1:50 AM, Martin Grigorov mgrigo...@apache.org wrote:
On Fri, Jul 12, 2013 at 8:59 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
On Thu, Jul 11, 2013 at 7:22 AM, Martin Grigorov mgrigo...@apache.org
wrote:
On Thu, Jul 11, 2013 at 4:48 PM, Sven Meier s...@meiers.net wrote:
Hi,
The idea with plain JS solution I cannot visualize in my head yet.
EventDelegatingBehavior is just a collector of JavaScript snippets. The
actual magic runs in the browser: a custom bubbling of events and
delegation to the actual behavior.
It should be possible to do this plain with JavaScript:
public class DelegatingAjax implements IAjax {
public ajax(IHeaderResponse response, Component component,
AjaxRequestAttributes attributes) {
CharSequence ajaxAttributes = renderAjaxAttributes(**component,
attributes);
response.render(**OnDomReadyHeaderItem.**forScript(Wicket.Event.***delegate*(
+ ajaxAttributes + ););
}
}
This would be page-global though.
This is an important detail!
I'll consult with my frontend colleagues but so far I don't see problems.
For every delegated component we can set special CSS class, e.g.
'wicket-delegated'.
The binding will be: $(document).on('click', '.wicket-delegated',
function(event) {})
i.e. we will take advantage of jQuery delegation/live support.
This way even newly added items in the repeaters will be automatically
supported.
this is partially on the right track, but there are still some
optimization that can be made.
first, the ajax attributes need to be moved into a data attribute that
is written out on the tag. the final output of attaching a onclick
ajax behavior to a tag should end up looking like this:
a wicket:id=ajaxlink
data-w-click=u/?0.foo:bar.ILinkListener/c/default/pd/true/
(we will need to figure out how to encode ajax attributes into a string)
example:
a id=c23 data-w-attrs='{u:someUrl,m:post}' ...
$('#c23').data(w-attrs) === {u: someUrl, m: post}
This works for valid JSON, but it doesn't for the enhancement we use - the
functions for the call listeners.
i did say we need to figure out a way to encode it right above the example :)
then you can have the one global listener:
$(document).on(click, function(e) {
The problem here is that using 'document' will make the things actually
slower.
We need to find a simple way to be able to bind on a parent component.
In Sven's example - a table with many cells the most appropriate element is
the table itself.
umm, why does it make things slower exactly? this has virtually no
overhead, events bubble up anyways...so where does the slowness come
from?
-igor
In event-delegating-behavior branch I need to traverse the parent
components and their behaviors to be able to find the appropriate parent.
So we win some performance in JS execution but lose some in Java :-/
var element=$(this), attrs=element.attr(data-w-click);
if (attrs!e.handledByWicket)
Wicket.Ajax.call(attrs);
e.handledByWicket=true; // if there are more handlers above, do
not double process the event - read below
}
}
the advantage here is that we only have one javascript listener that
needs to be registered.
however, there are a few disadvantages:
* event propagation options wont work anymore, because the event has
to propagate all the way to the document in order to trigger.
* some libraries block events. for example if there is a panel with an
ajax link inside a third party modal window. the modal window lib may
prevent any clicks from propagating out of itself, which means the
handler on the document will never see them.
we can sort of solve this by having a behavior that would write out
the listener above, but attached to the component not the document.
that way, if we look at my example with the panel inside the modal,
the user can add this behavior to the panel that will be in the modal
and still be able to capture the event.
this does, however, make troubleshooting more difficult. why didnt my
ajax event trigger? you will have to be a lot more aware about what
javascript you have in the dom.
i think a short term goal might be to move the ajax attributes into a
dom attribute and change our ajax code to simply say
Wicket.Ajax.bind(click, component234);
see above (valid JSON)
we can enrich the DOM:
a ... onsuccess=someScript
but I think this is a step back to Wicket 1.5 days (ajax decorators on
strings, etc.)
this will register the listener like above on the element directly. so
no delegation yet but cleaner javascript/html. also the browser doesnt
have to parse as much javascript, so it will be a bit speedier.
potentially we can collect ids to further optimize js size:
Wicket.Ajax.bind({click, [c34, c32], blur: [c22,c98]);
-igor
Sven
On 07/11/2013 03:40 PM, Martin Grigorov wrote:
On Thu, Jul 11, 2013 at 4:30 PM, Nick Pratt
Re: git commit: WICKET-5071 use url as clientUrl
human history is not cryptographically hashed :( On Fri, Jul 12, 2013 at 6:36 AM, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Jul 12, 2013 at 4:33 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Fri, Jul 12, 2013 at 7:34 AM, Sven Meier s...@meiers.net wrote: Sorry, that was the wrong issue number in the clipboard. Changing the last commit message after push? Linus says don't to it: http://stackoverflow.com/**questions/457379/how-do-i-** edit-an-incorrect-commit-**message-in-git-ive-pushed/**457396#457396 http://stackoverflow.com/questions/457379/how-do-i-edit-an-incorrect-commit-message-in-git-ive-pushed/457396#457396 Besides, history rewriting is disallowed at ASF (for good reason). For SVN it is not disallowed. But I guess you mean just Git history, not human history :-)
Re: [VOTE] Release Apache Wicket 6.9.1 - fix for CDI issues
+1 to release -igor On Fri, Jul 5, 2013 at 9:17 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.9.1 This is a patch release for 6.9.0 because in 6.9.0 the CDI integration was broken for injecting into anonymous inner classes (see WICKET-5226). This release only contains (in addition to anything that was fixed in 6.9.0) the reversal of the particular commit that caused WICKET-5226 to disable injection into anonymous inner classes. Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.9.1 [ ] No, don't release Apache Wicket 6.9.1, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.9.1 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-106/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Here are the signatures for the source release artifacts: apache-wicket-6.9.1.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlHW674ACgkQJBX8W/xy/UXEmgCfSgYLE1GOcEKBhjk3O67vxB6K d60AoJHM3P+7W+qUvGl1zLIv375FGNj8 =P14U -END PGP SIGNATURE- apache-wicket-6.9.1.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlHW674ACgkQJBX8W/xy/UXdxQCfRqJKCVuIIVqTjssax5q1aNb7 Z5UAoJN196AuUUG1CYYNw+Lm1QSXv9Tc =yHaF -END PGP SIGNATURE-
Re: Michael Mosmann is a committer and PMC member!
welcome! -igor On Mon, Jul 1, 2013 at 2:51 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Please welcome Michael Mosmann as our newest addition to the Wicket team! Michael has been a long time contributor to Wicket, and even wrote a book on the subject. His day to day work keeps him busy with Wicket so we are very happy that Michael wanted to join our band of merry men! Martijn
Re: RestartResponseAtInterceptPageException#continueToOriginalDestination
go for it On Fri, Jun 28, 2013 at 11:43 PM, martin.dilger martin.dil...@googlemail.com wrote: That sounds like a pretty good thing. Should I file a Ticket? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-continueToOriginalDestination-tp4659907p4659920.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: RestartResponseAtInterceptPageException#continueToOriginalDestination
if your form is not backed by wicket i do not think you should count
on being within a wicket request cycle...
-igor
On Fri, Jun 28, 2013 at 7:43 AM, martin.dilger
martin.dil...@googlemail.com wrote:
Hi Martin,
image the typical SignIn-Functionality.
You have a SignInPanel which only shows the necessary Form Components.
Then you have some sort of Bean like SignInActionXYZ, which has in its
perform method the typical flow:
if(signInSuccesful()){
//well, check if there was some interception
RestartResponseAtInterceptPageException.continueToOriginalDestination()
//no, ok, do some Other stuff
}
Of coure you are right, in many cases (but not all) it is valid and good to
work from Component.
BUT in some cases it is ok and good, to have this Possibility from other
Classes.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-continueToOriginalDestination-tp4659907p4659909.html
Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.
Re: RestartResponseAtInterceptPageException#continueToOriginalDestination
this does not seem cluttered to me:
1 add(new Button(login) {
2 onsubmit() {
3 if (authenticator.login(username, password)) {
4continueToOriginalDestination();
5setResponsePage(UserHome.class);
6} else {
7 error(login failed);
8 }
9 }
do you expect to call setResponsePage(UserHome.class) from your action
as well, in case there is no intercept page?
do you expect to call error() from that action?
it seems to me that lines 4,5, and 7 all belong in your UI-layer and
should not be in a layer below...my two cents.
-igor
On Fri, Jun 28, 2013 at 8:29 AM, martin.dilger
martin.dil...@googlemail.com wrote:
Maybe an addition, dont get me wrong, everything is possible the way it is.
I´m just asking for convenience to declutter some of my components.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-continueToOriginalDestination-tp4659907p4659913.html
Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.
Re: RestartResponseAtInterceptPageException#continueToOriginalDestination
i think the middle ground is to add RequestCycle#continueToOriginalDestination(). that way its your job to make sure you actually have a valid wicket scope before attempting to call that method. -igor On Fri, Jun 28, 2013 at 11:49 AM, martin.dilger martin.dil...@googlemail.com wrote: Hi Igor, We dont talk about different layers. Even if my class would be named SignInAction, it belongs to the UI-Layer and thats the only valid place, thats completely right. Could be a Spring Bean for example, that throws some use case specific authentication - exceptions (AuthenticationFailed, InvalidCredentials, UsernameNotFound... ) that are handled at a central place - RequestCycleListener for example. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-continueToOriginalDestination-tp4659907p4659915.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Wicket 7 status
On Wed, Jun 26, 2013 at 4:20 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi all, I'd like to discuss where we are with Wicket 7 and what to do next. At the moment there are just 3https://issues.apache.org/jira/issues/?jql=project%20%3D%20WICKET%20AND%20fixVersion%20%3D%20%227.0.0%22%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20ORDER%20BY%20created%20DESC%2C%20summary%20ASC tickets with Fix Version 7.0.0. One https://issues.apache.org/jira/browse/WICKET-5172 of them is about adding a link for the javadoc at http://wicket.apache.org. Trivial. Another https://issues.apache.org/jira/browse/WICKET-4951 is about CDI-1.1. John Sarman is helping here. Thanks! i havent had time to keep up with this, be sure we do not lock ourselves into weld... And the last https://issues.apache.org/jira/browse/WICKET-5184 one is about the signature of AbstractTree/Model.ofSet(). I don't see a good solution here, but I have provided a workaround. In the roadmap page there is also: Refactor checkgroup/radiogroup to make them non componentshttps://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Refactorcheckgroup%2Fradiogrouptomakethemnoncomponents. - @Igor: do you want to work yourself on this ? Otherwise please give more details how you imagine the new way. im fine with someone else taking this one. the basic idea is to make CheckGroup and RadioGroup non-components because in a lot of cases it is inconvenient to have them wrap some sections. eg when you have two check groups you have to put one inside the other, which is non-intuitive. so the groups are linked by the instance of CheckGroup and RadioGroup objects which can take care of generating unique ids, etc. so instead of code like this: RadioGroup group=new RadioGroup(); add(group); group.add(new Radio()); we would have RadioGroup group=new RadioGroup(); add(new Radio(id, group)); makes sense? -igor Make CSS class strings used in the framework configurablehttps://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Makecssclassstringsusedintheframeworkconfigurable - this one is clear. If there are no objections then I'll pick it soon (unless someone else does it before me). I'm going to investigate few tickets about bookmarkable mappers (MountMapper, MountedMapper, PackageMapper and ResourceMapper) and their handling of named parameters in the path/segments. Unless someone has more ideas what can be improved for Wicket 7 I think we are pretty close to be feature complete and we can release a milestone or release candidate. I'd like to thank Cedric Gatay, Michael Mossman, Andrea Del Bene and John Sarman for their help so far!
Re: Wicket 7 status
i may be able to help here. ive recently written a descent polling panel we use to execute long-running sql queries. its not async in the sense that it does not work via servlet 3 async requests - it polls with ajax. but, unlike lazyloadpanel we have now this one doesnt block access to the page, and has some rudimentary job management. i will see if i can open source it... -igor On Wed, Jun 26, 2013 at 9:03 AM, Nick Pratt nbpr...@gmail.com wrote: If you're asking what else could go in, better async support for long running tasks would be a great addition - perhaps some simple job management. There are a couple of examples out on the web, and we built our own a while back, but Id rather the framework provided such support (with associated front end updates / notifications on job completion) N On Wed, Jun 26, 2013 at 7:20 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi all, I'd like to discuss where we are with Wicket 7 and what to do next. At the moment there are just 3 https://issues.apache.org/jira/issues/?jql=project%20%3D%20WICKET%20AND%20fixVersion%20%3D%20%227.0.0%22%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20ORDER%20BY%20created%20DESC%2C%20summary%20ASC tickets with Fix Version 7.0.0. One https://issues.apache.org/jira/browse/WICKET-5172 of them is about adding a link for the javadoc at http://wicket.apache.org. Trivial. Another https://issues.apache.org/jira/browse/WICKET-4951 is about CDI-1.1. John Sarman is helping here. Thanks! And the last https://issues.apache.org/jira/browse/WICKET-5184 one is about the signature of AbstractTree/Model.ofSet(). I don't see a good solution here, but I have provided a workaround. In the roadmap page there is also: Refactor checkgroup/radiogroup to make them non components https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Refactorcheckgroup%2Fradiogrouptomakethemnoncomponents . - @Igor: do you want to work yourself on this ? Otherwise please give more details how you imagine the new way. Make CSS class strings used in the framework configurable https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Makecssclassstringsusedintheframeworkconfigurable - this one is clear. If there are no objections then I'll pick it soon (unless someone else does it before me). I'm going to investigate few tickets about bookmarkable mappers (MountMapper, MountedMapper, PackageMapper and ResourceMapper) and their handling of named parameters in the path/segments. Unless someone has more ideas what can be improved for Wicket 7 I think we are pretty close to be feature complete and we can release a milestone or release candidate. I'd like to thank Cedric Gatay, Michael Mossman, Andrea Del Bene and John Sarman for their help so far!
Re: WicketTester CDI and WicketApplication
we use a custom solution at $dayjob, but its so tired to our environment it would be hard to repackage. maybe we can use this: http://jglue.org/cdi-unit/ but i havent tried it yet. -igor On Mon, Jun 10, 2013 at 1:49 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi Igor Emond, At the moment we don't have any tests for wicket-cdi module. Do you use something similar for testing your application(s) like what Cedric suggested in users@ or you use something with mocks like Spring's ApplicationContextMock that we have. With Guice it is also very easy to use a Module with bindings needed only for the particular test. There is no need to emulate application container to run your Spring/Guice tests. I doubt that Arquilian is the only option for testing CDI based apps. But I don't have experience with CDI myself. I'll be glad to add some tests for wicket-cdi(-1.1) module. -- Forwarded message -- From: Cedric Gatay gata...@gmail.com Date: Sun, Jun 2, 2013 at 8:57 PM Subject: Re: WicketTester CDI and WicketApplication To: us...@wicket.apache.org Hi David, you can have a look at the base CDI enabled test class we're using at code-troopers in the following gist : https://gist.github.com/CedricGatay/5694293 Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Sat, Jun 1, 2013 at 6:15 PM, David Beer david.m.b...@gmail.com wrote: Hi Cedric Thanks for the reply I will take a look at Arquillian and see how I can use it. Any guides are helpful especially when used with wicket. Thanks David On 01/06/13 16:20, Cedric Gatay wrote: Hi, I usually use Arquillian to deploy a CDI context in my tests which require injection to work (often it happens for pages tests). When testing individual components it is easy to manually inject references (either via package visibility or via PowerMock's Whitebox for instance). Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_**Gatayhttp://twitter.com/Cedric_Gatay ) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Sat, Jun 1, 2013 at 5:13 PM, David Beer david.m.b...@gmail.com wrote: Hi All I am having difficulty finding information on how I can create a CDI context for use in my tests. Is there some kind of way of creating a mock cdi environment for testing. Currently my tests fail trying to retrieve the CDI Bean Manager as this is normally controlled by the Web Application Container. Do I need to create a mock Web Application class which simulates a dummy Bean Manager? Is there any guides specific to Wicket? Thanks David --** --**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.orghttp://apache.org users-unsubscribe@**wicket.apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketTester CDI and WicketApplication
yes, and they make my eyes bleed :) -igor On Mon, Jun 17, 2013 at 1:26 PM, Martin Grigorov mgrigo...@apache.org wrote: Thanks! I'll take a look. You may have noticed that now there are JS functional tests for the CDI pages in wicket-examples too On Mon, Jun 17, 2013 at 11:08 PM, Igor Vaynberg ivaynb...@apache.orgwrote: we use a custom solution at $dayjob, but its so tired to our environment it would be hard to repackage. maybe we can use this: http://jglue.org/cdi-unit/ but i havent tried it yet. -igor On Mon, Jun 10, 2013 at 1:49 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi Igor Emond, At the moment we don't have any tests for wicket-cdi module. Do you use something similar for testing your application(s) like what Cedric suggested in users@ or you use something with mocks like Spring's ApplicationContextMock that we have. With Guice it is also very easy to use a Module with bindings needed only for the particular test. There is no need to emulate application container to run your Spring/Guice tests. I doubt that Arquilian is the only option for testing CDI based apps. But I don't have experience with CDI myself. I'll be glad to add some tests for wicket-cdi(-1.1) module. -- Forwarded message -- From: Cedric Gatay gata...@gmail.com Date: Sun, Jun 2, 2013 at 8:57 PM Subject: Re: WicketTester CDI and WicketApplication To: us...@wicket.apache.org Hi David, you can have a look at the base CDI enabled test class we're using at code-troopers in the following gist : https://gist.github.com/CedricGatay/5694293 Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Sat, Jun 1, 2013 at 6:15 PM, David Beer david.m.b...@gmail.com wrote: Hi Cedric Thanks for the reply I will take a look at Arquillian and see how I can use it. Any guides are helpful especially when used with wicket. Thanks David On 01/06/13 16:20, Cedric Gatay wrote: Hi, I usually use Arquillian to deploy a CDI context in my tests which require injection to work (often it happens for pages tests). When testing individual components it is easy to manually inject references (either via package visibility or via PowerMock's Whitebox for instance). Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_**Gatayhttp://twitter.com/Cedric_Gatay ) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Sat, Jun 1, 2013 at 5:13 PM, David Beer david.m.b...@gmail.com wrote: Hi All I am having difficulty finding information on how I can create a CDI context for use in my tests. Is there some kind of way of creating a mock cdi environment for testing. Currently my tests fail trying to retrieve the CDI Bean Manager as this is normally controlled by the Web Application Container. Do I need to create a mock Web Application class which simulates a dummy Bean Manager? Is there any guides specific to Wicket? Thanks David --** --**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.orghttp://apache.org users-unsubscribe@**wicket.apache.org users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Deprecating wicket:enclosure
even though wicket:enclosure doesnt work for every single situation out there it is still immensely useful because it works for 90% use cases out there. so -1 to deprecate. in fact, the reason we introduced it in the first place was because adding EnclosureContainer-like components in code was a pain. -igor
Re: Deprecating wicket:enclosure
these things are usually added after the fact, which means you have to add the container then go find all the children that should be added into it and change the parent of the add() calls. just like any time when you have to insert a container into existing hierarchy, but one of the primary usecases is to do what the enclosures do. having these containers in code adds a lot of noise. some uis are prone to having a lot of these. eg when you hide a form component you also want to hide some static help markup. without enclosures this means having an extra container for each form component with dynamic visibility. enclosures were born as a practical solution to these frustrating problems. if they are broken they need to be fixed, but removing them is not an option i dont think. -igor On Mon, Jun 17, 2013 at 10:32 PM, Martin Grigorov mgrigo...@apache.org wrote: By pain what do you mean ? More code to write or some other problems ? What to do with these tickets ? I can close all but one as duplicates and link them ... On Tue, Jun 18, 2013 at 3:12 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: even though wicket:enclosure doesnt work for every single situation out there it is still immensely useful because it works for 90% use cases out there. so -1 to deprecate. in fact, the reason we introduced it in the first place was because adding EnclosureContainer-like components in code was a pain. -igor
Re: Generified Component
On Thu, May 30, 2013 at 12:37 PM, tetsuo ronald.tet...@gmail.com wrote:
-1000!
This will be horrible! Even with the current API, most generics I have to
declare in my code don't add anything to type safety. For example:
while i am also not a fan of having component generified i do believe
the example below is a bit contrived.
first, i hope most people do not use PropertyModels because they are
not compile-time-safe. there are plenty of project that implement
compile-time-safe models, personally i prefer
https://github.com/42Lines/metagen to using proxy-based solutions.
further, i hope even less people use compound property models. they
are even more unsafe then property models and make your code even more
fragile. i would hate to refactor code that uses CPMs.
add(new FormPerson(form, new CompoundPropertyModelPerson(new
PropertyModelPerson(this, person)))
.add(new TextFieldString(name))
.add(new TextFieldInteger(age))
.add(new TextFieldDouble(salary))
.add(new Button(save, new PropertyModelPerson(this,person)){
public void onSubmit() {
repository.save((Person)getForm().getDefaultModelObject());
}
});
In my experience, this kind of code is fairly common in Wicket
applications. Every form component must be declared with a type, but none
has *any* kind of type safety gain.
but how often do you declare a form component without adding any
validators to it? the generic type of component also makes sure you
add the correct validator. for example it wont let you add a validator
that expects strings to a component that produces integers.
also, not sure why you are replicating the model in Button. first, the
Button uses its model to fill its label; secondly, in real code the
model would be in a final var or field that things like onsubmit can
access easily.
-igor
- The property model uses reflection, so its type can't be verified by the
compiler (this.person could be anything, not just a Person).
- Generics will guarantee that the form model will be of type Person, but
since it's all declared inline, and the real model isn't verifiable, it
just adds lots of verbosity without any real gain.
- Most form components use the implicit model, that also uses reflection,
and also can't verify the actual type of the underlying property, at
compilation time. Even in runtime, *the type information is lost due erasure
*, so it can't use it to do any additional verification.
*- Worse, you can even declare the name TextField as Integer or
Double (while maintaining the 'text' attribute as String), and since
there is no type information at runtime, it doesn't matter. It won't even
throw an exception (it will just work normally).* In this case, the type
declaration is simply a lie.
Just pain, no gain. In my code, I sometimes just add a @SuppressWarnings(
rawtypes) to the class, and remove all useless generic type declarations.
If everything will be required to declare them, I will have do it more
frequently.
That said, repeater components benefit greatly from generics. So do custom
models, validators, and converters. Or the rare cases that we explicitly
declare the form component model. But forcing everything to be
generic-typed will just make Wicket extremely verbose to use, with very
little benefit.
On Thu, May 30, 2013 at 4:00 AM, Martin Grigorov mgrigo...@apache.orgwrote:
Hi,
I just pushed some initial work for [1] and [2] in
branch generified-component-4930.
So far it doesn't look nice.
The added generics break somehow setMetaData/getMetaData methods - you can
see compilation errors in Component and Page classes. I think it is caused
by the anonymous instance of MetaDataKey ( new MetaDataKeyT(type) {} ).
Also the visit*** methods do not compile at the moment, but even if we find
a way to fix their signature I think writing a visitor will become quite
cumbersome.
At the moment we have IVisitor
and org.apache.wicket.util.iterator.AbstractHierarchyIterator which do the
same job. The Iterator API is supposed to be simpler to write for the
users. Maybe we can drop IVisitor ... ?!
I'd like to ask for help with this task. It is supposed to be the biggest
API break for Wicket 7.0. My current feeling is that the end result won't
be very pleasant for the user-land code.
For example the application code will have to do something like:
WebMarkupContainerVoid wmc = new WebMarkupContainer(id)
It is not that much but we have to decide whether we want it.
But first let's try to fix the compilation problems.
1. https://issues.apache.org/jira/browse/WICKET-4930 (Add generics to
o.a.w.Component)
2.
https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Genericsfororg.apache.wicket.Component
Re: ISessionListener#onUnbound(String)
+1
-igor
On Wed, May 29, 2013 at 1:29 PM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
Do you think the following improvement should be made for Wicket 7:
diff --git i/wicket-core/src/main/java/org/apache/wicket/Application.java
w/wicket-core/src/main/java/org/apache/wicket/Application.java
index 98a7145..bb39537 100644
--- i/wicket-core/src/main/java/org/apache/wicket/Application.java
+++ w/wicket-core/src/main/java/org/apache/wicket/Application.java
@@ -478,6 +478,8 @@ public abstract class Application implements
UnboundListener, IEventSink
public void sessionUnbound(final String sessionId)
{
internalGetPageManager().sessionExpired(sessionId);
+
+ getSessionListeners().onUnbound(sessionId);
}
diff --git
i/wicket-core/src/main/java/org/apache/wicket/ISessionListener.java
w/wicket-core/src/main/java/org/apache/wicket/ISessionListener.java
index 73afbbf..b731f52 100644
--- i/wicket-core/src/main/java/org/apache/wicket/ISessionListener.java
+++ w/wicket-core/src/main/java/org/apache/wicket/ISessionListener.java
@@ -29,4 +29,12 @@ public interface ISessionListener
* @param session
*/
void onCreated(Session session);
+
+ /**
+* Informs the listener that session with specific id has been
unbound.
+*
+* @param sessionId
+* the id of the unbound session
+*/
+ void onUnbound(String sessionId);
}
It is a minor improvement to make ISessionListener more consistent with
IApplicationListener - one method for create and another for destroy.
Re: [VOTE] Release Apache Wicket 6.8.0
+1 -igor On Fri, May 17, 2013 at 11:59 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.8.0 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.8.0 [ ] No, don't release Apache Wicket 6.8.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.8.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-010/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Here are the signatures for the source release artifacts: GPG Signature for apache-wicket-6.8.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlGWcf8ACgkQJBX8W/xy/UUO0ACgznXMAQlFl3OcNHJ4+hoSji+V 5h8AnRwunnOUoldX6B4yF/wZSTzO1Jbx =K3Xg -END PGP SIGNATURE- GPG Signature for apache-wicket-6.8.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlGWcf8ACgkQJBX8W/xy/UVfYQCeJiDa/HO0V0rBfjIbrjQVTbFg D7UAn0i+ApWNIfnSJApA2KabJ5zyzhiV =kFsb -END PGP SIGNATURE- Change log: Release Notes - Wicket - Version 6.8.0 ** Sub-task * [WICKET-5162] - InlineEnclosure markup id could collide in the final page markup * [WICKET-5185] - JavaScript text is spread in several DOM text nodes ** Bug * [WICKET-5083] - Page#isPageStateless() may return wrong value * [WICKET-5103] - Wicket session id not up to date when container changes session id * [WICKET-5119] - PopupSettings IE8 - dosen't work second time a link is clicked. * [WICKET-5140] - InterceptData never gets cleared from session after continueToOriginalDestination is called and another page is requested afterwards * [WICKET-5142] - Generating invalid JavaScript for ajax update * [WICKET-5145] - do not post an Atmosphere event if the filtered subscription set is empty * [WICKET-5146] - Application not destroyed if WicketFilter#init() fails * [WICKET-5147] - WicketTester MockHttpRequest.getCookies very slow / OutOfMemory * [WICKET-5149] - PageRequestHandlerTracker doesn't track resolves of handlers caused by Exception * [WICKET-5154] - Positioning of autocomplete popup does not take into account borders * [WICKET-5157] - URL query parameter values containing equals sign get cut off * [WICKET-5163] - Implementing markup loading by extending ResourceStreamLocator produces errors with inherited markup * [WICKET-5176] - StringResourceModel doesn't detach model in some cases * [WICKET-5178] - StopPropagation functionality on link is broken * [WICKET-5181] - Problem with OnEventHeaderItem and Wicket.Event.add * [WICKET-5187] - Unknown tag name with Wicket namespace: 'panel' * [WICKET-5191] - Session is created unnecessarily ** Improvement * [WICKET-5143] - Create an interface for the roles replacing the current Roles class * [WICKET-5150] - Log additional info when FormComponent fails in updateCollectionModel * [WICKET-5158] - Ignore missing Page in StatelessForm#process() * [WICKET-5159] - Replace usage of JavaScript eval() with plain JS in headed contribution decoding * [WICKET-5160] - Throttle the animation in DebugWindow when there are many errors * [WICKET-5161] - The url gets longer when using StatelessForm with GET method * [WICKET-5166] - Relax the requirements for using FilteringHeaderResponse * [WICKET-5186] - Use arrays instead of String concatenation in JavaScript for better performance * [WICKET-5188] - Use a separate logger for the extra information logged in RequestCycle#onException() * [WICKET-5189] - preregister known wicket tag names ** Task * [WICKET-5169] - Create BuildBot config for wicket-6.x branch
Re: Handling user-specific timezones
On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov mgrigo...@apache.org wrote:
On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
we should write components that work with multiple types.
But this will mean that we will have to re-write it to javax.time for the
version of Wicket that will use JDK 8.
Your suggestion doesn't sound attractive to me anymore :-/
no, it just means we *add* handling for javax.time types when they
become available.
for example this is what code of a DateLabel might look like:
@Override
public void onComponentTagBody(MarkupStream markupStream, ComponentTag
openTag) {
String body = ;
Object date = getDefaultModelObject();
if (date != null) {
if (date instanceof ReadablePartial) { body = ... }
else if (date instanceof ReadableInstant) { body = ... }
else if (date instanceof Date) { body = ...}
else if (date instanceof Timestamp) { body = ... }
else {
throw new IllegalStateException(Object of type : +
date.getClass().getName() + is not supported);
}
}
replaceComponentTagBody(markupStream, openTag, body);
}
we are not using a converter because DateLabel carries a format string
as a property.
such a component is convenient because you dont need to worry if you
are using it with older api that has Date or a newer one that has Joda
we cannot go solely on threeten because version 1.0 is not coming
until jdk8 and only with jdk8.
I don't get the only with jdk8 part.
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.threeten%22%20AND%20a%3A%22threetenbp%22
threetenbp is the backport for JDK 7. It is version 0.8.1 at the moment so
API changes may be expected, but it can be used now.
right. but can we have a production version with a pre 1.0 dependency?
as far as semver goes pre 1.0 is the wild west - anything can change.
i think thats a bit dicy. and even if we do that, we should still
suport java.util.Date and java.sql.Timestamp. these types are in wide
use currently and will be for a while.
-igor
-igor
On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Dan,
I have no much experience with this matter so I cannot help much.
The new Joda-Time is http://threeten.github.io/
Question to other devs: do you think it is OK to migrate wicket-datetime
module to JDK 1.7 version of ThreeTen for Wicket 7 ?
I find this task interesting to me so I'll gladly work on it if other
devs
think that the API break is worth it.
On Thu, May 9, 2013 at 12:46 AM, Dan Retzlaff dretzl...@gmail.com
wrote:
Hi all,
I'd like to know what conventions you've established for your sites that
deal with users in many time zones.
Do you simply replace the converters (Date, SqlDate, SqlTime,
SqlTimestamp)?
Do you avoid MessageFormats in StringResourceModels? (I don't see a way
to
configure its MessageFormat.)
We currently bypass this stuff and do our formatting with application
utility methods, and adapting input into users' timezones as manual
steps,
e.g. with Joda-Time's DateTime#withZoneRetainFields().
I'd like to sweep this stuff under the rug with some application-level
configuration, e.g. of converters. But before I embark, I was hoping to
hear from someone who's already gone on this journey.
And related: maybe you have some golden rules time zone handling to
share?
A couple of mine are:
1. Avoid date types in SQL tables because it's hard to correctly
compare
to now across timezones.
2. Anything that shifts millis to adjust for timezones is a red flag
(including the aforementioned #withZoneRetainFields() sadly).
3. java.util.Date is evil and you should avoid it whenever possible.
Calendar is marginally better, but Joda-Time is the way to go.
Thanks,
Dan
--
Martin Grigorov
Wicket Training Consulting
http://jWeekend.com http://jweekend.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
Wicket Training Consulting
http://jWeekend.com http://jweekend.com/
Re: Handling user-specific timezones
On Thu, May 9, 2013 at 1:12 PM, Martin Grigorov mgrigo...@apache.org wrote:
On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov mgrigo...@apache.org
wrote:
On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
we should write components that work with multiple types.
But this will mean that we will have to re-write it to javax.time for the
version of Wicket that will use JDK 8.
Your suggestion doesn't sound attractive to me anymore :-/
no, it just means we *add* handling for javax.time types when they
become available.
having support for both joda and javax.time sounds a bit too much
additionally https://issues.apache.org/jira/browse/WICKET-466 is since
2007. Everyone knows the issues with j.u.Date/Calendar.
The fact that JDK development is slow doesn't mean that we should be slow
too. It is 6 years since this request has been made. Isn't it time to drop
support for j.u.Date/Calendar ?
there are a lot of issues with j.u.Date. no one here is going to
dispute that. but, even with all these issues it is still a widely
used class, and will continue to be long after jdk8 is released.
i do not care if internally wicket used joda or anything else to
represent time. we can encapsulate whatever mechanism we want. but,
externally we should support j.u.Date as well as joda, etc.
for example, jpa codebases which need to be portable or jee apps can
only map j.u/s.Date and j.s.Timestamp because those are the only
temporal types jpa has support for. if we do not support these
directly then the users will either have to convert their domain to
perform conversion in getters/setters or use a model adapter to bind
to those types. either way, its a hassle, especially since its really
easy for us to support these types directly.
-igor
for example this is what code of a DateLabel might look like:
@Override
public void onComponentTagBody(MarkupStream markupStream, ComponentTag
openTag) {
String body = ;
Object date = getDefaultModelObject();
if (date != null) {
if (date instanceof ReadablePartial) { body = ... }
else if (date instanceof ReadableInstant) { body = ... }
else if (date instanceof Date) { body = ...}
else if (date instanceof Timestamp) { body = ... }
else {
throw new IllegalStateException(Object of type : +
date.getClass().getName() + is not supported);
}
}
replaceComponentTagBody(markupStream, openTag, body);
}
we are not using a converter because DateLabel carries a format string
as a property.
such a component is convenient because you dont need to worry if you
are using it with older api that has Date or a newer one that has Joda
we cannot go solely on threeten because version 1.0 is not coming
until jdk8 and only with jdk8.
I don't get the only with jdk8 part.
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.threeten%22%20AND%20a%3A%22threetenbp%22
threetenbp is the backport for JDK 7. It is version 0.8.1 at the moment
so
API changes may be expected, but it can be used now.
right. but can we have a production version with a pre 1.0 dependency?
as far as semver goes pre 1.0 is the wild west - anything can change.
i think thats a bit dicy. and even if we do that, we should still
suport java.util.Date and java.sql.Timestamp. these types are in wide
use currently and will be for a while.
-igor
-igor
On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Dan,
I have no much experience with this matter so I cannot help much.
The new Joda-Time is http://threeten.github.io/
Question to other devs: do you think it is OK to migrate
wicket-datetime
module to JDK 1.7 version of ThreeTen for Wicket 7 ?
I find this task interesting to me so I'll gladly work on it if other
devs
think that the API break is worth it.
On Thu, May 9, 2013 at 12:46 AM, Dan Retzlaff dretzl...@gmail.com
wrote:
Hi all,
I'd like to know what conventions you've established for your sites
that
deal with users in many time zones.
Do you simply replace the converters (Date, SqlDate, SqlTime,
SqlTimestamp)?
Do you avoid MessageFormats in StringResourceModels? (I don't see a
way
to
configure its MessageFormat.)
We currently bypass this stuff and do our formatting with application
utility methods, and adapting input into users' timezones as manual
steps,
e.g. with Joda-Time's DateTime#withZoneRetainFields().
I'd like to sweep this stuff under the rug with some
application-level
configuration, e.g. of converters. But before I embark, I was hoping
to
hear from someone who's already gone on this journey.
And related: maybe you have some golden rules time zone handling to
share?
A couple of mine are:
1. Avoid date types in SQL tables because it's hard to correctly
Re: CDI upgrade to 1.1
most likely wicket-cdi module will be cloned into wicket-cdi-1.1
module with the old one remaining...
-igor
On Mon, May 6, 2013 at 11:03 PM, Emond Papegaaij
emond.papega...@gmail.com wrote:
Yes, the conversational scope is the main reason for the upgrade.
Seam-conversation has always been sort of a hack, and it is good to see
this fixed. You say it is possible to deploy a CDI 1.1 provider as part of
your web application, and this should indeed work. However, a CDI provider
deployed in a war does not provide the same level of integration as the CDI
provider that is loaded by the container. For example, it is not possible
to inject classes like servlet listeners. Also, I'm not sure if extensions
loaded by the container-CDI, such as the extensions provided by infinispan
and resteasy, are available when you embed a CDI provider in your war. What
would happen if you use the infispan extension to configure caches in your
Wicket application or when you combine a REST webservice with a Wicket
application in the same war? I know for sure that the weld servlet listener
does not work when a CDI provider is already loaded by the container, which
could make it difficult to integrate the newer version of weld in your
application.
Relying on the availability of wildfly 8 and/or glassfish 4 is not an
option IMHO. These projects have both shown not to stick to their
deadlines. The wildfly guys even keep saying on their forum 'It's done when
it's done'. This might very well be somewhere mid 2014 for all you know. I
think we should be careful to provide a level of integration that is the
same or better than Wicket 6 does, especially for popular containers like
wildfly and glassfish. Perhaps we can split wicket-cdi into 3 components:
core, cdi-1.0 and cdi-1.1. This way users can pick the version they are
using, rather than changing the cdi version they are using.
Best regards,
Emond
On Mon, May 6, 2013 at 11:18 PM, Dominik Drzewiecki
dominik.drzewie...@gmail.com wrote:
I think that the rationale behind upgrading to CDI 1.1 is the support of
the conversational scope right in the spec.
Right now it is plumbed using seam-conversation-spi along with the
appropriate seam-conversation-{weld,owb,candi} container integration
module. The point is that seam-conversation is somewhat outdated and seems
abandoned (no new releases since version 3.0 in January 2012). It will not
work with openwebbeans =1.1.4 nor will it work with tomee =1.5.0 leaving
the user with the only option - weld 1.1.x. Don't be affraid of cdi 1.1 not
being implemented in containers, one can always settle for custom cdi
integration, deployed as part of web application - both weld and owb are
fitted with appropriate listeners that bootstrap embedded cdi container.
Besides, cdi 1.1 implementations are around the corner - Weld 2.0.0.Final
got released on 24 April, OWB guys declare that it will be pretty
straightforward to support CDI 1.1 after the refactorings that they had
done to OWB 1.2. I understand that upgrading CDI impl in containers already
supporting it is not an option, but by the time wicket 7 RCs start rolling,
both wildfly (jboss 8) and glassfish 4 reach GA (both use weld).
regz,
/dd
2013/5/6 Emond Papegaaij emond.papega...@topicus.nl
Hi all,
I noticed the TODO for Wicket 7 to upgrade the CDI dependency
to 1.1. I think it's better to pospone this upgrade to Wicket 8.
CDI 1.1 is part of JEE 7, for which the spec only has been
approved last week. Containers will need some time to
implement the spec, for example wildFly (formerly JBoss) 8 is
expected to be released in November and Glassfish somewhere
this summer. Upgrading CDI in a container like Glassfish 3.2 or
JBoss 7 often is not option, so I think it's probably better not to
upgrade wicket-cdi before containers supporting CDI 1.1 are
available.
Best regards,
Emond
--
/* Spelin donut mader if iz ina coment */
Re: A few questions about contributing
-0 i would prefer that only core committers are assigned to an issue, that way we know someone is actually taking care of it and its easy to find issues not taken by anyone. if a non-committer wants to contribute a patch and claim an issue while doing so they can leave a comment to that effect which should be sufficient. my two cents. -igor On Thu, May 2, 2013 at 11:17 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi Cedric, On Thu, May 2, 2013 at 6:41 PM, Cedric Gatay gata...@gmail.com wrote: Hi guys, to contribute the most efficiently, I'm curious about few things : * is someone is using IntelliJ IDEA? I'm using the Eclipse code formatter plugin, but I think my formatted code is not yet on par with the one formatted by Eclipse, if another dev is using this IDE and got a good code format setup, I would be interested in getting it. https://github.com/martin-g/dotfiles/blob/master/.IntelliJIdea11/config/codestyles/wicket.xml * is it possible to allow everyone to be assigned to an issue in Jira ? It could be cumbersome to find an issue not already taken by someone. This is possible. Jira setup is: Assignable User Users with this permission may be assigned to issues. - Project Role (Administrators) - Project Role (Contributors) - Project Role (PMC) - Project Role (Committers) i.e. we can add you to Contributors group. Contributors can also: - Edit Issues Ability to edit issues. - Schedule Issues Ability to view or edit an issue's due date. - Assign Issues Ability to assign issues to other people. - Resolve Issues Ability to resolve and reopen issues. This includes the ability to set a fix version. - Close Issues Ability to close issues. Often useful where your developers resolve issues, and a QA department closes them. I'm not aware of such precedent before so we have to ask other Wicket core developers whether we can add you in this group. I'm +1 Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr -- Martin Grigorov Wicket Training Consulting http://jWeekend.com http://jweekend.com/
Re: FormComponent's label outputs markup attributes
because they need to be styled differently and as far as i know there is no cross-browser selector that lets you select a label connected to a form component that has some specific css class or attribute... -igor On Thu, May 2, 2013 at 1:45 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Igor, I have a question about your entry in the roadmap for Wicket 7.0: SimpleFormComponentLabel should output the required class just like wicket:for Why helper classes like SimpleFormComponentLabel and AutoLabel should render anything else than for attribute? And maybe HTML5's form. http://www.w3.org/wiki/HTML/Elements/label#HTML_Attributes https://developer.mozilla.org/en-US/docs/HTML/Element/label required, disabled, etc. should be in FormComponent#onComponentTag -- Martin Grigorov Wicket Training Consulting http://jWeekend.com http://jweekend.com/
Re: Add 'Component' to #updateAjaxRequestAttributes()
On Fri, Apr 26, 2013 at 11:44 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi Igor,
I saw your entry in the roadmap:
==
h4. ajaxbehavior#updateAjaxAttributes() should get component passed in
otherwise referencing the component as needed in throttle settings is
annoying
{code}
queryField.add(new AjaxFormComponentUpdatingBehavior(onkeydown) {
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
attributes.setThrottlingSettings(new
ThrottlingSettings(queryField.getMarkupId(), Duration.seconds(1)));
^
{code}
==
Few comments
1) the throttling id is not used for DOM selector so it could be anything.
Just make sure it is unique for all throttlers
yes. and the easiest/most obvious way to make sure it is unique is to
use component's markup id as base, which we already know to be unique
:)
-igor
2) the component is easily available via #getComponent()
(AbstractDefaultAjaxBehavior#getComponent())
I think we can spare this API break for the users
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com http://jweekend.com/
Re: [VOTE] Branch for Wicket 7.0
correct. the commitment we make is: new features go into current major version we maintain major.version-1 - which means backporting bug fixes we support major.version-2 - which means we backport security releated fixes -igor On Sat, Apr 27, 2013 at 1:07 AM, Martin Grigorov mgrigo...@apache.org wrote: On Sat, Apr 27, 2013 at 9:56 AM, Sven Meier s...@meiers.net wrote: [x] Yes, start working on Wicket 7. When are we going to declare a feature freeze for Wicket 1.5.x? Lately I'm backporting only bug fixes to 1.5.x. New features go only in 6.x. It is not a problem for me to release 1.5.x for some more months. The release script makes this really easy. I think we can freeze it for security related bug fixes only once Wicket 7.0.0 is released. Sven On 04/25/2013 03:15 PM, Martin Grigorov wrote: Hi, I think it is time to start the work for Wicket 7.0. At https://cwiki.apache.org/**confluence/x/D4flAQhttps://cwiki.apache.org/confluence/x/D4flAQyou may see the proposed roadmap. The entries are extracted from https://cwiki.apache.org/**confluence/x/rwjVAQ(Ideashttps://cwiki.apache.org/confluence/x/rwjVAQ(Ideasfor Wicket 7) and currently contains only what I find interesting to me and can implement by myself. If you want some of the other ideas included then add it and assign it to yourself. The change that will cause API breaks is Use Java 7 + add generics to o.a.w.Component and descendants Vote options: [ ] Yes, start work on Wicket 7 with the proposed roadmap [ ] No, it is too soon to mandate Java 7/Servlet 3.0 [ ] No, the suggested improvements are not enough for a new major version -- Martin Grigorov Wicket Training Consulting http://jWeekend.com http://jweekend.com/
Re: [VOTE] Release Apache Wicket 6.7.0 (take 2)
+1 to release -igor On Fri, Apr 12, 2013 at 12:55 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is the second vote to release Apache Wicket 6.7.0. The previous attempt was one month ago and was cancelled due to a bug that caused wicket (examples) to not function on Windows machines. Right after the vote stalled, I got the flu for about 2 weeks and work got in the way. We're back on the original schedule, but missing one release in the mean time. This release contains extra fixes when compared to the candidate from a month ago, see the bottom of this message for the diff between this release candidate and the previous one, and for the full list of fixes. Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.7.0 [ ] No, don't release Apache Wicket 6.7.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.7.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-097/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Here are the signatures for the source release artifacts: GPG Signature for apache-wicket-6.7.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlFoSDkACgkQJBX8W/xy/UUoqgCeOroiBwXTemeP8szbunrIYgib 74sAoJtiJ8gNfrkyLKiFfpZ6767KoQVL =Dxh/ -END PGP SIGNATURE- GPG Signature for apache-wicket-6.7.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlFoSDkACgkQJBX8W/xy/UXxugCeKO2jRhlTpKKwosDlzvtWRFPE 58IAn2zWnXJJadhwJ1qPj9I2umJ1yjhj =let5 -END PGP SIGNATURE- Additional fixes compared to previous release candidate: ** Bug +* [WICKET-4658] - TabbedPanel CSS last is wrong if last step is not visible +* [WICKET-4893] - AutoCompleteTextField removes DropDownChoice from Page +* [WICKET-5086] - FormTester throws an exception when a Palette component is added to a Form associated with a compound property model +* [WICKET-5104] - AjaxSelfUpdatingTimerBehavior in hidden component in ModalWindow causes Ajax Response Error +* [WICKET-5112] - Parantheses problem with UrlValidator +* [WICKET-5114] - Url#toString(StringMode.FULL) throws exception if a segment contains two dots +* [WICKET-5116] - TabbedPanel.setSelectedTab() does not behave as specified in JavaDoc +* [WICKET-5117] - Wicket ignores allowDefault:false attribute in multipart ajax requests +* [WICKET-5123] - Component.continueToOriginalDestination() can redirect to ./. +* [WICKET-5125] - IE8 error in wicket-date.js when used in a modalwindow +* [WICKET-5126] - SecurePackageResourceGuard is blocking access to web fonts +* [WICKET-5131] - Problems with cookies disabled when using 301/302 and also 303 (even with cookies) +* [WICKET-5132] - Evaluation of returned data (which includes alot of javascript) very slow after ajax call in IE10. +* [WICKET-5134] - java.lang.NullPointerException at org.apache.wicket.markup.html.form.Form.onComponentTag(Form.java:1520) during Atmosphere eventbus.post() if using WebSockets +* [WICKET-5136] - CheckingObjectOutputStream#check(Object) swallows Exception without logging the cause +* [WICKET-5138] - Wicket does not correctly handle http OPTIONS requests +* [WICKET-5141] - Exception while rendering absolute URL with UrlResourceReference ** Improvement +* [WICKET-5113] - Set a different TimeZone for the RequestLogger +* [WICKET-5121] - Log warning message if a component that is not on the page associated with the AjaxRequestTarget is added +* [WICKET-5122] - Add the free Wicket guide in the books page on the official site. +* [WICKET-5127] - Dont use sun-internal packages to allow easy jdk7 compilation +* [WICKET-5137] - Improve TagTester support for Ajax responses +* [WICKET-5139] - Missing French translations Full list of changes: Release Notes - Wicket - Version 6.7.0 ** Bug * [WICKET-4658] - TabbedPanel CSS last is wrong if last step is not visible * [WICKET-4803] - UrlDecoder should log a message when invalid input is provided * [WICKET-4871] - wicket-atmosphere version mismatch with wicket-example-jar * [WICKET-4893] - AutoCompleteTextField removes DropDownChoice from Page * [WICKET-4903] - relativeUrl's begins with ./ * [WICKET-4907] - UrlResourceReference generates broken relative URLs * [WICKET-4942] - Double slash '//' in starting url makes Url.parse output a relative Url * [WICKET-4989] - WicketTester should send
Re: [VOTE] Release Apache Wicket 6.7.0 (take 2)
lol. nice! On Fri, Apr 12, 2013 at 1:38 PM, Dan Retzlaff dretzl...@gmail.com wrote: If the changelog doesn't look impressive enough, try this: http://starlogs.net/#apache/wicket On Fri, Apr 12, 2013 at 1:04 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: +1 to release -igor On Fri, Apr 12, 2013 at 12:55 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is the second vote to release Apache Wicket 6.7.0. The previous attempt was one month ago and was cancelled due to a bug that caused wicket (examples) to not function on Windows machines. Right after the vote stalled, I got the flu for about 2 weeks and work got in the way. We're back on the original schedule, but missing one release in the mean time. This release contains extra fixes when compared to the candidate from a month ago, see the bottom of this message for the diff between this release candidate and the previous one, and for the full list of fixes. Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.7.0 [ ] No, don't release Apache Wicket 6.7.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.7.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-097/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Here are the signatures for the source release artifacts: GPG Signature for apache-wicket-6.7.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlFoSDkACgkQJBX8W/xy/UUoqgCeOroiBwXTemeP8szbunrIYgib 74sAoJtiJ8gNfrkyLKiFfpZ6767KoQVL =Dxh/ -END PGP SIGNATURE- GPG Signature for apache-wicket-6.7.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlFoSDkACgkQJBX8W/xy/UXxugCeKO2jRhlTpKKwosDlzvtWRFPE 58IAn2zWnXJJadhwJ1qPj9I2umJ1yjhj =let5 -END PGP SIGNATURE- Additional fixes compared to previous release candidate: ** Bug +* [WICKET-4658] - TabbedPanel CSS last is wrong if last step is not visible +* [WICKET-4893] - AutoCompleteTextField removes DropDownChoice from Page +* [WICKET-5086] - FormTester throws an exception when a Palette component is added to a Form associated with a compound property model +* [WICKET-5104] - AjaxSelfUpdatingTimerBehavior in hidden component in ModalWindow causes Ajax Response Error +* [WICKET-5112] - Parantheses problem with UrlValidator +* [WICKET-5114] - Url#toString(StringMode.FULL) throws exception if a segment contains two dots +* [WICKET-5116] - TabbedPanel.setSelectedTab() does not behave as specified in JavaDoc +* [WICKET-5117] - Wicket ignores allowDefault:false attribute in multipart ajax requests +* [WICKET-5123] - Component.continueToOriginalDestination() can redirect to ./. +* [WICKET-5125] - IE8 error in wicket-date.js when used in a modalwindow +* [WICKET-5126] - SecurePackageResourceGuard is blocking access to web fonts +* [WICKET-5131] - Problems with cookies disabled when using 301/302 and also 303 (even with cookies) +* [WICKET-5132] - Evaluation of returned data (which includes alot of javascript) very slow after ajax call in IE10. +* [WICKET-5134] - java.lang.NullPointerException at org.apache.wicket.markup.html.form.Form.onComponentTag(Form.java:1520) during Atmosphere eventbus.post() if using WebSockets +* [WICKET-5136] - CheckingObjectOutputStream#check(Object) swallows Exception without logging the cause +* [WICKET-5138] - Wicket does not correctly handle http OPTIONS requests +* [WICKET-5141] - Exception while rendering absolute URL with UrlResourceReference ** Improvement +* [WICKET-5113] - Set a different TimeZone for the RequestLogger +* [WICKET-5121] - Log warning message if a component that is not on the page associated with the AjaxRequestTarget is added +* [WICKET-5122] - Add the free Wicket guide in the books page on the official site. +* [WICKET-5127] - Dont use sun-internal packages to allow easy jdk7 compilation +* [WICKET-5137] - Improve TagTester support for Ajax responses +* [WICKET-5139] - Missing French translations Full list of changes: Release Notes - Wicket - Version 6.7.0 ** Bug * [WICKET-4658] - TabbedPanel CSS last is wrong if last step is not visible * [WICKET-4803] - UrlDecoder should log a message when invalid input is provided * [WICKET-4871] - wicket-atmosphere
Re: [VOTE] Release Apache Wicket 6.7.0
friday is fine by me -igor On Mon, Apr 8, 2013 at 4:05 AM, Cedric Gatay ced...@gatay.fr wrote: +1 for the 6.7.0 release on Friday. __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Mon, Apr 8, 2013 at 11:43 AM, Andrea Del Bene an.delb...@gmail.comwrote: +1 for keeping the schedule and release it on Friday. as this release instance has failed, and a couple of weeks have gone by due to flu and catching up on work related projects, shall I craft a 6.7.0 release now or shall I wait until friday and continue our release schedule (but release 6.7 instead of the scheduled 6.8?) My preference is wait until friday and maintaining the schedule. I don't have any objection of new stuff entering this particular release— I think 6.7.0 was just delayed a month due to unforeseen circumstances. Martijn On Thu, Mar 28, 2013 at 6:23 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Thu, Mar 28, 2013 at 6:21 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Well the vote didn't pass (didn't reach the required 3 +1 votes/majority), so there's no reason (yet) for a 6.7.1. Need to re-roll 6.7.0 and restart the vote. Also, I'm on a short holiday and don't know if I have the time to roll another release (6.7.0 or 6.7.1) until tuesday. My guess is there's no actual rush to get it out, other than striving to maintain the schedule. Martijn
Re: git commit: fix WICKET-5117 Wicket ignores allowDefault:false attribute in multipart ajax requests
are there already tests covering the multipart code branch?
On Tue, Mar 26, 2013 at 2:29 PM, Martin Grigorov mgrigo...@apache.org wrote:
want to try QUnit ? :-)
On Mar 26, 2013 11:22 PM, ivaynb...@apache.org wrote:
Updated Branches:
refs/heads/master 15e5b0ec5 - ea29f1f7c
fix WICKET-5117 Wicket ignores allowDefault:false attribute in multipart
ajax requests
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/ea29f1f7
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/ea29f1f7
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/ea29f1f7
Branch: refs/heads/master
Commit: ea29f1f7c04fdec88a06d056b1ddf4f9d345a22d
Parents: 15e5b0e
Author: Igor Vaynberg igor.vaynb...@gmail.com
Authored: Tue Mar 26 14:22:31 2013 -0700
Committer: Igor Vaynberg igor.vaynb...@gmail.com
Committed: Tue Mar 26 14:22:31 2013 -0700
--
.../wicket/ajax/res/js/wicket-ajax-jquery.js | 17 --
1 files changed, 14 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/ea29f1f7/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
index 11ab136..1f80ded 100644
---
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
+++
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
@@ -528,7 +528,9 @@
Wicket.Event.publish('/ajax/call/precondition',
attrs);
if (attrs.mp) { // multipart form. jQuery.ajax()
doesn't help here ...
- return this.submitMultipartForm(context);
+ var ret =
this.submitMultipartForm(context);
+ self.preventDefaultIfNecessary(attrs);
+ return ret;
}
if (attrs.f) {
@@ -635,6 +637,17 @@
self._executeHandlers(attrs.ah, attrs);
Wicket.Event.publish('/ajax/call/after', attrs);
+ self.preventDefaultIfNecessary(attrs);
+
+ return jqXHR;
+ },
+
+ /**
+* Aborts the default event if attributes request it
+*
+* @param {Object} attrs - the Ajax request attributes
configured at the server side
+*/
+ preventDefaultIfNecessary: function(attrs) {
if (!attrs.ad attrs.event) {
try {
attrs.event.preventDefault();
@@ -643,8 +656,6 @@
// jquery fails 'member not found'
with calls on busy channel
}
}
-
- return jqXHR;
},
/**
Re: [VOTE] Release Apache Wicket 6.7.0
+1 to release -igor On Fri, Mar 22, 2013 at 8:40 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is a vote to release Apache Wicket 6.7.0 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.7.0 [ ] No, don't release Apache Wicket 6.7.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/6.7.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-014/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Here are the signatures for the source release artifacts: GPG Signature for apache-wicket-6.7.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlFMVFUACgkQJBX8W/xy/UXw+wCeP+da6MQS+3X5qwDviAbrSylh AnQAnRyuPvMuKP8nqsSISB0MV57/xm22 =ueds -END PGP SIGNATURE- GPG Signature for apache-wicket-6.7.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iEYEABECAAYFAlFMVFUACgkQJBX8W/xy/UU1YQCeMVnFr2D5yEXF28BbXQNhNz32 7lwAoMRtMMTKkfCVXnon564pkij5pQxA =tWH6 -END PGP SIGNATURE- Release Notes - Wicket - Version 6.7.0 ** Bug * [WICKET-4803] - UrlDecoder should log a message when invalid input is provided * [WICKET-4871] - wicket-atmosphere version mismatch with wicket-example-jar * [WICKET-4903] - relativeUrl's begins with ./ * [WICKET-4907] - UrlResourceReference generates broken relative URLs * [WICKET-4942] - Double slash '//' in starting url makes Url.parse output a relative Url * [WICKET-4989] - WicketTester should send copies of its cookies * [WICKET-4995] - Using CryptoMapper causes page to render twice * [WICKET-5039] - Manual invocation of FunctionsExecutor#notify() is broken * [WICKET-5041] - DefaultCssAutoCompleteTextField should have Constructor (String id) * [WICKET-5044] - Atmosphere + DateLabel * [WICKET-5045] - Upgrade Atmosphere to 1.0.10 * [WICKET-5047] - Wicket Ajax: Inline script header contribution issue * [WICKET-5048] - Inline enclosures don't work with different namespace * [WICKET-5049] - Wicket Session may be null in SessionBindingListener after deserialization * [WICKET-5052] - @SpringBean fails to invoke methods on bean with non-public methods * [WICKET-5053] - random parameters is now _ with jQuery Ajax * [WICKET-5054] - Possible bug in org.apache.wicket.util.lang.Packages when building path with repeating names * [WICKET-5055] - AutoComplete still triggers redundant events to registered change listener * [WICKET-5061] - EnclosureHandler ignores wicket:xyz elements as children * [WICKET-5067] - SelectOptions fails to render text on openClose tag * [WICKET-5072] - Cookies#isEqual(Cookie, Cookie) may fail with NullPointerException * [WICKET-5073] - UrlRenderer#removeCommonPrefixes() fails when contextPath+filterPrefix has more segments than the argument * [WICKET-5075] - When modal window is closed page scrolls to top * [WICKET-5076] - form#onSubmit() is called on just replaced nested forms * [WICKET-5078] - RestartResponseException broken with page instance and bookmarkable page * [WICKET-5080] - FilterToolbar.html contains javascript that is used elsewhere * [WICKET-5082] - Ajax update renders parent/child JS in different order than initial Page render * [WICKET-5085] - InlineEnclosure are piling up on each render * [WICKET-5093] - The event listener in Wicket.Ajax.ajax() should not return the value of attrs.ad (allowDefault) * [WICKET-5094] - ISecuritySettings#getEnforceMounts(true) prevents access to *all* non-mounted bookmarkable pages * [WICKET-5098] - PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars * [WICKET-5102] - wicket-bean-validation: Bean validation PropertyValidator only works with direct field access * [WICKET-5103] - Wicket session id not up to date when container changes session id ** Improvement * [WICKET-4115] - SignInPanel should not always redirect to the Home page when the user is signed-in automaticaly with the remember-me feature. * [WICKET-5005] - Add Utility to allow conversion from Panel (or Component) to html String * [WICKET-5038] - Add equals() and hashcode() implementation to INamedParameters.NamedPair * [WICKET-5046] - NumberTextField should use appropriate validator * [WICKET-5050] - AutoComplete should not request suggestions if input is no longer active element * [WICKET-5057] - FilteringHeaderResponse
Re: Release Wicket 6.7.0 soon ?
+1 -igor On Mon, Mar 18, 2013 at 8:51 AM, Martin Grigorov mgrigo...@apache.org wrote: OK, thanks! I hope you get better soon! On Mon, Mar 18, 2013 at 4:38 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Mon, Mar 18, 2013 at 9:41 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi Martijn, Jira says 15.03 as release date for 6.7.0. I guess you are in vacation or busy with other matters. I came down with the flu. I'll make it this friday (i.e. postpone a week). Should we wait for you or someone else should make the release this time ? I suggest just wait. I'm feeling quite bit better today (have not felt good past week) Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [Vote] Release Apache Wicket 1.4.22
+1 -igor On Wed, Feb 20, 2013 at 6:33 AM, Martin Grigorov mgrigo...@apache.org wrote: This vote is to release Apache Wicket 1.4.22 Git repo http://git-wip-us.apache.org/repos/asf/wicket.git Branch name build/wicket-1.4.22 Archived and signed Git repo https://dist.apache.org/repos/dist/dev/wicket/1.4.22/ Staging Maven repo https://repository.apache.org/content/repositories/orgapachewicket-276/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12324070 This vote ends Saturday, February 23 at 16:30 (GMT+2) Please test the release and offer your vote. The Wicket team!
Re: [Vote] Release Apache Wicket 1.5.10
+1 -igor On Wed, Feb 20, 2013 at 3:59 AM, Martin Grigorov mgrigo...@apache.org wrote: This vote is to release Apache Wicket 1.5.10 Git repo http://git-wip-us.apache.org/repos/asf/wicket.git Branch name build/wicket-1.5.10 Archived and signed Git repo https://dist.apache.org/repos/dist/dev/wicket/1.5.10/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12323510 This vote ends Saturday, February 23 at 14:00 (GMT+2) Please test the release and offer your vote. The Wicket team!
Re: Igor needs 105 commits to overtake Eelco's commit count
coo On Tue, Feb 19, 2013 at 5:49 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Commit statistics for the Wicket project across the whole history (lines marked with * are from people who have had commit bits, non-marked lines are original authors from pull requests): * 2932 Eelco Hillenius * 2827 Igor Vaynberg * 2053 Martin Grigorov * 1867 Juegen Donnerstag * 1484 Johan Compagner * 1321 Jonathan Locke * 963 Matej Knopp * 928 Martijn Dashorst * 422 Alastair Maw * 353 Peter Ertl * 277 Jean-Baptiste Quenot * 235 Frank Bille Jensen * 234 Sven Meier * 218 Janne Hietamaki * 205 Gerolf Seitz * 117 Emond Papegaaij *78 Pedro Santos *62 Gwyn Evans *55 Jeremy Thomerson *42 Timo Rantalaiho *40 Chris Turner *16 Carl-Eric Menzel *14 Ate Douma *12 Maurice Marrink * 8 Jan Blok 2 Jesse Long 1 slowery 1 robert mcguinness 1 cvs2svn 1 Thomas Götz 1 Michael Mosmann 1 Joe Schaefer 1 Bertrand Guay-Paquet Martijn
Re: How to contribute to the reference guide
why doesnt the guide live in a subdir of the project. that way there will be a guide per branch. one of the biggest problems with the wiki, etc, is that it doesnt account for code differences between the versions. having a guide per branch (major version) makes more sense. -igor On Wed, Feb 6, 2013 at 1:04 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Few people contacted me personally to ask how they can contribute to the reference guide. I've just added http://martin-g.github.com/wicket-reference-guide/howtohelp.html that explains the steps. Let me know if I can improve it. Or just me a patch ;-) -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [VOTE] Release Apache Wicket 6.5.0
+1 to release -igor On Fri, Jan 18, 2013 at 3:58 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.5.0 [ ] No, don't release Apache Wicket 6.5.0, because ... Distributions, changelog, keys and signatures can be found at: http://dist.apache.org/repos/dist/dev/wicket/wicket-6.5.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-146/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Signatures: apache-wicket-6.5.0.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlD52k0ACgkQJBX8W/xy/UVeKwCgmTaR9Ij79wyi2SEvFRZI2Msj tKcAoNP8onT0wgH9GM445dvb4c+mQqTH =svmp -END PGP SIGNATURE- apache-wicket-6.5.0.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlD52k0ACgkQJBX8W/xy/UVefgCgsyv0NIWHpgGd/RAY9aU8jDgc QKgAnAm6xGINMC+lDozYK1KotGCOTL+l =OFQ0 -END PGP SIGNATURE-
Re: git commit: add a serialization-safe class wrapper
On Sun, Nov 25, 2012 at 6:27 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
On Sat, Nov 24, 2012 at 8:16 PM, ivaynb...@apache.org wrote:
Updated Branches:
refs/heads/master 48044610a - 65dd7b32e
add a serialization-safe class wrapper
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/65dd7b32
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/65dd7b32
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/65dd7b32
Branch: refs/heads/master
Commit: 65dd7b32ea4f91862353ab0f7bafe3bca5e271ea
Parents: 4804461
Author: Igor Vaynberg igor.vaynb...@gmail.com
Authored: Sat Nov 24 11:16:32 2012 -0800
Committer: Igor Vaynberg igor.vaynb...@gmail.com
Committed: Sat Nov 24 11:16:32 2012 -0800
--
.../wicket/util/reference/ClassReference.java | 72 +++
1 files changed, 72 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/65dd7b32/wicket-core/src/main/java/org/apache/wicket/util/reference/ClassReference.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/util/reference/ClassReference.java
b/wicket-core/src/main/java/org/apache/wicket/util/reference/ClassReference.java
new file mode 100644
index 000..7653633
--- /dev/null
+++
b/wicket-core/src/main/java/org/apache/wicket/util/reference/ClassReference.java
@@ -0,0 +1,72 @@
+package org.apache.wicket.util.reference;
+
+import java.io.Serializable;
+import java.lang.ref.WeakReference;
+
+import org.apache.wicket.Application;
+
+/**
+ * A serialization-safe reference to a {@link Class}
+ *
+ * @author igor
+ *
+ * @param T
+ *type of class
+ */
+public class ClassReferenceT implements Serializable
+{
+ private transient WeakReferenceClass? extends T cache;
+ private final String name;
+
+ /**
+* Constructor
+*
+* @param clazz
+*/
+ public ClassReference(Class? extends T clazz)
+ {
+ name = clazz.getName();
+ cache(clazz);
+ }
+
+ /**
+* @return the {@link Class} stored in this reference
+*/
+ @SuppressWarnings(unchecked)
+ public Class? extends T get()
+ {
+ Class? extends T clazz = cache != null ? cache.get() :
null;
+ if (clazz == null)
+ {
+ try
+ {
+ clazz = (Class? extends
T)Application.get()
+ .getApplicationSettings()
+ .getClassResolver()
+ .resolveClass(name);
Issue 1:
org.apache.wicket.core.util.lang.WicketObjects#resolveClass(String) does
almost the same.
Differences:
1) it falls back to the context class loader
2) it just logs a warning and returns null instead
Question: do we want to re-use it here ?
done. i dont much like the idea of delegating to the context because
this class should fail outside of wicket context, but it doesnt matter
that much i guess.
Issue 2:
org.apache.wicket.util.ClassProvider is something very similar to
ClassReference.
problem 1: ClassProvider is just broken in its current state because it
doesn't resolve the class from its name when the weakRef is null.
yes, it seems very strange and very broken.
problem 2: Its only usage is at
org.apache.wicket.SystemMapper.HomePageProvider and it really doesn't need
ClassProvider but just IProviderClass? extends Page
Question: should we merge ClassProvider and ClassReference into one ?
I think the easiest way is to just deprecate ClassProvider.
i modified classreference to implement iprovider so it can now replace
classprovider as a drop in. want to do it?
-igor
+ }
+ catch (ClassNotFoundException e)
+ {
+ throw new RuntimeException(Could not
resolve class: + name, e);
+ }
+ cache(clazz);
+ }
+ return clazz;
+ }
+
+ private void cache(Class? extends T clazz)
+ {
+ cache = new WeakReferenceClass? extends T(clazz);
+ }
+
+ /**
+* Diamond operator factory
+*
+* @param clazz
+* @return class reference
+*/
+ public static T ClassReferenceT of(ClassT clazz)
+ {
+ return new ClassReferenceT(clazz);
+ }
+}
\ No newline at end of file
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: [2/2] git commit: Make 'groups' member final and rename other field members to not have '_' as suffix to make them consistent with rest Wicket classes.
can you please rename the fields back.
the underscore at the end of the field means those fields should not
be accessed directly
for example property_ should not be accessed directly - only via
getProperty() getter because it is lazily initialized. even though it
is private people modifying the code may not be aware of or not
remember not to access it directly.
-igor
On Sun, Nov 25, 2012 at 7:49 AM, mgrigo...@apache.org wrote:
Make 'groups' member final and rename other field members to not have '_' as
suffix to make them consistent with rest Wicket classes.
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/9e970024
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/9e970024
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/9e970024
Branch: refs/heads/master
Commit: 9e9700241eadf93bed2d2a4d61e7cadb998005d5
Parents: ddf53c9
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
Authored: Sun Nov 25 16:43:05 2012 +0100
Committer: Martin Tzvetanov Grigorov mgrigo...@apache.org
Committed: Sun Nov 25 16:43:05 2012 +0100
--
.../wicket/bean/validation/PropertyValidator.java | 28 +++---
1 files changed, 14 insertions(+), 14 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/9e970024/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
--
diff --git
a/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
b/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
index ea843c1..e625f38 100644
---
a/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
+++
b/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
@@ -52,11 +52,11 @@ import org.apache.wicket.validation.IValidator;
*/
public class PropertyValidatorT extends Behavior implements IValidatorT
{
- private static Class?[] EMPTY = new Class?[0];
+ private static final Class?[] EMPTY = new Class?[0];
private FormComponentT component;
- private Property property_;
- private IModelClass?[] groups_;
+ private Property property;
+ private final IModelClass?[] groups;
public PropertyValidator(Class?... groups)
{
@@ -75,16 +75,16 @@ public class PropertyValidatorT extends Behavior
implements IValidatorT
public PropertyValidator(Property property, IModelClass?[] groups)
{
- this.property_ = property;
- this.groups_ = groups;
+ this.property = property;
+ this.groups = groups;
}
private Property getProperty()
{
- if (property_ == null)
+ if (property == null)
{
- property_ =
BeanValidationConfiguration.get().resolveProperty(component);
- if (property_ == null)
+ property =
BeanValidationConfiguration.get().resolveProperty(component);
+ if (property == null)
{
throw new IllegalStateException(
Could not resolve Property from
component: +
@@ -94,16 +94,16 @@ public class PropertyValidatorT extends Behavior
implements IValidatorT
to resolve the Property
automatically);
}
}
- return property_;
+ return property;
}
private Class?[] getGroups()
{
- if (groups_ == null)
+ if (groups == null)
{
return EMPTY;
}
- return groups_.getObject();
+ return groups.getObject();
}
@SuppressWarnings(unchecked)
@@ -123,7 +123,7 @@ public class PropertyValidatorT extends Behavior
implements IValidatorT
can only be added to FormComponents);
}
- // TODO add a validation key that appends the type so we can
have differnet messages for
+ // TODO add a validation key that appends the type so we can
have different messages for
// @Size on String vs Collection - done but need to add a key
for each superclass/interface
this.component = (FormComponentT)component;
@@ -136,9 +136,9 @@ public class PropertyValidatorT
Re: [2/2] git commit: Make 'groups' member final and rename other field members to not have '_' as suffix to make them consistent with rest Wicket classes.
i think both should be used. the underscore to distract you - so you
will go check the comment/javadoc of the field.
-igor
On Sun, Nov 25, 2012 at 12:50 PM, Martin Grigorov mgrigo...@apache.org wrote:
I think comments/javadoc in the code would be better.
The trailing underscore didn't tell me that this is the reason.
If we are going to use them from now on then let's make it public in dev@.
On Sun, Nov 25, 2012 at 9:30 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
can you please rename the fields back.
the underscore at the end of the field means those fields should not
be accessed directly
for example property_ should not be accessed directly - only via
getProperty() getter because it is lazily initialized. even though it
is private people modifying the code may not be aware of or not
remember not to access it directly.
-igor
On Sun, Nov 25, 2012 at 7:49 AM, mgrigo...@apache.org wrote:
Make 'groups' member final and rename other field members to not have
'_' as suffix to make them consistent with rest Wicket classes.
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/9e970024
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/9e970024
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/9e970024
Branch: refs/heads/master
Commit: 9e9700241eadf93bed2d2a4d61e7cadb998005d5
Parents: ddf53c9
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
Authored: Sun Nov 25 16:43:05 2012 +0100
Committer: Martin Tzvetanov Grigorov mgrigo...@apache.org
Committed: Sun Nov 25 16:43:05 2012 +0100
--
.../wicket/bean/validation/PropertyValidator.java | 28 +++---
1 files changed, 14 insertions(+), 14 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/9e970024/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
--
diff --git
a/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
b/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
index ea843c1..e625f38 100644
---
a/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
+++
b/wicket-experimental/wicket-bean-validation/src/main/java/org/apache/wicket/bean/validation/PropertyValidator.java
@@ -52,11 +52,11 @@ import org.apache.wicket.validation.IValidator;
*/
public class PropertyValidatorT extends Behavior implements
IValidatorT
{
- private static Class?[] EMPTY = new Class?[0];
+ private static final Class?[] EMPTY = new Class?[0];
private FormComponentT component;
- private Property property_;
- private IModelClass?[] groups_;
+ private Property property;
+ private final IModelClass?[] groups;
public PropertyValidator(Class?... groups)
{
@@ -75,16 +75,16 @@ public class PropertyValidatorT extends Behavior
implements IValidatorT
public PropertyValidator(Property property, IModelClass?[]
groups)
{
- this.property_ = property;
- this.groups_ = groups;
+ this.property = property;
+ this.groups = groups;
}
private Property getProperty()
{
- if (property_ == null)
+ if (property == null)
{
- property_ =
BeanValidationConfiguration.get().resolveProperty(component);
- if (property_ == null)
+ property =
BeanValidationConfiguration.get().resolveProperty(component);
+ if (property == null)
{
throw new IllegalStateException(
Could not resolve Property from
component: +
@@ -94,16 +94,16 @@ public class PropertyValidatorT extends Behavior
implements IValidatorT
to resolve the
Property automatically);
}
}
- return property_;
+ return property;
}
private Class?[] getGroups()
{
- if (groups_ == null)
+ if (groups == null)
{
return EMPTY;
}
- return groups_.getObject();
+ return groups.getObject();
}
@SuppressWarnings(unchecked)
@@ -123,7 +123,7 @@ public class PropertyValidatorT extends
Re: Release planning 6.4/6.5
is that when the world is supposed to end? On Mon, Nov 19, 2012 at 6:29 AM, Martin Grigorov mgrigo...@apache.org wrote: First, let's see what will happen at Dec 21th! On Mon, Nov 19, 2012 at 4:26 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: With the holidays coming up, I have set 6.4 to be released on 14 december, and 6.5 on 18 januari. Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [VOTE] Release Apache Wicket 6.3.0
+1 ps if all of us vote +1/-1 why does the email still say [ ] Yes, release ... :) -igor On Fri, Nov 16, 2012 at 6:09 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Please download the source distributions found on my people.apache.org distribution area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.3.0 [ ] No, don't release Apache Wicket 6.3.0, because ... Distributions, changelog, keys and signatures can be found at: http://people.apache.org/~dashorst/wicket-6.3.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-042/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Signature for apache-wicket-6.3.0.tar.gz: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlCmHncACgkQJBX8W/xy/UW5FACgg2wb7wpwnSY+234DUuyqvDD9 HxMAoNSs6vENJjkIxrJRX2lMEkHO5ypD =0/XE -END PGP SIGNATURE- Signature for apache-wicket-6.3.0.zip: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlCmHncACgkQJBX8W/xy/UWdFgCfY37WtS3IbO0EjzdBC6UP5WF9 EH4AmwWaAFknJjEPsY6i6oh78VtNyVYW =Qanp -END PGP SIGNATURE- Release Notes - Wicket - Version 6.3.0 ** Bug * [WICKET-4623] - UploadProgressBar does not show up if the form submitted by AjaxButton or AjaxLink * [WICKET-4826] - PaletteButton#onComponentTag(ComponentTag) does not call super * [WICKET-4829] - ComponentResolvers created in app init ignore markup's namespace * [WICKET-4836] - Unmount a page does not work if the path starts with / * [WICKET-4837] - SmartLinkMultiLineLabel does not display email addresses or web URLs as hyperlinks * [WICKET-4841] - Return error code 400 when an Ajax request has no base url set in header/request parameters. * [WICKET-4842] - WicketRuntimeException when Tomcat cleans up a session later on * [WICKET-4844] - AbstractResourceReferenceMapper doesn't escape separators in style/variation names * [WICKET-4848] - Reporter of FeedbackMessage should not be set to 'null' on detach * [WICKET-4850] - BaseWicketTester discards cookies with MaxAge = -1 when processing a new request * [WICKET-4851] - IE8, IE7 javascript errors with Wicket 6 * [WICKET-4857] - AutoCompleteTextFields submits Form if a choice is selected via enter-key * [WICKET-4859] - Integer overflow in AbstractToolbar * [WICKET-4864] - 'format' not set in ConversionException * [WICKET-4865] - Page parameters not working with CryptoMapper ** Improvement * [WICKET-4831] - Append the feedback message CSS class instead of overriding it * [WICKET-4835] - Add debug log messages in CompoundRequestMapper#mapRequest * [WICKET-4845] - Make BasicResourceReferenceMapper public so it is easy to extend it * [WICKET-4853] - Change FormComponent#reportRequiredError() from private to protected * [WICKET-4856] - Support SVG extension in SecurePackageResourceGuard * [WICKET-4863] - Customize ValidationError creation by FormComponent * [WICKET-4867] - Detach the object before calculating its size ** Task * [WICKET-4855] - Upgrade JQuery to 1.8.2
Re: [Vote] Release Apache Wicket 1.5.9
+1 -igor On Tue, Nov 6, 2012 at 1:34 AM, Martin Grigorov mgrigo...@apache.orgwrote: This vote is to release Apache Wicket 1.5.9 Git repo http://git-wip-us.apache.org/repos/asf/wicket.git Branch name build/wicket-1.5.9 Archived and signed Git repo http://people.apache.org/~mgrigorov/wicket-1.5.9/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12322962 This vote ends Friday, November 9 at 12:00 (GMT+2) Please test the release and offer your vote. The Wicket team!
Re: git commit: WICKET-4859 change component id counter to long, similar to RepeatingView
its not for convenience. without this autogenerated id the user would have to specify it and make sure it is unique across all toolbars in the datatable. when the datatable is created/configured via several methods this can be a headache. also, the ids do not matter because they are used in the repeater. -igor On Thu, Nov 8, 2012 at 4:12 AM, Sven Meier s...@meiers.net wrote: Statics make me cringe Me too. I'm not sure about the need of an AtomicLong. I've just took the easy route and changed it to how RepeatingView works. why does the counter have to be globally unique? See my last comment on the issue: It's just that toolbars have an auto generated id (for convenience?). Sven On 11/08/2012 11:26 AM, Martijn Dashorst wrote: On Thu, Nov 8, 2012 at 11:24 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Thu, Nov 8, 2012 at 10:02 AM, svenme...@apache.org wrote: - private static int counter = 0; + /** Counter used for generating unique component ids. */ + private static long counter = 0; Should this be an AtomicLong instead? Statics make me cringe in a multithreaded environment. On second thought: why does the counter have to be globally unique? Doesn't that make it rather an issue with long running applications where markup ids generated from component ids get very long? Martijn
Re: [VOTE] Release Apache Wicket 6.2.0
+1 -igor On Fri, Oct 19, 2012 at 1:10 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Please download the source distributions found on my people.apache.org distribution area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.2.0 [ ] No, don't release Apache Wicket 6.2.0, because ... Distributions, changelog, keys and signatures can be found at: http://people.apache.org/~dashorst/wicket-6.2.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-143/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Signature for apache-wicket-6.2.0.tar.gz: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlCBq9cACgkQJBX8W/xy/UV1AwCg0nYpvPC2ImS6SN5o0uk9MgL5 uOYAn11kfDfnHB5+opoE5b9WiMjyEbK0 =o4SQ -END PGP SIGNATURE- Signature for apache-wicket-6.2.0.zip: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlCBq9cACgkQJBX8W/xy/UWsYwCg1I9cfQMgrY8eMsItZCiGzIii zREAnApoWxAlEv1k9R8ITzg+cIoVoZId =6oZp -END PGP SIGNATURE- Martijn
Re: Type-safe PropertyModel for Wicket 7
On Wed, Oct 10, 2012 at 10:42 AM, Dan Retzlaff dretzl...@gmail.com wrote: I'd like to start a thread on Dominik Drzewiecki's suggestion of a type-safe property model improvement for Wicket 7. I've seen a few competing solutions: 1. Igor's metagen: https://github.com/42Lines/metagen 2. Igor's bindgen-wicket: http://code.google.com/p/bindgen-wicket/ 3. Carl-Eric's wicket-safemodel: https://github.com/duesenklipper/wicket-safemodel We use our own metagen-like solution (written before Igor's) for use in PropertyModels and JPA/Hibernate criteria queries, but we've been eyeing... 4. Querydsl (http://www.querydsl.com/) ... as a JPA/Hibernate query alternative. To avoid redundant Maven plugins and generated classes, I've been meaning to explore adapting Querydsl's Q* classes into a Wicket IModel. This approach is too heavy for a Wicket core feature, but I mention it because on the surface it seems like the cleanest option for JPA-backed Wicket projects. Is there a clear best here (or elsewhere)? Worst? :) Igor, is it accurate to say that metagen supercedes bindgen-wicket? yes. i started out working with bindgen because it offers a nice syntax of ( a.foo().bar() ) to build expressions, but because of that it is also very viral and generates a lot of metadata. i wrote metagen to reduce the amount of this metadata generated, but it sacrifices on the elegance of property expression syntax ( a.get(B.foo).get(C.bar) ), this syntax is similar to jpa's builtin metadata syntax. metagen is a standalone project. -igor Is it a reasonable goal for this to be a core feature, or does its probable Maven plugin relegate it to another (experimental?) module? Cheers, Dan
Re: [vote] Release Apache Wicket 6.1.1 (take 2)
+1 -igor On Fri, Oct 5, 2012 at 4:36 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: This is the second attempt to release Apache Wicket 6.1.1, as I botched creating the source archives (the rest seem in good working order). The source archives have been updated, as are the signatures. Please ensure that your sources tarball has the correct signature (I've included the GPG signatures below). All, as promised: a bug fix release for 6.1.0 with two issues resolved: WICKET-4759 FilterForm/FilterToolbar don't work when there's more than one IColumn to be filtered WICKET-4789 url rendering regression: keep trailing empty segment if base still has segments but relative has not Distributions: http://people.apache.org/~dashorst/wicket-6.1.1 Maven staging repository with the artifacts (includes wicket-parent-6.1.1.pom) https://repository.apache.org/content/repositories/orgapachewicket-091/ Build branch: build/wicket-6.1.1 Detached signatures below. [ ] Yes, release 6.1.1 [ ] No, don't release 6.1.1 Martijn Detached signatures: apache-wicket-6.1.1.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlBuwqoACgkQJBX8W/xy/UV3CQCeMqU7MVzgnD45D8ysWdqNNZbF FaYAmwW365Yq712BOqt/s1DyszYrox+n =fVqm -END PGP SIGNATURE- apache-wicket-6.1.1.zip.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlBuwrQACgkQJBX8W/xy/UUvFwCfdNFwU/IIS1nw3snGUvg4VKJP ufcAnj5JwzgDdbb4/j65mZaVshHLwlgS =s06X -END PGP SIGNATURE-
Re: IWriteableModel
what problem are you trying to solve? -igor On Sun, Sep 30, 2012 at 11:25 PM, Michael Mosmann mich...@mosmann.de wrote: Hi, .. yesterday I did some refactoring which introduced a IReadOnlyModel interface. I stopped this so far because of these many default casts to IModel. I will try it again with the other way around (IWriteableModel). So far I could see how things become more clear if the right interface is used. So here comes some questions: - Is somebody interested in this change (beside me)? - Is there a chance that we missing something so wicket could break? - Is there a better name (sure there is)? Thanks Michael
Re: Component setDefaultModel
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before. So
the
label does not see any changes, because no one tells the model instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine,
but
its not. A child component does not use getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to trouble,
if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might
not
got
the full picture how to use wicket the right way errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so there
is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Hi,
is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause
Re: Component setDefaultModel
i thought the issue we were discussing here is the way the models are
linked...which is not solved by making setdefaultmodelobject
non-public.
-igor
On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote:
If you extend GenericPanel you inherit setModel() and getModel(), that's the
whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to tinker
with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but this
is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again
in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So
the
label does not see any changes, because no one tells the model
instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel,
since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all
FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance,
the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is
fine,
but
its not. A child component does not use
getParent().getDefaultModel()
to
get
Re: Component setDefaultModel
em. setdefaultmodel
-igor
On Thu, Sep 27, 2012 at 10:09 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i thought the issue we were discussing here is the way the models are
linked...which is not solved by making setdefaultmodelobject
non-public.
-igor
On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote:
If you extend GenericPanel you inherit setModel() and getModel(), that's the
whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to tinker
with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but this
is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this, defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model isn't the wicket way so I'd
suggest
changing the visibility of Component#setDefaultModel() to protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it again
in
an
other way:
APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So
the
label does not see any changes, because no one tells the model
instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.
thanks
Michael
Hi,
In this particular code I think the problem is PropertyModel,
since
it brings the type unsafety.
Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all
FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
mich...@mosmann.de
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance,
the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);
add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 10:49 AM, Sven Meier s...@meiers.net wrote:
We're discussing the case where a component distributes its model to its
children or behaviors.
For the component developer it's easier to assume that the model can't be
changed without its consensus (i.e. by offering a generic #setModel()).
Of course this can be handled perfectly by a coding guideline. I always tell
people to *never* change a component's model.
I cannot count times where I'm called to a developer's IDE with him having
absolutely no clue why something entered here doesn't display over there: In
many cases this is caused by setting models.
But a protected #setDefaultModelObject() would make this explicit in the
API.
ok. lets start with a bit of history to have more context.
setDefaultModel() only exists because of type-erasure. before wicket
supported generics all components had a public setModel() method. so,
one might say that having a public setModel() is the wicket way
because it was there since 1.0. just to establish the baseline.
lets take a concrete example of FormComponent. right now it has a
public setModel() method, but by your thinking we would have to make
both setDefaultModel and setModel methods protected, because we do not
know that all FormComponents support changing the model. after all, a
common subclass of FormComponent is FormComponentPanel which pretty
much always distributes its model. so, we leave it to subclasses of
FormComponent and FormComponentPanel to decide whether or not to
override setModel() to make it public.
a TextField would make its setModel() public - because it properly
handles the usecase, correct? so it is still possible for your
developers to call setModel() on a textfield and rewire it so it no
longer links with a model of another component correctly.
so we are now back to square one with the addition that a lot of
components have to override setModel() just to change its visibility
from protected to public - introducing a lot of noise.
im all for making the code better, but i do not think that this change
does. in the end, the developer has to know what the method does if
they chose to call it.
-igor
Sven
On 09/27/2012 07:09 PM, Igor Vaynberg wrote:
i thought the issue we were discussing here is the way the models are
linked...which is not solved by making setdefaultmodelobject
non-public.
-igor
On Thu, Sep 27, 2012 at 10:04 AM, Sven Meier s...@meiers.net wrote:
If you extend GenericPanel you inherit setModel() and getModel(), that's
the
whole purpose of this base class.
You want these two methods, otherwise you wouldn't extend it - there's
nothing to fix.
Component#setDefaultModel() is dangerous because it allows others to
tinker
with your component innards.
I still think limiting access to #setDefaultModel() is a good idea, but
this
is no crucial issue anyway.
Sven
On 09/27/2012 06:16 PM, Michael Mosmann wrote:
Am 27.09.2012 17:51, schrieb Igor Vaynberg:
good point..
-1 from me.. thought it was a good idea, but wasn’t
Michael
so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.
-igor
On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de
wrote:
Am 27.09.2012 17:32, schrieb Igor Vaynberg:
Hi,
.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().
Michael
-1 on changing setDefaultModel().
1) if B panel's model is truly dependent on A's then that dependency
should be expressed:
add(new BPanel(b, new PropertyModel(this, defaultModel));
or do not use the default model slot of B to store the model. that
way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.
2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through
the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:
new DropDownChoice(foo).setModel(bar).setChoices(baz)...
this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.
-igor
On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModelSome model) {
super(id,model);
add(new BPanel(b, model);
}
}
A client using APanel might later change the model, leaving BPanel
working
on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel(b, new PropertyModel(this,
defaultModel)));
But it would be much easier if APanel could assume that its model
isn't
changed unattendedly.
IMHO changing a component's model
Re: WICKET-4780
that class used to have a javadoc that specified it was important that
it is the last mount-related call in init()
-igor
On Mon, Sep 24, 2012 at 7:47 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
https://issues.apache.org/jira/browse/WICKET-4780 shows an interesting
problem with wrapping of request mappers.
The code is:
public void init() {
super.init();
setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
mountPage(/home, HomePage.class);
}
and this leads to:
BufferedResponseMapper is wrapped as part of SystemMapper in CryptoMapper.
Later when mountPage(/home) is called a new CompoundRequestMapper is
created with CryptoMapper as a member and a MountedMapper for HomePage
is prepended to it.
So we have : CompoundRequestMapper(MountedMapper(/home),
CryptoMapper(SystemMapper(BufferedResponseMapper, /* other system
mappers */ )))
When a request with url : home?0 comes MountedMapper(/home) is asked
first and it matches, so BufferedResponseMapper is not asked at all.
Later when starting to render the reported WARN is issued because now
we check for stored response.
The only solution that I see is to do smarter wrapping at
#setRootRequestMapper().
We can split SystemMapper on two sub mappers - one with
RestartResponseAtInterceptPageException.MAPPER and
BufferedResponseMapper (BRM),and another with the rest system mappers
which are also used to generate Urls.
When #setRootRequestMapper() is called we should create such compound
mapper that will always use RRAIPE.MAPPER and BRM before any other
mapper.
Do you see other solutions which are simpler than this one ?
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
[mostly devs] flyouts are dead
we have decided to move away from flyouts because of various ux problems. i have deprecated FlyoutAction and introduced ModalAction which works as a drop in replacement. things to lookout for when doing the migration: when you switch over to modal action you may want to pass in an extra constructor arg that controls the title of the modal. by default it will set the title to the name of the action, but sometimes an action called Edit does not give enough context so use the (Edit, Edit Semester Requirement) constructor. switching over requires some markup tweaks as well. for example, the title (Edit Semester Requirement) above is currently embedded in the flyout markup - so that needs to be removed. also, Leslie has to change some css to make alignment work. if you switch over you have to let her know. actionbar now has closeModal() so when you are done migrating your code change calls to closeFlyout() to use closeModal() instead. i will be slowly moving bits and pieces away from flyouts during my slack time at a rate that wont burden Leslie so i may not get to a lot. i will also only be migrating the actionbar stuff first. we should probably set up tech debt at the end of this itreration to handle the rest of the places. -igor
