Hello all,
I'd like to contribute some patches for wicketstuff-scriptaculous, could
someone please setup a project in the wicketstuff JIRA?
Thanks
Sven
I wouldn't call 6 votes a reason to change an API.
Count me on Leave as is.
Sven
Jan Kriesten schrieb:
Hi,
I counted up the votes for the IDataProvider issue. Undecided votes in
braces:
[ ( ) ] IDataProviderI,T
[ 6 (3) ] IteratorIModelT , drop model
[ 3 (3) ] Leave as is.
So, there
prototype, that's just the examples but i
would not mind using this project instead of including it manually. I
am not sure how much of prototype i use anyway. Guess that is
something to investigate when i clean them up :)
Maurice
On Sun, May 18, 2008 at 11:23 AM, Sven Meier [EMAIL PROTECTED
Hello Richard,
I checked in a first version of wicketstuff-prototype.
It comes with prototype.js version 1.6.0.2. As you suggested the script
can be overriden with a custom resource on Application basis, see:
org.wicketstuff.prototype.PrototypeResourceReference#install(Application,
Resource)
Hello Ryan,
I've created an issue in JIRA and attached a patch, so that
wicketstuff-scriptaculous can utilize wicket-prototype.
BTW
- did you have time to check my other patch for sorting of arbitrary
containers?
- it seems that teamcity has to be adjusted for the new project location
of
So we need wicketstuff-scriptaculous-extensions?
I'm planning to publish a new component next week that depends on
wicketstuff-prototype only.
Do we need an additional wicketstuff-prototype-extensions then?
This might get out of hands - I'd rather keep these minis in minis ;).
Sven
. But then again im
not sure it would bring too much infrastructure.
Sven Meier wrote:
As the initiator of the wicketstuff-prototype project I don't see
much value in utilizing the google loader:
Who want's to depend on google just to load other project's
javascript files?
I can't imagine anyone wanting
Hello Ryan,
what about my patches?
Do you still want to review them or may I check the changes in by myself?
Thanks
Sven
Sven Meier schrieb:
Hello Ryan,
I've created an issue in JIRA and attached a patch, so that
wicketstuff-scriptaculous can utilize wicket-prototype.
BTW
- did you have
/browse/WSCRIPTACULOUS-2
Feel free to check in the changes.
I'd like to hold off on the repeater code for now though. I want to review
that a bit more and try and create a new sortable behavior
On Sun, Jun 15, 2008 at 3:17 PM, Sven Meier [EMAIL PROTECTED] wrote:
Hello Ryan,
what about my
IMHO we shouldn't blame everything on the fact that each component has a
model. I'm working with Wicket for three years now and the whole
component - model relation worked out nicely most of the time.
I won't say that we shouldn't try to improve the matter ;).
So .. what do you have against
to check in the changes.
I'd like to hold off on the repeater code for now though. I want to review
that a bit more and try and create a new sortable behavior
On Sun, Jun 15, 2008 at 3:17 PM, Sven Meier [EMAIL PROTECTED] wrote:
Hello Ryan,
what about my patches?
Do you still want to review
So ObjectModel will hold a single object only? What about lists and
collections?
IMHO the Object.. prefix has no benefit.
Why not drop the Model class altogether?
Its static helper methods could be located in a new non-instantiable
class Models (note the trailing 's') because there's nothing
, Sven Meier s...@meiers.net wrote:
So ObjectModel will hold a single object only? What about lists and
collections?
Are you serious? A collection is still one instance. It doesn't matter
how many references it holds.
-Matej
IMHO the Object.. prefix has no benefit.
Why not drop the Model
My vote counts? Great ;)
+1
On 05/22/2010 09:22 AM, Jeremy Thomerson wrote:
As you may have noticed over the past couple of days (ha), there has been
quite a bit of discussion over what seemed at the time like a very trivial
change in WICKET-2846 [*]. The end result is that it does not break
Hi Jeremy,
IMHO your chart misses two important points:
- string resources from parental components take precedence,
- Wicket mangles string resource keys, e.g.
foo.bar.baz.Required
bar.baz.Required
baz.Required
Regards
Sven
--
View this message in context:
Hi Douglas,
WICKET-3171 describes a problematic case, where visibility of a
component changes while its form is being processed.
In our projects we're overriding isVisible() where appropriate and never
encountered a similar problem.
I'd say WICKET-3171 is the rare 5% usecase. What's next, is
I'm -1 on adding more subclasses to Wicket's type hierarchy.
We have single inheritance in Java, why waste it for something which could
equally well be implemented with behaviors?
Sven
Am 30.11.2010 um 13:18 schrieb Andrea Del Bene:
Same for me. I prefer having new component classes with a
As long as you don't keep a reference to doc, there's no need for a
model.
If you're pulling a lot of fields out of your doc instance (e.g. many
huge strings), your session size could still benefit from a LDM.
Regards
Sven
On Fri, 2010-12-03 at 13:51 -0800, Don wrote:
Does it matter as long
Hi,
I want to work on 1.5 migration for some wicket-stuff core projects.
Could someone grant me commit access please?
User: svenmeier
Thanks
Sven
Hi all,
I've migrated wicket-stuff/jslibraries to Wicket 1.5, further
improvements are in process.
Any objections if I check in the changes?
What I would like to do next:
IMHO we don't need multiple JavaScript integration projects. Thus I want
to deprecate (remove?) wicket-stuff/prototype
I've tried your quickstart and added a comment.
Best regards
Sven
On 06/01/2011 08:09 PM, nino martinez wael wrote:
Any of you taken a look at 3756?
I'm very happy to be part of this incredible team :).
Thanks
Sven
On 06/29/2011 06:30 PM, Igor Vaynberg wrote:
Welcome!
-igor
On Wed, Jun 29, 2011 at 1:19 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
The Wicket PMC is proud to have Sven Meier join our team. Sven has
been active
Well, forcing a specific locale would make life easier for devs who
break the build for another locale ;)
Sven
On 07/06/2011 09:28 PM, Juergen Donnerstag wrote:
Does that mean we'll not detect such issues anymore? I'd much rather
would like maven or jenkins to run all tests with 2 different
Hi all,
I just wanted to move o.a.w.util.time.* related tests from wicket-core
into wicket-util. But apparently there are many more tests (e.g.
StringListTest) located in the 'wrong' wicket module.
Any reason against moving all these tests?
Thanks
Sven
Thanks Martin, I've changed the model to calculate the locale as the
Localizer does it.
Sven
On 07/23/2011 03:22 PM, Martin Grigorov wrote:
On Sat, Jul 23, 2011 at 12:39 PM,svenme...@apache.org wrote:
Author: svenmeier
Date: Sat Jul 23 09:39:15 2011
New Revision: 1150077
URL:
IMHO the decision to split wicket into core, -util and -request should
be reconsidered after 1.5, so for now:
1) -1
2) +1 (if it's possible without a custom plugin)
3) +0
Sven
On 17.08.2011 19:22, Igor Vaynberg wrote:
a lot of energy has gone into discussing and prototyping wicket+osgi
in
...
-igor
On Thu, Aug 18, 2011 at 12:13 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
This is related to the currently running vote about OSGi problem with
split packages in sub-modules (-util, -request and -core).
Sven Meier - today, James Carman - few months ago, and few other
people
I'm +0 on integrating this into 1.5, it could equally well just be put into
wicketstuff. We can still graduate it into Wicket later on.
BTW why is this module named wicket-weld and not wicket-cdi?
Sven
--
View this message in context:
+1 tested examples and other applications - all working fine.
Sven
On 08/23/2011 07:31 PM, Igor Vaynberg wrote:
This vote is to release wicket 1.5-RC6
Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC6/
Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC6/dist/
+1
Sven
On 08/24/2011 05:53 PM, Igor Vaynberg wrote:
This vote is to release wicket 1.5-RC7
Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC7/
Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC7/dist/
Maven repo:
+1 ,RC7 fixed the last outstanding issue for our applications.
Sven
On 08/29/2011 10:39 PM, Igor Vaynberg wrote:
this vote is to promote 1.5-RC7 to 1.5.0.
current bug fixes already made to trunk will be part of 1.5.1
this vote ends Thursday, September 1st at 2pm GMT-7
-igor
#. rework Wicket components: ModalWindow, Wizard and Trees
#. try to boil down Wicket core to its essentials (e.g. without most
components)
Sven
On 08/30/2011 12:12 AM, Martijn Dashorst wrote:
In order to start discussing what will constitute Wicket Next and
where we want to take our beloved
+1
On 09/05/2011 02:24 PM, Martijn Dashorst wrote:
+1
On Sun, Sep 4, 2011 at 7:15 PM, Pedro Santos pedros...@gmail.com wrote:
+1
2011/9/4 jcgarciam jcgarc...@gmail.com
+1
On Sun, Sep 4, 2011 at 6:01 AM, Peter Ertl-3 [via Apache Wicket]
ml-node+3788932-1962192371-65...@n4.nabble.com
+1
Sven
-Ursprüngliche Nachricht-
Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Gesendet: Donnerstag, 10. November 2011 17:42
An: dev@wicket.apache.org
Betreff: Re: [vote] release wicket 1.5.3
+1
-igor
On Wed, Nov 9, 2011 at 12:14 PM, Igor Vaynberg igor.vaynb...@gmail.com
Pull requested.
Sven
On 12/11/2011 02:35 AM, Jeremy Thomerson wrote:
If anybody here has ten minutes available to help me test some GitHub
features, please see [1] and complete the first batch of steps. Basically,
fork that repo, add a commit or two, and then create a pull request for me.
Gabriel Landon:
I would love to have a refactor of the Treegrid (see
https://issues.apache.org/jira/browse/WICKET-1600 WICKET-1600 ) implemented
with the http://code.google.com/p/wicket-tree/ wicket-tree implementation
Sven Meier has done.
It would be very nice to use a TreeProvider instead
Hi Jeremy,
Thoughts about moving your tree to wicket-extensions
yes, ultimately the new implementation from wicket-tree will be part of
wicket-extensions.
IMHO it's just a matter of timing, so this rework doesn't delay the next
Wicket release and we get enough feedback on the new
If so I'll start working on WICKET-4240 next week.
Sven
On 12/29/2011 06:49 PM, Igor Vaynberg wrote:
imho we should put it into wicket 6. wicket 7 will be far off...
-igor
On Thu, Dec 29, 2011 at 9:21 AM, Sven Meiers...@meiers.net wrote:
Hi Jeremy,
Thoughts about moving your tree to
Welcome :)
Sven
On 12/30/2011 04:26 PM, Emond Papegaaij wrote:
Thank you all for the confidence you have in my work! I'm really proud to be a
member of the Wicket team and am looking forward to get some real work done.
I've already pushed some patches for a few tickets, broke most testcases
Seems superfluous, thus +1 for removing crufty code.
Sven
Am 03.01.2012 17:06, schrieb Igor Vaynberg:
seems like a leftover from the time past. +1 to remove.
-igor
On Tue, Jan 3, 2012 at 7:27 AM, Martin Grigorovmgrigo...@apache.org wrote:
Hi,
What is the use case for supporting the
There are a few places where the active or next requestHandler is looked
up by type. This could be:
T extends IRequestHandler T RequestCycle#resolveHandler(ClassT)
This would result in a little more typing though, e.g. for Ajax:
RequestCycle.get().resolveHandler(IAjaxRequestHandler.class)
+1
Am 10.01.2012 20:03, schrieb Igor Vaynberg:
This vote is to release wicket 1.5.4
Branch
http://git-wip-us.apache.org/repos/asf/wicket/?p=wicket.git;a=shortlog;h=refs/heads/build/wicket-1.5.4
Artifacts
http://people.apache.org/~ivaynberg/wicket-1.5.4/dist/
Maven repo
+1
On 01/19/2012 06:04 PM, Jeremy Thomerson wrote:
+1
On Thu, Jan 19, 2012 at 11:47 AM, Igor Vaynbergigor.vaynb...@gmail.comwrote:
+1
-igor
On Tue, Jan 17, 2012 at 8:34 PM, Igor Vaynbergigor.vaynb...@gmail.com
wrote:
This vote is to release wicket 1.5.4 take 3
Branch
I don't know the reason for this. Let's change it for 1.5.x too.
Sven
Am 30.01.2012 13:35, schrieb Martin Grigorov:
Hi devs,
At https://issues.apache.org/jira/browse/WICKET-4356 the reporter asks
a reasonable question: why toXyz(default) throws a FormatException
instead of returning the
imho simpler to put a form inside modal's panel and call it a day
IMHO the modalwindow-form requirement is weird. It's counter-intuitive and
inelegant - just look at all the html elements created in modal window's js.
It breaks encapsulation: Why should I put the modal window into a form,
Anybody knows the reason why IPageParametersEncoder's methods are
asymetrical:
Url encodePageParameters(PageParameters pageParameters);
PageParameters decodePageParameters(Request request);
Shouldn't that be:
Url encodePageParameters(PageParameters pageParameters);
Hi Martin,
new Tree impl
I'll still have to do minor cleanups and javadoc, but no api changes.
WICKET-3927 I think this one can be closed.
Agreed.
WICKET-2128 I agree that ${label} should be used
IIRC the reason for using ${input} is that the label isn't necessarily
set on the component.
Page parameters are for GET parameters only, which is obvious in the
following signature:
Url encodePageParameters(PageParameters pageParameters);
IMHO WICKET-4338 should be reverted.
Sven
Am 23.02.2012 08:45, schrieb Martin Grigorov:
Hi,
I think it works with Request to be able
Hi all,
apparently UrlEncoder doesn't encode the at-sign @, line #189:
dontNeedEncoding.set('@');
The comment copied from java.net.URLEncoder states however:
As a last note, Intenet Explorer does not encode the @
character which is clearly not
unreserved according to
Hi Dan,
actually I've reread the current URI specification
(http://tools.ietf.org/html/rfc3986) and @ *is* allowed in path and query.
I've had problems with reading a request from an external site, which
insists on sending encoded @s. I solved the problem by handling the
request in a custom
Tested examples and our current application ... +1
Sven
On 03/07/2012 05:42 PM, Peter Ertl wrote:
+1
Am 07.03.2012 um 17:27 schrieb Igor Vaynberg:
+1
-igor
On Mon, Mar 5, 2012 at 9:42 AM, Igor Vaynbergigor.vaynb...@gmail.com wrote:
This vote is to release wicket 1.5.5
Branch
I had a lot of request recently whether to wait for Wicket 6 instead of
migrating to 1.5.x.
Seems there are a lot of projects still running on 1.4.x, so I'm all in
favor of a milestone soon.
Hopefully this will bring people to speed with their upgrade plans.
Sven
On 03/20/2012 09:39 AM, Emond
+1
Sven
On 03/21/2012 04:46 PM, Juergen Donnerstag wrote:
+1
Juergen
On Wed, Mar 21, 2012 at 11:57 AM, Emond Papegaaij
emond.papega...@topicus.nl wrote:
+1 for release, +1 for beta
On Tuesday 20 March 2012 12:21:38 Igor Vaynberg wrote:
+1 for release, +0 for beta vs milestone.
-igor
On
+1
On 03/25/2012 04:31 PM, Martin Grigorov wrote:
+1
tested wicket-examples and the quickstart archetype
On Fri, Mar 23, 2012 at 2:33 PM, Martin Grigorovmgrigo...@apache.org wrote:
This vote is to release wicket 6.0.0-beta1.
This is the first release of 6.x branch and its purpose is to get
Hi Juergen,
I double checked with how other filters/resolvers are doing it and I
found AutoLabelTextResolver to leave the tag id untouched too.
May be a Component's flag bit can be used for that purpose.
Shouldn't that be a flag on the markup tag instead then?
I don't know how likely it is
Hi,
An artifical markup which creates duplicate IDs can be constructed.
all auto labels' tags have the same id already (its class name) so no
need to create some artificial markup.
To me the applied patch leaves us with a bigger problem than it fixes.
If the id of the tag in the cached
the render (I dont know wicket internals well enough to
tell) or stored in the page store. If they do, its a big memory leak.
At the very least its spews out huge amounts of data in the debug
logging.
Cheers,
Jesse
On 29/03/2012 22:39, Sven Meier wrote:
Hi,
An artifical markup which
/2012 22:39, Sven Meier wrote:
Hi,
An artifical markup which creates duplicate IDs can be constructed.
all auto labels' tags have the same id already (its class name) so no need
to create some artificial markup.
To me the applied patch leaves us with a bigger problem than it fixes.
If the id
point, but lets fix the problem
properly and not introduce a bug with an enhancement.
Juergen
Cheers,
Jesse
On 29/03/2012 22:39, Sven Meier wrote:
Hi,
An artifical markup which creates duplicate IDs can be constructed.
all auto labels' tags have the same id already (its class name) so no
need
and not introduce a bug with an enhancement.
Juergen
Cheers,
Jesse
On 29/03/2012 22:39, Sven Meier wrote:
Hi,
An artifical markup which creates duplicate IDs can be constructed.
all auto labels' tags have the same id already (its class name) so no
need
to create some artificial markup.
To me
The listener won't be set in IFrameworkSettings by default, right?
IMHO it's better located in extensions then.
Sven
On 04/07/2012 01:37 AM, James Carman wrote:
Add the listener to core and if folks want to use it they can. You could
have a component instantiation listener add the detach
Once this is introduced you can't turn it off.
You might use some components which depend on their models being
detached externally, without you even being aware of it.
Sven
On 04/08/2012 12:15 PM, Johan Compagner wrote:
i think it would be fine to have something like this, and enabled by
Hi Martin,
IMHO we shouldn't touch grouping in display of numbers (e.g. in labels),
so -1 for changing it globally.
BTW if somebody registered his own converter for numbers, he would again
have to take care of grouping by himself.
Instead we could
3)
Skip converters and do formatting of
((AbstractDecimalConverter?)converter).getNumberFormat(getLocale()).setGroupingUsed(false);
will set the flag on a NF instance which will be thrown away immediately.
Right, I should have tried that out first :/.
do formatting of values in NTF explicitly
What do you mean with this ?
BTW I didn't say I prefer the solution without converters ;).
I just wanted to offer alternatives to the global grouping change.
Sven
On 04/20/2012 06:32 PM, Sven Meier wrote:
((AbstractDecimalConverter?)converter).getNumberFormat(getLocale()).setGroupingUsed(false);
will set the flag
Hi Christoph,
It wouldn't be a no-op if you stored the modified NumberFormat in the
cache:
this would change the grouping for all numberformats cloned in
succession by the converter, wouldn't it?
This is the same as changing the grouping globally.
Sven
On 04/22/2012 05:58 PM, Christoph
Welcome Carl-Eric :)
On 04/26/2012 11:55 AM, Martijn Dashorst wrote:
Carl-Eric Menzel has been invited to join the Wicket team. Please
welcome Carl-Eric!
Martijn Dashorst
+1 for 1.5.6
Sven
On 04/30/2012 10:05 PM, Martin Grigorov wrote:
Can someone of the Wicket devs verify the problem and cancel the release?
Or +1 it otherwise ...
P.S. I'm on vacation without IDEs around :-)
On Sun, Apr 29, 2012 at 1:34 PM, Sebastienseb...@gmail.com wrote:
We're probably talking about WICKET-453*2*, IMHO it can still be
improved for the next 6.0 beta.
Sven
On 05/05/2012 07:00 PM, Emond Papegaaij wrote:
The ticket you mentioned is already fixed in 6.0. I fixed it right after
filing it.
Best regards
Emond
Op 5 mei 2012 14:16 schreef Peter
+1 for 1.5.7
Sven
On 05/28/2012 11:59 AM, Martin Grigorov wrote:
Hi,
We've found a quite serious problem in DiskDataStore internals -
https://issues.apache.org/jira/browse/WICKET-4572.
In case the disk space per http session is exhausted it may lead to
Wicket returning the wrong page instance
Hi Michael,
you can count me in too!
Username: svenmeier
Best regards
Sven
On 05/31/2012 09:03 AM, Martin Grigorov wrote:
Hi Michael,
On Thu, May 31, 2012 at 5:14 AM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
Hello,
I've been doing the wicketstuff-core builds since May 2010
+1 for the second build
Sven
On 05/30/2012 04:05 PM, Martin Grigorov wrote:
This vote is to release Apache Wicket 1.5.7
Git repo
http://git-wip-us.apache.org/repos/asf/wicket.git
Branch name
build/wicket-1.5.7
Archived and signed Git repo
http://people.apache.org/~mgrigorov/wicket-1.5.7/
With that change I wanted to improve consistency of ResourceNameIterator.
Yes, we have a regression now. But IMHO it was pure luck that this 'bug'
happened to work in 1.5.x
Sven
Martin Grigorov (JIRA) j...@apache.org schrieb:
[
[+1] Copy ...
Sven
Martijn Dashorst martijn.dasho...@gmail.com schrieb:
My vote:
[+1] Copy RfcCompliantEmailAddressValidator over
EmailAddressValidator, deprecate RfcCompliantEmailAddressValidator
[ ] Deprecate EmailAddressValidator, move
RfcCompliantEmailAddressValidator to core, favor RFC in
+1
The filter looks useful to me and I don't see a problem with the limitation.
Sven
Jeremy Thomerson jer...@wickettraining.com schrieb:
All,
I created this blog post [1] last year and in quite a few of my Wicket
classes people ask about how to do this same thing. I can commit it to
core in
Can't you just use #getChainedModel()?
Sven
Greg Johnson greg.john...@saltaire.com.au schrieb:
hi,
for some validator use cases public getTarget() in AbstractPropertyModel was
important for access to the parent object, eg for cross field validation.
this is now not possible in 6.x as
+1
Sven
On 08/21/2012 05:03 PM, Igor Vaynberg wrote:
+1
-igor
On Tue, Aug 21, 2012 at 1:14 AM, Martin Grigorov mgrigo...@apache.org wrote:
This vote is to release Apache Wicket 1.5.8
Git repo
http://git-wip-us.apache.org/repos/asf/wicket.git
Branch name
build/wicket-1.5.8
Archived and
+1 release
Sven
On 08/23/2012 11:13 PM, Martijn Dashorst wrote:
No fuzz, no separate RC releases. This is the real deal.
Please vote for releasing the following source artifacts after
checking them thoroughly for any misgivings:
- tag: wicket-6.0.0
- release branch: builds/wicket-6.0.0
Still there:
https://github.com/apache/wicket/blob/build/wicket-1.5.8/wicket-extensions/src/main/java/org/apache/wicket/extensions/markup/html/repeater/data/table/ISortableDataProvider.java
Sven
On 08/25/2012 06:51 PM, nunofaria11 wrote:
Hi, Is SortableDataProvider not available in 1.5.8?
Hi,
I've just noticed, that the Ajax log in Wicket 6 doesn't show the full
response structure any more, e.g. just the text without ajax-response,
component and evaluate tags.
This is due to line #680 in wicket-ajax-jquery.js :
var responseAsText = jQuery(data).text();
Was this change
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
might not got
the whole picture, a *protected* would suffice for that.
Sven
On 09/27/2012 02:22 PM, Michael Mosmann wrote:
Am 27.09.2012 14:19, schrieb Sven Meier:
IMHO changing a component's model isn't the wicket way so I'd
suggest changing the visibility of Component#setDefaultModel
: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
, 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
to call it.
Agreed.
Just one little nitpick: In my scenario it's two developers, one who has to
safeguard against another developer calling a method he isn't suppose to call.
Sven
On 09/27/2012 08:59 PM, Igor Vaynberg wrote:
On Thu, Sep 27, 2012 at 10:49 AM, Sven Meier s...@meiers.net wrote
this will make more advanced developer more unconfortable
I hear that ;).
Jeremy gave a good suggestion: set up some kind of code-check
Sven
On 09/27/2012 09:38 PM, Martin Grigorov wrote:
On Thu, Sep 27, 2012 at 10:29 PM, Sven Meier s...@meiers.net wrote:
lets take a concrete example
+1 built from source archive and checked some examples
Sven
On 10/01/2012 09:41 AM, Martijn Dashorst wrote:
+1. I've built from the release sources, checked the binary
compatibilty and didn't find any issues.
The discovered bugs/regressions are unfortunate, but in 3 weeks is a
new release
[X] Yes, release Apache Wicket 6.2.0
Sven
On 10/19/2012 10:10 PM, Martijn Dashorst 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.
Give your DropDownChoice a model to write to. See DropDownChoicePage in
wicket-examples for a usage with CompoundPropertyModel.
Sven
On 10/20/2012 11:49 AM, cipriano garcia Hernandez wrote:
rg.sakaiproject.portal.api.PortalHandlerException:
org.apache.wicket.WicketRuntimeException: Method
Can someone explain me why you are using the data field to store the IModel?
Memory optimization.
when we look at all the access to the get method we can see that it excludes
always
the first element if the model is set.
If the model is set, Components knows it to be at index 0:
I agree, it would be better placed in wicket-authroles.
Sven
On 10/25/2012 07:19 PM, Jesse Long wrote:
Hi all,
IAuthenticationStrategy is pretty much only used by wicket-authroles.
This was enough cause to get Session#authenticate kicked out.
Also, the interface makes some assumptions
which is actually an example or roll your
own impl.
And the recent poll by Jeremy showed that many users use home backed solutions.
On Fri, Oct 26, 2012 at 10:21 AM, Sven Meier s...@meiers.net wrote:
I agree, it would be better placed in wicket-authroles.
Sven
On 10/25/2012 07:19 PM, Jesse Long
perfectly
into wicket-auth-roles (and is used there only).
Sven
On 10/26/2012 10:28 AM, Martin Grigorov wrote:
On Fri, Oct 26, 2012 at 11:20 AM, Sven Meier s...@meiers.net wrote:
Why not to improve it ?
Sure, we can improve it.
But for now it's just an ugly interface (see the #load() method
Grigorov wrote:
On Fri, Oct 26, 2012 at 11:34 AM, Sven Meier s...@meiers.net wrote:
I don't want to promote wicket-auth-roles to be something more
than example but moving IAuthenticationStrategy there will help for this.
Ok, now I understand. Perhaps time to move wicket-auth-roles to
wicket-examples
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
+1 Makes sense to me.
(If anyone else is wondering too: Component doesn't implement
IDetachable because if it did, we'd run in an infinite loop when models
reference components.)
Sven
On 11/13/2012 03:58 PM, Martin Grigorov wrote:
Hi,
The debug panel in wicket-devutils uses
+1 yes, release
Checked signature, build and examples.
Sven
On 11/16/2012 03:23 PM, Martijn Dashorst wrote:
+1
Tested the examples, quickstart, compilation of the source package,
signatures, and the CLIRR didn't report any issues.
Martijn
On Fri, Nov 16, 2012 at 3:09 PM, Martijn Dashorst
- assertEquals(encöding, actual);
+ assertEquals(enc\u00f6ding, actual);
Why this change is needed ?
A problem with platform encoding where the tests run?
I don't think it is really needed. But I know a company where the encoding of
all Java sources is switched
If so can we mark the issue fixed?
Now it is.
Sven
On 12/14/2012 04:27 PM, Martijn Dashorst wrote:
Should this be included in 6.4? If so can we mark the issue fixed?
Martijn
On Fri, Dec 14, 2012 at 4:19 PM, svenme...@apache.org wrote:
Updated Branches:
refs/heads/master 1f5989f54 -
[+1] Yes, release Apache Wicket 6.4.0
Ran examples and tested distribution in my applications.
Sven
On 12/14/2012 05:24 PM, Martijn Dashorst wrote:
Please download the source distributions found on my people.apache.org
distribution area linked below.
I have included the signatures for both
1 - 100 of 636 matches
Mail list logo
