Re: [vote] Revert WICKET-2846
[X ] +1 - revert WICKET-2846 in the next release (in other words, get rid of the InheritableThreadLocal) While there's a chance of not being able to avoid the thread problem due to it being in an 3rd-party code AND there's a workaround for what 2846 is doing, then it doesn't seem to be a good idea to include it. /Gwyn
Re: [vote] release wicket 1.3.7
[X] Yes release 1.3.7 /Gwyn
Re: [vote] release wicket 1.4.0
[X] Yes release 1.4.0 /Gwyn
Re: wicket blogs
Done - site should update shortly, I believe... /Gwyn On Wed, Mar 25, 2009 at 4:54 PM, Michael Mosmann mich...@mosmann.de wrote: Hi, can someone add my blog to the wicket blogs page? http://www.wicket-praxis.de/blog/ thank you:) michael mosmann
Re: security article on TSS (partly covering wicket)
I could be wrong, but it looked to me as if they were saying that if you used hidden fields, then there was a potential insecurity as they could be changed by the user. I guess you trap that by automatically generating an additional hidden field containing a hash of the other hidden fields along with a randomly initialised salt value, then check they when they get received... /Gwyn On Thu, Jul 31, 2008 at 7:09 PM, Korbinian Bachl - privat [EMAIL PROTECTED] wrote: Hi, its *not* my opinion - I just read the article and thought you might want to know about it. I mean, beside that, it seems as wicket is very secure in comparision to the other frameworks mentioned there - Honestly, I dont know why this harsh reactions (other mails) came. Best, Korbinian Martijn Dashorst schrieb: How is HiddenField insecure in your opinion? Martijn On Wed, Jul 30, 2008 at 10:59 PM, Korbinian Bachl - privat [EMAIL PROTECTED] wrote: HI, under http://www.theserverside.com/tt/articles/article.tss?l=AreJavaWebApplicationsSecure is an article covering java WebApps security; On part 2 it also looks at webframeworks for java including wicket 1.3.x - it mentions Wicket has only one component (HiddenField) vulnerable to integrity attacks. maybe this gap could be closed? Also the rest seems aso quite interesting. Best, Korbinian
Re: [vote] release wicket-1.3.4
[X] release wicket 1.3.4 /Gwyn
Re: Kittens got approved through lazy consensus
Well, from my POV, -core would be for things that are licenced under the Apache licence, likely to be used in a majority of projects are intended to be supported by the core team, -extensions is for things that are licenced under the Apache licence, likely to be used in a significant number of projects are intended to be supported by the core team, while -stuff does not require Apache licencing and is not specifically supported by the core team. (As an aside, we don't seem to have anything obvious on the main site mentioning the various modules, extentions or stuff - Must try remember to see if I'm overlooking something...) One issue with using -stuff for this would be that at the moment, the licencing is such that it can be easily put into -extensions, whereas to put it into -stuff then later 'promote' it to -extensions would require a certain amount of re-doing of the work. On the other hand, if it goes into -extensions, it seems to me that /if/ it were to be too much of a drain on resources (which would seem to be the only reason to do so), it whould be relatively easy to move it 'out' to -stuff at a later date. /Gwyn On Tue, Jun 3, 2008 at 9:16 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: +1 for extensions +2 for wicketstuff I'd still like a clear definition on when what goes where.. Thats when is wicketstuff appropriate and when are extensions and when are wicket core appropriate. Martijn Dashorst wrote: The IP clearance for the kittens got approved through lazy consensus. Now we can integrate the kittens into our project. I believe the target was extensions? Martijn -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684
Fwd: Quote replacement in document prologue?
Commit or not?
Index: src/main/java/org/apache/wicket/Page.java
===
--- src/main/java/org/apache/wicket/Page.java (revision 658674)
+++ src/main/java/org/apache/wicket/Page.java (working copy)
@@ -1372,9 +1372,13 @@
if ((markupStream != null) (markupStream.getXmlDeclaration()
!= null)
(application.getMarkupSettings().getStripXmlDeclarationFromOutput()
== false))
{
- response.write(?xml version='1.0' encoding=');
+ // Gwyn - Wed, 21 May 2008 12:23:41
+ // If the xml declaration in the markup used
double-quotes, use
them in the output too
+ // Whether it should be or not, sometimes it's
significant...
+ char quoteChar =
(markupStream.getXmlDeclaration().indexOf('\')
== -1) ? '\'' : '\';
+ response.write(?xml version= + quoteChar + 1.0 +
quoteChar +
encoding= + quoteChar);
response.write(encoding);
- response.write('?);
+ response.write(quoteChar + ?);
}
// Set response locale from session locale
-- Forwarded message --
From: Gwyn Evans [EMAIL PROTECTED]
Date: Wed, May 21, 2008 at 12:23 AM
Subject: Re: Quote replacement in document prologue?
To: [EMAIL PROTECTED]
Ah - org.apache.wicket.Page#configureResponse doesn't take account of
the specified template, just uses it's hard-coded one... Tomorrow...
/Gwyn
On Wed, May 21, 2008 at 12:10 AM, Gwyn Evans [EMAIL PROTECTED] wrote:
Just noticed that even though I specify a prologue as:
?xml version=1.0 encoding=UTF-8?
it gets delivered as:
?xml version='1.0' encoding='UTF-8'?
Anyone able to point me to where this is happening, as the particular
document spec variant I'm trying to work to here requires the
former...
/Gwyn
Re: Quote replacement in document prologue?
https://issues.apache.org/jira/browse/WICKET-1652
On Wed, May 21, 2008 at 9:41 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
Looks good to me. Maybe create a JIRA issue as well?
Eelco
On Wed, May 21, 2008 at 6:22 AM, Gwyn Evans [EMAIL PROTECTED] wrote:
Commit or not?
Index: src/main/java/org/apache/wicket/Page.java
===
--- src/main/java/org/apache/wicket/Page.java (revision 658674)
+++ src/main/java/org/apache/wicket/Page.java (working copy)
@@ -1372,9 +1372,13 @@
if ((markupStream != null)
(markupStream.getXmlDeclaration() != null)
(application.getMarkupSettings().getStripXmlDeclarationFromOutput()
== false))
{
- response.write(?xml version='1.0' encoding=');
+ // Gwyn - Wed, 21 May 2008 12:23:41
+ // If the xml declaration in the markup used
double-quotes, use
them in the output too
+ // Whether it should be or not, sometimes it's
significant...
+ char quoteChar =
(markupStream.getXmlDeclaration().indexOf('\')
== -1) ? '\'' : '\';
+ response.write(?xml version= + quoteChar + 1.0
+ quoteChar +
encoding= + quoteChar);
response.write(encoding);
- response.write('?);
+ response.write(quoteChar + ?);
}
// Set response locale from session locale
-- Forwarded message --
From: Gwyn Evans [EMAIL PROTECTED]
Date: Wed, May 21, 2008 at 12:23 AM
Subject: Re: Quote replacement in document prologue?
To: [EMAIL PROTECTED]
Ah - org.apache.wicket.Page#configureResponse doesn't take account of
the specified template, just uses it's hard-coded one... Tomorrow...
/Gwyn
On Wed, May 21, 2008 at 12:10 AM, Gwyn Evans [EMAIL PROTECTED] wrote:
Just noticed that even though I specify a prologue as:
?xml version=1.0 encoding=UTF-8?
it gets delivered as:
?xml version='1.0' encoding='UTF-8'?
Anyone able to point me to where this is happening, as the particular
document spec variant I'm trying to work to here requires the
former...
/Gwyn
test - sorry, please ignore
test - 'to' is definately 'dev@wicket.apache.org'...
Re: test - sorry, please ignore
Had some emails that I expected to show up here going to one of the incubator lists - suppose it could be finger trouble but I normally just type 'dev' into GMail's popup I'd have have to type 'wicket-dev' instead... /Shrugs On Tue, May 20, 2008 at 9:01 AM, Johan Compagner [EMAIL PROTECTED] wrote: it works! On Tue, May 20, 2008 at 9:53 AM, Gwyn Evans [EMAIL PROTECTED] wrote: test - 'to' is definately 'dev@wicket.apache.org'...
WICKET-1627 (1624/ 1580) WICKET-1643 (was Fwd: [VOTE] Release Apache Wicket 1.4 M2)
Appears to be a reasonable POV - any reason (other than time!) not to apply these? /Gwyn -- Forwarded message -- From: Doug Donohoe [EMAIL PROTECTED] Date: Mon, May 19, 2008 at 3:00 PM Subject: Re: [VOTE] Release Apache Wicket 1.4 M2 To: dev@wicket.apache.org I vote not to. I have submitted two outstanding patches that have not been committed yet. These patches fix a total of 4 bugs. https://issues.apache.org/jira/browse/WICKET-1627 (includes 1624 and 1580) https://issues.apache.org/jira/browse/WICKET-1643 The longer these patches are not committed, the harder it is for me to continue to contribute to wicket since my tree is out-of-sync with the main tree. -Doug Frank Bille wrote: Hi all, Second milestone release of Wicket 1.4 has been build. The distribution artifacts can be downloaded from here: http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m2/dist/ The maven staging repository can be found here: http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m2/m2-repo/ There is also a RAT report for the distribution: http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m2/apache-wicket-1.4-m2.rat The artifacts has been signed with my (Frank Bille) public key which can be found in the keys file: http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m2/KEYS I have tested the following: * mvn clean install the distribution/src * Check the RAT file. Can't see anything new * Various testing in wicket-examples (winxp+ie6, winxp+ie7, macosx+safari) Frank [ ] +1 Release Apache Wicket 1.4 Milestone 2 [ ] -1 Don't release, because... -- View this message in context: http://www.nabble.com/-VOTE--Release-Apache-Wicket-1.4-M2-tp17308649p17316717.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release Apache Wicket 1.4 M2
On Mon, May 19, 2008 at 5:01 PM, Doug Donohoe [EMAIL PROTECTED] wrote: I spent the better part of last week tracking down and fixing these bugs. I don't want to see this work go to waste. Can you please take a look at these patches? Looks like Johan will be doing that, see other thread. It would be a shame to miss the 1.4 release altogether, which is what you seem to be suggesting. No, I think that the 1.4 comments were specifically about not wanting to block a 1.4 /milestone/ release, not a 1.4 release itself. /Gwyn
Re: [vote] accept kitten-captcha into Apache Wicket
On Sun, May 18, 2008 at 7:22 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: [X] yes, accept kitten-captcha into Wicket /Gwyn
Re: Avoiding Relative URL tweaking...
Thanks - turns out that doing that's not enough, as it's also added to
the list of MarkupFilterChains set in
org.apache.wicket.markup.MarkupParser, so it adds a
_relative_path_prefix_, causing a MarkupException: Unable to find
component... later!
As an alternative, I was able to get somewhere by overriding
WebApplication.newWebRequest as below, although I do need to split the
app...
protected WebRequest newWebRequest(HttpServletRequest servletRequest) {
return new ServletWebRequest(servletRequest) {
public String getRelativePathPrefixToContextRoot() {
return ;
}
};
}
/Gwyn
On Tue, May 13, 2008 at 4:24 PM, Johan Compagner [EMAIL PROTECTED] wrote:
maybe
IPageSettings
public ListIComponentResolver getComponentResolvers()
{
return componentResolvers;
}
and then remove the one RelativePathPrefixHandler?
On Tue, May 13, 2008 at 5:07 PM, Gwyn Evans [EMAIL PROTECTED] wrote:
Any thoughts on the best way to avoid the URL prefixing by
RelativePathPrefixHandler?
I'm trying to use Wicket to serve some basic WML pages, one feature of
which is that there might be a href value of !id!... being used,
where the !id! should be treated as an absolute URL prefix. The
issue I have is that I don't want it processed to 'href=../../!id!'
which it is at the moment.
A pre-request/page solution would be the ideal, as I'm also serving
HTML pages from the same app, but could easily split the app into two
if that's simpler that way...
/Gwyn
Re: Build server - java 6?
I think we're saying the class files are 1.5 compatible, it's just the 1.6 run-time libs do certain (undefined) orderings differently, isn't it? /Gwyn On Sun, May 4, 2008 at 9:40 PM, Johan Compagner [EMAIL PROTECTED] wrote: But we cant build with java 6 or can we say that class files are 1.5?? The snapshots shouldnt be suddenly 1.6 only On 5/4/08, Martijn Dashorst [EMAIL PROTECTED] wrote: Yes, and that is why I think Java 6 would be a benefit to the server: 1. to fix the tests 2. to make sure they stay fixed :) Martijn On 5/4/08, James Carman [EMAIL PROTECTED] wrote: Don't the test cases fail with 1.6? On Sun, May 4, 2008 at 12:08 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: I know we have to compile everything using Java 5. But as many of our users are running Java 6 already, perhaps we should add a testing build profile that builds Wicket using Java 6. One problem: we don't have Java 6 installed on the box. (Java 6 would also be a big improvement performance wise I think) Should we install java 6? And if so, who is going to do so? Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
Re: Build server - what do we do?
I'd suggest having a look at getting at least one project running under Hudson, just so you've got a comparison. I've used it locally in the past found it nice easy, but not for a while now - It's still the one I'd try first, though. /Gwyn On Sat, May 3, 2008 at 1:21 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Status: - build server: teamcity professional, is operational, will ask for an open source license if we decide to go with teamcity - confluence: upgraded to 2.8, operational - wicket examples (dojo, 12, 13, security, inmethod): operational - teatime operational (##wicket logs) - jira - not operational, doesn't want to start up, fails with classdef not found Before we open up the flood gates to all projects to setup team city, I'd like to get some opinions first. Since we currently have 20 or so accounts, I'd like to get some volunteers to setup a couple of projects and see how the server behaves with more projects. Martijn
Re: wicket iolite
Hmm - I had some problems myself running it, but I'm not sure if that was Maven or what... I normally have a corporate proxy repo (running Artifactory) as a mirror, but I needed to remove that before I could get it downloaded but having done so, it's looking interesting, so thanks! /Gwyn On Wed, Apr 30, 2008 at 11:42 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Okay thanks:) Just me screwing around and forgetting params.. David Bernard wrote: use -DremoteRepositories=http://wicketstuff.org/maven/repository it works on my box /davidB On Wed, Apr 30, 2008 at 7:29 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Anybody got any clues? IT does work when using it locally, I guess it would work too if I got it published to maven central repo.. Nino Saturnino Martinez Vazquez Wael wrote: nope it's still the same using this command line: mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-iolite -DarchetypeVersion=1.3-SNAPSHOT -DremoteRepositories= http://wicketstuff.org/maven -DgroupId=com.mycompany -DartifactId=ioliteTest01 Works like a snug if I install the archetype and run it locally... David Bernard wrote: Nino, it's a bug with the version 2 of maven-archetype-plugin. try with an explicit version mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create /davidB Nino Saturnino Martinez Vazquez Wael wrote: I am of course only asking about 2, as it seems that we will have to wait for the next release of maven to helpout with number 1.. Nino Saturnino Martinez Vazquez Wael wrote: Hi Im having trouble on serveral front's with the upcomming archetype wicket iolite[1]. Problems 1. multiple projects in a archetype (currently im including all source as resources, which makes it unable to use specified packagenames) 2. I cant seem to use the archetype directly from wicketstuff maven Im using this command line with maven: mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-iolite -DarchetypeVersion=1.3-SNAPSHOT -DremoteRepositories= http://wicketstuff.org/maven^ -DgroupId=com.mycompany -DartifactId=myproject In bamboo I've entered this mvn clean deploy -U, and I can see that the archetype are available at wicketstuf[2]. I've also entered the distribution management in my pom: distributionManagement snapshotRepository idrepo/id nameLocal Bamboo/Tomcat repository/name url file:/home/wicket/tomcat/webapps/maven/repository/ /url uniqueVersionfalse/uniqueVersion /snapshotRepository repository idrepo/id nameLocal Bamboo/Tomcat repository/name url file:/home/wicket/tomcat/webapps/maven/repository/ /url uniqueVersionfalse/uniqueVersion /repository /distributionManagement So the question are what's wrong? [1]= http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Iolite [2] http://wicketstuff.org/maven/repository/org/apache/wicket/wicket-archetype-iolite/ -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684
Firefox beta ExternalLink
I'm having an issue with the above wanted to see if anyone's able to comment... (I can't get to IRC at the moment, or I'd probably have tried there). The Wicket connection is that the JavaScript is that generated by ExternalLink, so fairly fundamental... The issue is that when I try use a button to link off to an external page, (it's just a form with a button with an onclick=window.location.href='http://news.bbc.co.uk/text_only.stm'), it works in IE FF 2, but not in FF 3b5. I've disabled AdBlockPlus Firebug checked everything else, but with 3beta5, clicking the button just reloads the page - nothing appearing in the FF Error Console. Anyone got an ExternalLink they can test in FF 3beta5 to see if it's just me? /Gwyn
Re: [vote] establish a [EMAIL PROTECTED] mail list
On 29/01/2008, Martijn Dashorst [EMAIL PROTECTED] wrote: I propose to create a new focused mailing list to give these efforts a breathing space and to lessen the traffic on the user list for organizing these events. This list will also be archived by Apache, and we'll give it a place on nabble as well. -0 I don't think that it would solve anything, as announcements would still be cross-posted not enough people would jump through the hoops to join another mailing list. /Gwyn
Re: Status - 1.3.1
+1 /Gwyn On 29/01/2008, Frank Bille [EMAIL PROTECTED] wrote: I think we should release 1.3.1 now, since there has been quite a few serious fixes. I have time to build it tomorrow. WDYT? Frank On Jan 20, 2008 7:42 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: Can everybody please take a look at our JIRA for 1.3.1 and close items that were already resolved, and move tasks/features/improvements to 1.3++ (i.e. 1.4, 1.5, 2.0, 3.0, 5.0, 2008, PrettyView, BigPussyCat, ...)? This way we only keep real bugs for 1.3, which need resolving. According to me, one of the blockers is: - WICKET-1130 https://issues.apache.org/jira/browse/WICKET-1130 - waits for Al to fix this But there are more concerning relative URLs. Are we going to fix those in the 1.3.x timeframe or should we postpone that to 1.3++? Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 -- Download Wicket 1.3.0 now! - http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: [VOTE] Release Wicket 1.3.0 final
[X] Release Apache Wicket 1.3.0 final Clean build, run on Windows XP, JDK 1.5, FF2 /Gwyn
Re: [vote] Cut the final wicket 1.3.0 release this weekend
[X] Yes, build 1.3.0 final this weekend /Gwyn
Re: 1.4 Wish List
On 15/12/2007, Eelco Hillenius [EMAIL PROTECTED] wrote: A general remark about this list is that I also think this actually should be 1.4.1. We agreed a long time ago that 1.4 would be only the last missing parts of 2.0 (Java 5 related things, most notably generics). Like I predicted back then, it is taking us a long time to reach 1.3, and we should have the discipline of sticking to what we promised way back: 1.4(.0) is about the last 2.0 ports, and after we have a good 1.4.0 final, we can start on new features again. Totally agree - I think I saw a comment on users@ from Johan or Igor to the effect that we hadn't had a discussion as to what 1.4 was, whereas my recollection is that we certainly stated what 1.4.0 was to be, i.e. as above. Personally, I'd be very against anything going into 1.4 that wasn't either a bug-fix found in 1.3.x or directly related to a 'missing' 2.0 feature. /Gwyn -- Download Wicket 1.3.0-rc2 now! - http://wicketframework.org
Links to -Extensions -Stuff
Shouldn't we be linking from the home page to Wicket Extensions Wicket Stuff (and if so, where), or am I overlooking something? For W-Stuff, I guess http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki but I'm not sure about Extensions - anyone? /Gwyn
Component 'validation' phase?
Just wondering if it would be possible and if so, worthwhile, to have a 'validation' point somewhere in the (development) page processing, to try warn about things that are valid but probably not what's intended. The specific issue that springs to mind is that raised in WICKET-1163, i.e. where you have a component that's had both setVisible(false) and setOutputMarkupId(true) called on it, but not setOutputMarkupPlaceholderTag(true). It seems to me that that it might be worth a warning in the log file when in development mode, at least, and there might be other combinations that might be worth detecting. Comments? /Gwyn -- Download Wicket 1.3.0-rc1 now! - http://wicketframework.org
Re: wicket wiki and attachments
On 13/11/2007, Dmitry Kandalov [EMAIL PROTECTED] wrote: On Tuesday 30 October 2007 00:47:46 Martijn Dashorst wrote: The best way to go at this is to upload your attachment to a new JIRA issue, and grant us the use of the file. Give a link to the document where you want the attachment and we'll add it to confluence. Could someone please attach these ones https://issues.apache.org/jira/browse/WICKET-1144 Done I've asked infra@ about what the best way is to make more permanent arrangements. Did he say anything good? Hmm - Don't recall noticing a response, actually... /Gwyn -- Download Wicket 1.3.0-rc1 now! - http://wicketframework.org
Re: Replacing div/ with div/div
It seems to me that while it's something that Wicket /could/ do, I'm not sure if it's something that Wicket /should/ do... Having said that, I think I'd be less against it if we restricted it to only tags that had a wicket:id attribute? /Gwyn Thursday, November 1, 2007, 2:18:34 PM, you wrote: It is semanticaly the same. And Firefox really treats div/ etc. wrong way. Should we have a vote on this? -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: yeah we are generating extra attributes but do we introduce tags itself ? On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: That's not entirely true. E.g. we generate unique ids for script elements, that is altering markup (this is necessary for header contribution filtering). I don't think it would harm to expend those tags. -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: until now we have the policy that we don't alter the markup. But we could expand all of them if needed. I don't mind to much On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Actually, I think that we might want to do this for all tags except for couple of selected ones, e.g. hr / This would also reduce confusion of new user when they do span wicket:id=label'/ -Matej On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Hi, I noticed that if you add empty div / tags to firefox, it treats it like if you forgot to close it. That can cause weird behavior on ajax replacements for example, as it treats the subsequent tags as children of the div / tag. I think we should have a MarkupFilter that replaces all div / tags with div/div. This semes to be also case for span, p, b, ... etc. -Matej -- Best regards, Gwynmailto:[EMAIL PROTECTED]
Re: [VOTE] WICKET-995
The '.' is legal where it's being used, the problem appears to be that some JavaScript libraries don't correctly parse it but instead do something different. On the one hand, this is just the autogenerated ids, as far as we can see at the moment, it's a 'safe' fix and (I think) anyone relying on the old behaviour has other options/is taking a risk, while on the other, it's adding 'magic' to work around third-party bugs. /Gwyn On Thursday, September 27, 2007, 9:58:47 AM, Johan [EMAIL PROTECTED] wrote: we shouldn't generate illegal id's no matter what a developer gives us as there componentid or is that already taken care off? (before this change?) So you keep the change on my end if that also fixes the really illegal stuff anyway johan On 9/26/07, Ryan Holmes [EMAIL PROTECTED] wrote: At Igor's request, I'm asking for a vote on https://issues.apache.org/ jira/browse/WICKET-995 The issue has already been fixed, but reopened due to questions and some opinions against the change. I think the comments on the issue provide enough background, so here are the choices: [ ] 1) Keep the change. It provides friendlier HTML id's by eliminating '.' characters and it's perfectly safe. [ ] 2) Revert the change. It's not a bug and the magic behavior is unnecessary and/or dangerous. -Ryan /Gwyn
WickeMessage functionality check?
Anyone got a couple of mins to check WicketMessageResolver? It looks to me as if WicketMessageResolver$MessageLabel.onComponentTagBody() would support wicket:messagekey/wicket:message albeit with a debug warning, by using 'key' as the key, but it doesn't, as before it gets to that part of the code, it's been intercepted by an earlier trap in resolve() that throws MarkupException( Wrong format of wicket:message key='xxx': attribute 'key' is missing); Any thoughts as to what the correct behaviour should be? -- Best regards, Gwyn mailto:[EMAIL PROTECTED]
Re: Release 1.3.0 Beta-4 this weekend?
I've not looked at the rest of the issues, so that may be unrepresentative, but I'd be concerned that we don't hold up the release for things that appear to be only of minority interest. My vote would be a beta4 or RC as soon as possible - If there's then something that we really should have added, there's always V1.3.1... /Gwyn On Tuesday, September 25, 2007, 3:10:13 PM, Martijn [EMAIL PROTECTED] wrote: I still see a lot of unresolved issues, that are breakers for 1.3 final IMO. For example stateless pages in combination with forms seem unusable, at least looking at the issues. I think that needs to be solved before we consider releasing the final beta. Or we need to plan another one, or just bite the bullet and go into RC after this, fixing the issues along the way. The last snapshot was published on Sat, 15 Sep 2007 21:06:11 GMT, also not a very good indicator of stability. Martijn On 9/25/07, Frank Bille [EMAIL PROTECTED] wrote: Heyall With the portlet support approaching, is it possible for me to do a release on sunday? /Frank
Re: Please review WICKET-983: Merge the portlet support branch into the trunk
Yes, it's about time, I think... ...Done. /Gwyn On Thursday, September 20, 2007, 10:28:05 AM, Frank [EMAIL PROTECTED] wrote: I think we should wrap this up and hold a vote on how to proceed with portlets. As I see it there are two options: 1) Merge portlets into trunk now and delay the final 1.3 release until the dust has settled. 2) Delay portlets support until 1.4. WDYT? Frank On 9/19/07,Gwyn Evans[EMAIL PROTECTED] wrote: On Wednesday, September 19, 2007, 12:12:16 AM, Ate [EMAIL PROTECTED] wrote: Since -beta3, there have been several other commits to the trunk which also affect critical areas like url handling: should those not have been applied either? Probably not! :-) The amount of changes to the existing code isn't very big and won't cost you much time to review. If you're willing to do so, I'd suggest checking out the -beta3 release and apply the patch file I attached to WICKET-983. Then, using the Eclipse Team Synchronization Perspective, you can get a quick view on all the changes, within context. I used IDEA, but yes - the only issues I had were the changed test expectations in jdk-1.4\wicket\src\test\java\org\apache\wicket\ajax\ markup\html\componentMap\SimpleTestPageExpectedResult.html SimpleTestPageExpectedResult-1.html, where the change in AbstractAjaxBehaviour.java results in the test page having a IActivePageBehaviorListener rather than a IBehaviorListener. I also provided a build wicket-examples.war based on the portlet-support branch for testing purposes which you can deploy in any servlet container: http://people.apache.org/~ate/wicket/wicket-examples.war I used the one I built, but no problems found. At the moment I'd have a "- 0.2" position on things, i.e. slightly negative, as I want to get a 1.3 release out and have concerns that this might delay things, but open to persuasion would welcome some input from someone more familiar with the core than I am who might be able to comment as to if my concerns are likely to be unfounded. Well, I can't see any problems, no one else has raised anything we're still getting a reasonable rate of issues being raised/fixed on trunk, so I'm happy for you to apply the changes now... it's cost you though! :-) How about, once this is all in working OK, about doing a couple of wiki articles - One "Hello Portal" for users, describing how to get started with Wicket and an example portal server, and a second for the developers, flagging things to watch out for when coding the core? /Gwyn /Gwyn
Re: [VOTE] WICKET-983: Merging portlet support
On Thursday, September 20, 2007, 11:09:04 AM, Gwyn [EMAIL PROTECTED] wrote: [X] 1) Merge now and accept the (small but non-zero) chance of delaying 1.3 a bit. /Gwyn
Re: [VOTE] WICKET-983: Merging portlet support
On Thursday, September 20, 2007, 11:28:02 AM, Martijn [EMAIL PROTECTED] wrote: I would feel more confident in the outcome when Al has had his looksy on sunday. Shall we at least extend the vote until then? Typical votes run for 72 hours, so it wouldn't delay too much if we extend it until sunday evening or so. If Al hasn't been able to check it on sunday, I don't see a reason for further delay though. No problem with extending here, I just felt that as the discussion had dried up, even pending Al's review it would be worth trying to get an idea of the feelings either way sooner rather than later. /Gwyn
Re: mvn site: a possible solution
On Thursday, September 20, 2007, 11:13:23 PM, Tim [EMAIL PROTECTED] wrote: BTW, I'm continuing to run the full javadoc build in ~tobrien as an interim solution. It certainly isn't ideal, but it's one way to solve the problem. I'll keep an eye on the discussion. Please flag it (to myself or Martijn, if no-one else) if/when that changes, as that's where the JavaDoc link on the front page goes! :-) /Gwyn
Re: [jira] Resolved: (WICKET-647) New Wicket Portlet support
On Tuesday, September 18, 2007, 5:18:16 AM, Eelco [EMAIL PROTECTED] wrote: I think the issue is how much extra time is needed to wait until the merged result can be proven in the wild to be stable enough. It may not affect only those who write portlets, but also those who don't. Frankly, I seldom see such significant new features being introduced in a beta stage. It's been in there for a while though, and the impact on the Wicket core project should be nill. The only thing that we have to take into account with the Wicket core project is that we shouldn't break Ate's rules, but I think that could only happen when we would introduce new functionality or do big internal refactoring. The existing code's been there, true, but that's not the problem here. While I'm sympathetic about the desire to get Portlet support into trunk, it seems to me that the fundamental problem is that we're not taking the task of getting 1.3 released seriously. As a result, we're entertaining the question of making major changes to the codebase when we should be locking it down except for fixes to release-stopping bugs. As a side-effect of this willingness to accept changes, Ate's (justified) concern is that before the release, the 1.3 trunk will change so significantly that his work becomes useless. My preference would be to have a brake on the trunk enhancements, to stop adding functionality and to focus on getting a 1.3 out - frankly, getting to a Beta-4 release seems to me to be indicative that something's gone wrong somewhere. As a result, I don't know where the Portlet changes should go - I can understand that it would be good to get them in 1.3, but my feeling remains that at this stage of a release, they shouldn't be added. /Gwyn
Re: svn commit: r570573 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/request/WebRequestCodingStrategy.java
Not sure what you mean by push it? I wasn't saying that there shouldn't be the Eclipse settings, just that at some stage it might be worth documenting them in a more generic way than just the .pref files. Unfortunately, while I can generate a IDEA 7 project by importing the pom.xml files, I don't know of anything that converts the Eclipse settings into the correct IDEA settings. Once done, they could be uploaded, but that's not the problem! /Gwyn On Tuesday, September 4, 2007, 6:12:57 PM, Johan [EMAIL PROTECTED] wrote: But event then if there where a bit active userson IDEA then still it is a good idea that the eclipse users do how we do it now its way better then nothing.. Can IDEA not push it like eclipse? johan On 9/4/07, Gwyn Evans [EMAIL PROTECTED] wrote: On Monday, September 3, 2007, 9:38:50 PM, Eelco [EMAIL PROTECTED] wrote: and we agreed from day one in this project to follow our formatting rules, which again from day one we committed as part of the eclipse project files. Other IDEs? We'll tackle that when we'll get there. Actually, I've been using IDEA right from the start, but luckily only on small bits of code, as it's not been easy to pick out all the Wicket-specific formatting settings from the Eclipse settings... If I was doing more, I'd have started a wiki page to try document the settings options as seen by IDEA, but it's not got to that yet... /Gwyn
Re: svn commit: r570573 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/request/WebRequestCodingStrategy.java
On Tuesday, September 4, 2007, 9:35:23 PM, Johan [EMAIL PROTECTED] wrote: On 9/4/07,Gwyn Evans[EMAIL PROTECTED] wrote: Not sure what you mean by "push it"? when you open a project project properties page then many things can be configured only for the project itself you can overwrite the workspace settings. And when you do that eclipse saves this in a directory .settings this dir can be committed and then everybody that checks out that project have the same settings. johan I see. With IDEA, you can set per-project code-styles, but the settings are kept in the single project file. They can be manually imported and/or exported if required, though. /Gwyn
