Re: [vote] Name the release after 1.3
[] Apache Wicket Omega i see most are voting for wicket 2.0 are we sure about that? i think it won't even be that big api break (i really think it will be much less then 1.2 - 1.3) and it will be still very close to what we call now 2.0.. so it could be confusing in the short term. so mostly it will be java 5, so maybe [x] Apache Wicket 1.5 johan (but i don't mind Wicket 2.0) On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote: There is a vote already in place for switching the development branches around. Now it is time to name the release after 1.3 (and not 1.3.1 :). Apache Wicket 1.3 will be followed by: [ ] Apache Wicket 1.4 [ ] Apache Wicket 1.5 (after the JDK) [ ] Apache Wicket 5 (similar, but more accurate) [ ] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change) [ ] Apache Wicket 2007 [ ] Apache Wicket r59332 (just use the damned revision number) Other proposals are permitted. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: [Wicket-user] [announce] wicket 1.x development has moved to trunk in svn
OK, so I think it will be fine if we also switch - wicketstuff/trunk to wicketstuff/branches/wicket-2-DISCONTINUED - wicketstuff/branches/wicket1.x to wicketstuff/trunk -- Vincent Martijn Dashorst a écrit : We have now switched trunk and wicket 1.x in subversion. We have been getting reports of confused users about the status of Wicket and where to get the code from. We appologize for the inconvenience this will cause. From now on trunk is again our main development branch. The previous Wicket 2 *with* constructor change has now been moved to branches/wicket-2-DISCONTINUED and is in maintenance mode (i.e. only bug fixes on a case-by-case basis). * Switching Wicket 1.3 If you depended on branches/wicket-1.x do the following in your checked out working copy: svn switch http://svn.apache.org/repos/asf/incubator/wicket/trunk (if you are a Wicket committer, substitute http with https) * Switching Wicket 2 If you were working on trunk and want to stay with the latest in that branch you will need to do the following in your working copy: svn switch http://svn.apache.org/repos/asf/incubator/wicket/branches/wicket-2-DISCONTINUED (if you are a Wicket committer, substitute http with https) We will switch the svn branches in wicket-stuff too. Best regards, Martijn
Re: [Wicket-user] [announce] wicket 1.x development has moved to trunk in svn
On 4/19/07, Vincent Demay [EMAIL PROTECTED] wrote: OK, so I think it will be fine if we also switch - wicketstuff/trunk to wicketstuff/branches/wicket-2-DISCONTINUED - wicketstuff/branches/wicket1.x to wicketstuff/trunk I think it is best to coordinate this with contributors to wicketstuff. If anyone has outstanding changes. I'm willing to do the switch, but don't want to upset people too much :) If anyone else is willing to do it, fine by me, as long as we coordinate. I propose we do the switch for wicketstuff at (or around) 6pm CET (for us euros: 18:00 central european time). Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: [Wicket-user] [announce] wicket 1.x development has moved to trunk in svn
Martijn Dashorst wrote: I propose we do the switch for wicketstuff at (or around) 6pm CET (for us euros: 18:00 central european time). OK. Bart.
Re: [Wicket-user] [announce] wicket 1.x development has moved to trunk in svn
On 4/19/07, Vincent Demay [EMAIL PROTECTED] wrote: If anyone else is willing to do it, fine by me, as long as we coordinate. As you want, you can do it, but if you are bored with svn mv, I can do it I don't mind doing it. I propose we do the switch for wicketstuff at (or around) 6pm CET (for us euros: 18:00 central european time). Why 18:00? is it your favorite time in the day ;) ? It is because then the west coast of the US is awake for a couple of hours, so they also have the opportunity to perform their last commits. And for us euro boys a whole working day. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: [Wicket-user] [announce] wicket 1.x development has moved to trunk in svn
Martijn Dashorst a écrit : On 4/19/07, Vincent Demay [EMAIL PROTECTED] wrote: If anyone else is willing to do it, fine by me, as long as we coordinate. As you want, you can do it, but if you are bored with svn mv, I can do it I don't mind doing it. Ok, do it ;) I propose we do the switch for wicketstuff at (or around) 6pm CET (for us euros: 18:00 central european time). Why 18:00? is it your favorite time in the day ;) ? It is because then the west coast of the US is awake for a couple of hours, so they also have the opportunity to perform their last commits. And for us euro boys a whole working day. Martijn
Re: [vote] Move trunk to branches, promote wicket-1.x to trunk
* Martijn Dashorst: This is a vote to promote 1.x to trunk and demote trunk to branches with an appropiate label, and do it soon (as in now) [x] yes, switch them [ ] no, don't switch them -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: [vote] Name the release after 1.3
* Martijn Dashorst: Apache Wicket 1.3 will be followed by: [x] Apache Wicket 1.4 [ ] Apache Wicket 1.5 (after the JDK) [ ] Apache Wicket 5 (similar, but more accurate) [ ] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change) [ ] Apache Wicket 2007 [ ] Apache Wicket r59332 (just use the damned revision number) No major new API will justify the change to 2.0, and 2.0 might be a confusing name as we just discontinued it. 2.0 makes me think of a child prematurely born dead. If we consider that an API break justifies bumping the major version number, we should already have renamed 1.3 to 2.0. As it seems API break doesn't imply major version number change, why would you do it for 1.4 and not for 1.3? Furthermore bumping a major version number often means we're providing brand new features, not just introducing Java 1.5 syntax, as there is no real added value to that except increased comfort. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: [vote] Name the release after 1.3
Wednesday, April 18, 2007, 11:04:12 PM, Martijn wrote: There is a vote already in place for switching the development branches around. Now it is time to name the release after 1.3 (and not 1.3.1 :). Apache Wicket 1.3 will be followed by: [+1] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change) I think there /will/ be a certain amount of confusion, but I do think that the jump to Java 2/JDK1.5, justifies the major version increment. I do however wonder if the following would be better... [ ] Apache Wicket 2.1 (one step beyond) /Gwyn
Re: About the votes
Thursday, April 19, 2007, 10:51:15 AM, Jean-Baptiste wrote: Can you please wait at least 24 or 48 hours before taking action, and wait for more developers to express their opinion? For European people like me the vote started yesterday evening when leaving the office, and the switch from 1.x to trunk has been checked in in the morning, when the workday begins. That doesn't leave a lot of time to raise any concern. Got to agree here - if there was a security issue, then maybe the rush would be justified, but if not, then I'd have expected 48 hrs minimum. Were you so confident about the result of the vote? To my mind, the vote isn't to gather enough agreement, it's to ensure that there's not a disagreement/better alternative option overnight votes won't help with that... /Gwyn
Re: [vote] Name the release after 1.3
[x] Apache Wicket 1.4 (Non-binding vote) Having declared 2.0 a dead-end, you shouldn't release anything with the same version number within six months at least - there's too much potential for confusion IMHO. Not to mention tutorials and code snippets that are floating around labelled for Wicket 2.0. Yikes. Charlie. On 4/19/07, Gwyn Evans [EMAIL PROTECTED] wrote: Wednesday, April 18, 2007, 11:04:12 PM, Martijn wrote: There is a vote already in place for switching the development branches around. Now it is time to name the release after 1.3 (and not 1.3.1 :). Apache Wicket 1.3 will be followed by: [+1] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change) I think there /will/ be a certain amount of confusion, but I do think that the jump to Java 2/JDK1.5, justifies the major version increment. I do however wonder if the following would be better... [ ] Apache Wicket 2.1 (one step beyond) /Gwyn
Error logging
Hi list,
I have a problem with error logging strategies. In our application, we use a
log4j SMTP appender, that sends out alarming emails in case of error logs.
However, we cannot properly control our wicket application as far as logging
is concerned. The problem is that this causes us to receive emails, for
instance, when a user enters an incorrect URL - which is hardly alarming,
I'd say.
We override the application's getDefaultRequestCycleFactory to return a
factory that constructs WebRequestCycle instances that override the
onRuntimeException method - we assumed that that way we could control
logging in case of runtime exceptions. However, in **private** methods of
RequestCycle, Exceptions are logged on the error level, most notably
RuntimeException. In the step() method for example, the following snippet
causes our problems:
catch (RuntimeException e)
{
// set step manually to handle exception
currentStep = HANDLE_EXCEPTION;
// probably our last chance the exception can be logged
log.error(e.getMessage(), e);
// try to play nicely and let the request processor handle the
// exception response. If that doesn't work, any runtime exception
// will automatically be bubbled up
if (processor != null)
{
processor.respond(e, this);
}
}
I'd say one should allow more control: why not call a protected method that
has a default implementation of log.error(e.getMessage, e) ? This way, one
can easily adjust the logging level by overriding this method in a subclass.
Your thoughts?
Regards,
--
Ivo van Dongen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
[warn] wicketstuff subversion reshuffle imminent
All, Following the recent shuffle in the Apache Wicket repository, we will also restructure the Wicket Stuff repo in the same manner. new trunk will become wicket 1.x existing trunk will move to branches/wicket-2-DISCONTINUED I'll take care of the new project that was added to trunk, so it will stay there. Any other stuff I need to know about? For committers, please check your Wicket Stuff in before 6pm CET (about less than 1.5 hours from now). When the shuffle is completed, you can switch your local working copy using the svn switch command. For a couple of dormant projects this means that they will move with trunk to the discontinued branch. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: About the votes
On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Can you please wait at least 24 or 48 hours before taking action, and wait for more developers to express their opinion? For European people like me the vote started yesterday evening when leaving the office, and the switch from 1.x to trunk has been checked in in the morning, when the workday begins. That doesn't leave a lot of time to raise any concern. Were you so confident about the result of the vote? 6 binding +1's from active committers, including 4 from the euro continent, so I felt confident, and eager: the number of queries when 2.0 is coming out is quite annoying. Apologies for being too enthousiastic with mv-ing the svn repo. I'll add durations and types of vote counting (majority or veto-able) next time. In this case I think it is an inconvenience that the shuffle took place, svn switch should not result in problems with uncommitted changes (at least I haven't seen them to date). Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: Error logging
* Ivo van Dongen: I have a problem with error logging strategies. In our application, we use a log4j SMTP appender, that sends out alarming emails in case of error logs. However, we cannot properly control our wicket application as far as logging is concerned. The problem is that this causes us to receive emails, for instance, when a user enters an incorrect URL - which is hardly alarming, I'd say. You may be interested in this bug report: PackageRequestTargetUrlCodingStrategy should interrupts the cycle and sends a 404 when a page/class cannot be found http://issues.apache.org/jira/browse/WICKET-293 If there is massive user feedback about this one, it may gain more attention ;-) I'd say one should allow more control: why not call a protected method that has a default implementation of log.error(e.getMessage, e) ? This way, one can easily adjust the logging level by overriding this method in a subclass. Check out the latest code, a new protected method has been added just for that. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Building a release of Wicket 1.3.0-incubating-beta (?) this weekend?
All, Since we did the package rename, and now that biggest API breakers of the backports are in, shall we now build a new release for 1.3? This release would be made available to the larger community. The IPMC would be much more willing to check it in this case. Questions: - should we create a release this weekend? - how do we label it? [alpha, beta, general availability, ...] Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Updating the examples on wicketstuff.org
Hi there, What is the procedure to update the examples on wicketstuff.org? http://wicketstuff.org/wicket13/ Also, it would be great to have Javadocs deployed online at each build. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Updating the examples on wicketstuff.org
To my best knowledge these get autodeployed by bamboo. Martijn On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Hi there, What is the procedure to update the examples on wicketstuff.org? http://wicketstuff.org/wicket13/ Also, it would be great to have Javadocs deployed online at each build. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
[announce] wicket-stuff for 1.x has moved to trunk in svn
We will switch the svn branches in wicket-stuff too. This is also completed as of now. Wicket Stuff svn now mirrors Wicket svn in structure. * Trunk of wicket stuff has been moved to branches/wicket-2-DISCONTINUED * Branch wicket-1.x has been moved to trunk If you have code checked out for wicket 1.x you can switch using svn switch http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/project If you have old trunk code checked out, you can switch using svn switch http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/branches/wicket-2-DISCONTINUED/project Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: Building a release of Wicket 1.3.0-incubating-beta (?) this weekend?
Questions: - should we create a release this weekend? Yes, please. - how do we label it? [alpha, beta, general availability, ...] Beta. You want schedule some time in to go through JIRA as well? Eelco
Re: Building a release of Wicket 1.3.0-incubating-beta (?) this weekend?
On 4/19/07, Eelco Hillenius [EMAIL PROTECTED] wrote: You want schedule some time in to go through JIRA as well? I'll just build the release. I can schedule the cut of the code base to a specific time, though. Especially if 1.2.6 is going out too (and I have some writing to do as well). Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: Error logging
I'd say one should allow more control: why not call a protected method that has a default implementation of log.error(e.getMessage, e) ? This way, one can easily adjust the logging level by overriding this method in a subclass. Check out the latest code, a new protected method has been added just for that. Yep. If you create a custom request cycle now, you can override logRuntimeException(RuntimeException). Don't call super in there when you don't want it to be logged without interference. Also onRuntimeException(Page, RuntimeException) is always called if you want more control over what is displayed to users. Eelco
[discussion] Name the release after 1.3 WAS Re: [vote] Name the release after 1.3
its not just an api break. it is also the fact that we changed the underlying technology. ive seen a lot of projects jump a major version when they switched to jdk 1.5 without adding too many features. it will also make it easier for martijn and eelco to continue with their book as they dont have to rebrand it with their publisher -igor On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: * Martijn Dashorst: Apache Wicket 1.3 will be followed by: [x] Apache Wicket 1.4 [ ] Apache Wicket 1.5 (after the JDK) [ ] Apache Wicket 5 (similar, but more accurate) [ ] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change) [ ] Apache Wicket 2007 [ ] Apache Wicket r59332 (just use the damned revision number) No major new API will justify the change to 2.0, and 2.0 might be a confusing name as we just discontinued it. 2.0 makes me think of a child prematurely born dead. If we consider that an API break justifies bumping the major version number, we should already have renamed 1.3 to 2.0. As it seems API break doesn't imply major version number change, why would you do it for 1.4 and not for 1.3? Furthermore bumping a major version number often means we're providing brand new features, not just introducing Java 1.5 syntax, as there is no real added value to that except increased comfort. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Updating the examples on wicketstuff.org
but i wonder if the symlink points to 1.3-snap or 1.3.0-snap? -igor On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote: To my best knowledge these get autodeployed by bamboo. Martijn On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Hi there, What is the procedure to update the examples on wicketstuff.org? http://wicketstuff.org/wicket13/ Also, it would be great to have Javadocs deployed online at each build. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: Updating the examples on wicketstuff.org
hrm, we used to have a symlink in tomcat's webapps dir that pointed to where maven installed the jars, so it would all work automagically. but now i see there is a copywicket13.sh that copies manually and the symlink is gone. any reason johan? -igor On 4/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote: but i wonder if the symlink points to 1.3-snap or 1.3.0-snap? -igor On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote: To my best knowledge these get autodeployed by bamboo. Martijn On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Hi there, What is the procedure to update the examples on wicketstuff.org? http://wicketstuff.org/wicket13/ Also, it would be great to have Javadocs deployed online at each build. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: Building a release of Wicket 1.3.0-incubating-beta (?) this weekend?
On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote: All, Since we did the package rename, and now that biggest API breakers of the backports are in, shall we now build a new release for 1.3? This release would be made available to the larger community. The IPMC would be much more willing to check it in this case. Questions: - should we create a release this weekend? you mean a public release? that depens on whether or not johan can get the attach/beginrender refactor in before then. that will break clients, so we should get it in before doing any soft of public release. - how do we label it? [alpha, beta, general availability, ...] if johan gets the refactor in call it a beta because they all major tweaks are in. if not, and you still want to make a release, call it alpha. and whatever you do, no matter how desperate you are, do not call it general availability. -igor Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: [vote] Name the release after 1.3
Charlie Dobbie wrote: [x] Apache Wicket 1.4 (Non-binding vote) Having declared 2.0 a dead-end, you shouldn't release anything with the same version number within six months at least - there's too much potential for confusion IMHO. Not to mention tutorials and code snippets that are floating around labelled for Wicket 2.0. Yikes. I have to agree with this, much as it may be a pain for the book. :-/ I'm inclined to adopt the full-on Apache versioning scheme, which means: - Non-backwards compatible updates are x.0.0 - Backwards compatible updates are x.y.0 - Forwards/backwards interchangable patch versions are x.y.z What about 3.0.0 with a move to this versioning scheme thereafter? Regards, Al
Re: [vote] Name the release after 1.3
On 19.4.2007, at 1.04, Martijn Dashorst wrote: Apache Wicket 1.3 will be followed by: [x] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change)
Re: [vote] Name the release after 1.3
[x] Apache Wicket 7.05 - I'm an Ubuntu user... :D On 4/19/07, Janne Hietamäki [EMAIL PROTECTED] wrote: On 19.4.2007, at 1.04, Martijn Dashorst wrote: Apache Wicket 1.3 will be followed by: [x] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change) -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060
[vote] Release Wicket 1.2.6
This is a vote to release Wicket 1.2.6 this weekend. There are still some issues open, but I hope they can be solved either for we release, or we should just postpone them to 1.2.7 Open issues: WICKET-268 NPE in ListView.renderItem(ListItem) WICKET-349 ListView can't undo changes to model WICKET-475 NPE in WebClientInfo when user-agent header is not sent WICKET-438 File handles are leaked when loading images from a jar file, Tomcat crashes The list of fixes is quite long, and contains a security related issue. Therefore I issue this vote to release Wicket 1.2.6 this weekend (build will be done on sunday). [ ] Release wicket 1.2.6 regardless if these four issues are resolved [ ] Release wicket 1.2.6 but I'll make sure these get fixed [ ] Don't release wicket 1.2.6 until these four issues are resolved Wicket 1.2.6 will be released on our old SF.net hardware, and will not be endorsed by the ASF, just as 1.2.4 and 1.2.5 were released. This is a vote by majority, and lasts until sunday noon CET (for Euros: 12:00). Martijn ps. I hope I still remember how to build a 1.2 style release. -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: [vote] Release Wicket 1.2.6
[x] Release wicket 1.2.6 regardless if these four issues are resolved -igor On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote: This is a vote to release Wicket 1.2.6 this weekend. There are still some issues open, but I hope they can be solved either for we release, or we should just postpone them to 1.2.7 Open issues: WICKET-268 NPE in ListView.renderItem(ListItem) WICKET-349 ListView can't undo changes to model WICKET-475 NPE in WebClientInfo when user-agent header is not sent WICKET-438 File handles are leaked when loading images from a jar file, Tomcat crashes The list of fixes is quite long, and contains a security related issue. Therefore I issue this vote to release Wicket 1.2.6 this weekend (build will be done on sunday). [ ] Release wicket 1.2.6 regardless if these four issues are resolved [ ] Release wicket 1.2.6 but I'll make sure these get fixed [ ] Don't release wicket 1.2.6 until these four issues are resolved Wicket 1.2.6 will be released on our old SF.net hardware, and will not be endorsed by the ASF, just as 1.2.4 and 1.2.5 were released. This is a vote by majority, and lasts until sunday noon CET (for Euros: 12:00). Martijn ps. I hope I still remember how to build a 1.2 style release. -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: [vote] Release Wicket 1.2.6
[ x ] Release wicket 1.2.6 regardless if these four issues are resolved [ ] Release wicket 1.2.6 but I'll make sure these get fixed [ ] Don't release wicket 1.2.6 until these four issues are resolved Eelco
Re: [vote] Release Wicket 1.2.6
Release it but i think igor can fix them all first tonight. On 4/20/07, Martijn Dashorst [EMAIL PROTECTED] wrote: This is a vote to release Wicket 1.2.6 this weekend. There are still some issues open, but I hope they can be solved either for we release, or we should just postpone them to 1.2.7 Open issues: WICKET-268 NPE in ListView.renderItem(ListItem) WICKET-349 ListView can't undo changes to model WICKET-475 NPE in WebClientInfo when user-agent header is not sent WICKET-438 File handles are leaked when loading images from a jar file, Tomcat crashes The list of fixes is quite long, and contains a security related issue. Therefore I issue this vote to release Wicket 1.2.6 this weekend (build will be done on sunday). [ ] Release wicket 1.2.6 regardless if these four issues are resolved [ ] Release wicket 1.2.6 but I'll make sure these get fixed [ ] Don't release wicket 1.2.6 until these four issues are resolved Wicket 1.2.6 will be released on our old SF.net hardware, and will not be endorsed by the ASF, just as 1.2.4 and 1.2.5 were released. This is a vote by majority, and lasts until sunday noon CET (for Euros: 12:00). Martijn ps. I hope I still remember how to build a 1.2 style release. -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
JavaScript object
Something like class below (although perhaps more efficient) could help us to
decorate and merge javascript in our AJAX code. Because code merges only
occur one layer at a time, it's as good as an AST for our simple purposes
(we don't need to globally refactor JavaScript, for example, only combine it
neatly), but much easier to use. I personally would have no problem
breaking the API to make this better, but we could also do this with 100%
backwards compat by simply having things that need JavaScript make a call to
a getWhateverJavaScript() method first and if that returns null (in the
default impl), it could proceed to do what it does now. So basically if you
wanted to assemble your script this new way, you could override these new
methods and the old stuff would be bypassed. Feedback?
Jonathan
---
package thoof.util.javascript;
import java.io.IOException;
import java.io.InputStream;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.regex.Pattern;
import org.apache.wicket.util.io.Streams;
import org.apache.wicket.util.string.interpolator.MapVariableInterpolator;
public class JavaScript {
private final String script;
private static final Pattern UNINTERPOLATED_VARIABLES = Pattern
.compile(\\s*\\$\\{\\w+\\}\\s*);
public JavaScript(final String script) {
this.script = script;
}
public static JavaScript load(final Class? type, final String
resourceName) {
return load(type.getResourceAsStream(resourceName));
}
public static JavaScript load(final InputStream in) {
try {
return new JavaScript(Streams.readString(in));
} catch (final IOException e) {
throw new IllegalStateException(Cannot load email template,
e);
}
}
public final JavaScript merge(final MapString, Object map) {
final String mergedScript = new MapVariableInterpolator(this.script,
map).toString();
return new JavaScript(UNINTERPOLATED_VARIABLES.matcher(mergedScript)
.replaceAll( ));
}
public final JavaScript merge(final Object... args) {
if (args.length % 2 != 0) {
throw new IllegalArgumentException(
Invalid interpolation arguments);
}
final MapString, Object map = new HashMapString, Object();
for (int i = 0; i args.length; i += 2) {
if (args[i] instanceof String) {
map.put((String) args[i], args[i + 1]);
} else {
throw new IllegalArgumentException(
Invalid interpolation arguments);
}
}
return merge(map);
}
public final JavaScript prepend(final JavaScript script) {
return new JavaScript(script + ; + this.script);
}
public final JavaScript append(final JavaScript script) {
return new JavaScript(this.script + ; + script);
}
public final JavaScript function(final String functionName) {
return new JavaScript(var + functionName + = function { +
script
+ };);
}
@Override
public String toString() {
return MapVariableInterpolator.interpolate(script,
Collections.EMPTY_MAP);
}
public static void main(final String arguments[]) {
JavaScript code = new JavaScript(var x = 10 + 3);
System.out.println( + code.toString());
code = code.prepend(new JavaScript(a + b));
System.out.println( + code.toString());
code = code.append(new JavaScript(c + d));
System.out.println( + code.toString());
code = code.function(callback);
System.out.println( + code.toString());
JavaScript ajax = new JavaScript(
var wcall; ${beforeCallback} wcall =
wicketAjaxGet('${url}', function() { ${success} }, function() { ${failure}
}); ${afterCallback} return !wcall;););
code = ajax.merge(url, /abc/def, beforeCallback, code,
afterCallback, a = b + c + d);
System.out.println( + code.toString());
}
}
--
View this message in context:
http://www.nabble.com/JavaScript-object-tf3610605.html#a10089745
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: JavaScript object
yeah, it's a little tricky, but i think the inheritance hierarchy can
provide the levels you're looking for (sort of as it does now) with
overrides and calls to super. i'm not sure exactly what you are asking me
to do, but the code might look like this (if i understand you right):
class QueryGoogle
{
JavaScript getScript()
{
final JavaScript script = new JavaScript(function
wget(http://www.google.com/q=${query},function(){${success}},function(){${failure}});
return script.merge(query, getQuery(), success, getSuccess(),
failure, getFailure());
}
protected abstract JavaScript getQuery();
protected JavaScript getSuccess() { return JavaScript.EMPTY; }
protected JavaScript getFailure() { return JavaScript.EMPTY; }
}
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers); }
}
class ThrottlingCucumberQuery extends CucumberQuery
{
JavaScript getQuery() { return new
ThrottlingDecorator(super.getQuery()); }
}
class NoTomatoAndAlertCucumberQuery extends CucumberQuery
{
JavaScript noTomatoes = new JavaScript(...);
JavaScript alert = new JavaScript(...);
JavaScript getQuery() { return
super.getQuery().append(noTomatoes).append(alert); }
}
Of course, if the cucumber script supports some kind of merging, it would
have to provide insertion points, like:
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers; ${middle};
moreCucumbers); }
}
igor.vaynberg wrote:
so you got single level layering
but what about multi level?
lets say our default ajax behavior returns this:
JavaScript code = new JavaScript(
function
wget(http://www.google.com/q=${query},function(){${success}},function(){${failure}});
now something down the road wants to search google for cucumbers
so it does
return code.merge(query,cucumbers);
something later down the road wants to exclude tomatoes from the search
results, and also add an alert on failure, but since the previous script
lost all the placeholders how would that work? i mean its really use it or
lose it.
unless the previous script that added cucumbers now provides its own
placeholders for all the previous placeholders, but these need to be
factored into functions or some such.
could you show me what that would look like with your code?
so...
JavaScript code = new JavaScript(
function
wget(http://www.google.com/q=${query},function(){${success}},function(){${failure}});
one layer adds cucumbers to the query
the next layer excludes tomatoes and adds an alert on failure
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
A throttling decorator would look like this:
public static class ThrottlingDecorator extends JavaScript {
private static final JavaScript THROTTLER = new JavaScript(
wicketThrottler.throttle('${id}', ${milliseconds},
${function}););
public ThrottlingDecorator(final String id,
final Duration maxFrequency, final JavaScript script) {
super(THROTTLER.merge(id, id, milliseconds, maxFrequency
.getMilliseconds(), function, script.function()));
}
}
and usage of that would be:
code = new ThrottlingDecorator(id, Duration.ONE_SECOND, code);
Jonathan Locke wrote:
Something like class below (although perhaps more efficient) could help
us
to decorate and merge javascript in our AJAX code. Because code merges
only occur one layer at a time, it's as good as an AST for our simple
purposes (we don't need to globally refactor JavaScript, for example,
only
combine it neatly), but much easier to use. I personally would have no
problem breaking the API to make this better, but we could also do this
with 100% backwards compat by simply having things that need JavaScript
make a call to a getWhateverJavaScript() method first and if that
returns
null (in the default impl), it could proceed to do what it does now.
So
basically if you wanted to assemble your script this new way, you could
override these new methods and the old stuff would be
bypassed. Feedback?
Jonathan
---
package thoof.util.javascript;
import java.io.IOException;
import java.io.InputStream;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.regex.Pattern;
import org.apache.wicket.util.io.Streams;
import
org.apache.wicket.util.string.interpolator.MapVariableInterpolator;
public class JavaScript {
private final String script;
private static final Pattern UNINTERPOLATED_VARIABLES = Pattern
.compile(\\s*\\$\\{\\w+\\}\\s*);
public JavaScript(final String script) {
this.script = script;
}
public static JavaScript load(final Class? type, final String
resourceName) {
return
Re: JavaScript object
im not getting the warm and fuzzy about this. i want to, but im not.
take our base query which has the similar success and failure points as my
example. in order to facilitate those you still need the generic
ajaxcalldecorator design because those placeholders are inherited across
all layers, and JavaScript doesnt support this.
further what you have done is design a hierarchy where each layer builds on
the previous. but that means each layer has to know the previous layers'
class so it can override the proper places. this is not true in our ajax
support. we need to be able to decorate things generically.
like what you have done today - add a parameter to the back of the url.
well, maybe someone after you wants to do the same. and maybe someone after
that as well. so it somehow needs to be generic, and i think something like
charsequence buildurl() {
return super.buildurl()+myparam=foo;
}
is the only way to do that unfortunately. i dont see how JavaScript will
make that easier.
maybe im just entirely missing the point.
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
oops i forgot the new virtual:
class abstract CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers; ${middle};
moreCucumbers).merge(getMiddle()); }
protected abstract Javascript getMiddle();
}
Jonathan Locke wrote:
yeah, it's a little tricky, but i think the inheritance hierarchy can
provide the levels you're looking for (sort of as it does now) with
overrides and calls to super. i'm not sure exactly what you are asking
me
to do, but the code might look like this (if i understand you right):
class QueryGoogle
{
JavaScript getScript()
{
final JavaScript script = new JavaScript(function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
return script.merge(query, getQuery(), success,
getSuccess(),
failure, getFailure());
}
protected abstract JavaScript getQuery();
protected JavaScript getSuccess() { return JavaScript.EMPTY; }
protected JavaScript getFailure() { return JavaScript.EMPTY; }
}
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers); }
}
class ThrottlingCucumberQuery extends CucumberQuery
{
JavaScript getQuery() { return new
ThrottlingDecorator(super.getQuery()); }
}
class NoTomatoAndAlertCucumberQuery extends CucumberQuery
{
JavaScript noTomatoes = new JavaScript(...);
JavaScript alert = new JavaScript(...);
JavaScript getQuery() { return
super.getQuery().append(noTomatoes).append(alert); }
}
Of course, if the cucumber script supports some kind of merging, it
would
have to provide insertion points, like:
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers; ${middle};
moreCucumbers); }
}
igor.vaynberg wrote:
so you got single level layering
but what about multi level?
lets say our default ajax behavior returns this:
JavaScript code = new JavaScript(
function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
now something down the road wants to search google for cucumbers
so it does
return code.merge(query,cucumbers);
something later down the road wants to exclude tomatoes from the search
results, and also add an alert on failure, but since the previous
script
lost all the placeholders how would that work? i mean its really use it
or
lose it.
unless the previous script that added cucumbers now provides its own
placeholders for all the previous placeholders, but these need to be
factored into functions or some such.
could you show me what that would look like with your code?
so...
JavaScript code = new JavaScript(
function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
one layer adds cucumbers to the query
the next layer excludes tomatoes and adds an alert on failure
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
A throttling decorator would look like this:
public static class ThrottlingDecorator extends JavaScript {
private static final JavaScript THROTTLER = new JavaScript(
wicketThrottler.throttle('${id}', ${milliseconds},
${function}););
public ThrottlingDecorator(final String id,
final Duration maxFrequency, final JavaScript script)
{
super(THROTTLER.merge(id, id, milliseconds,
maxFrequency
.getMilliseconds(), function, script.function
()));
}
}
and usage of that would be:
code = new ThrottlingDecorator(id, Duration.ONE_SECOND,
code);
Jonathan Locke wrote:
Something like class below (although perhaps more efficient) could
help
us
to decorate and merge javascript in our AJAX code. Because code
merges
only occur one layer at a time, it's as good as an AST for our
Re: JavaScript object
it could be that i don't understand what we're doing well enough.
i certainly don't understand your specific concern. the throttling
decorator i showed you is completely generic and can decorate any
javascript code.
igor.vaynberg wrote:
im not getting the warm and fuzzy about this. i want to, but im not.
take our base query which has the similar success and failure points as my
example. in order to facilitate those you still need the generic
ajaxcalldecorator design because those placeholders are inherited across
all layers, and JavaScript doesnt support this.
further what you have done is design a hierarchy where each layer builds
on
the previous. but that means each layer has to know the previous layers'
class so it can override the proper places. this is not true in our ajax
support. we need to be able to decorate things generically.
like what you have done today - add a parameter to the back of the url.
well, maybe someone after you wants to do the same. and maybe someone
after
that as well. so it somehow needs to be generic, and i think something
like
charsequence buildurl() {
return super.buildurl()+myparam=foo;
}
is the only way to do that unfortunately. i dont see how JavaScript will
make that easier.
maybe im just entirely missing the point.
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
oops i forgot the new virtual:
class abstract CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers; ${middle};
moreCucumbers).merge(getMiddle()); }
protected abstract Javascript getMiddle();
}
Jonathan Locke wrote:
yeah, it's a little tricky, but i think the inheritance hierarchy can
provide the levels you're looking for (sort of as it does now) with
overrides and calls to super. i'm not sure exactly what you are asking
me
to do, but the code might look like this (if i understand you right):
class QueryGoogle
{
JavaScript getScript()
{
final JavaScript script = new JavaScript(function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
return script.merge(query, getQuery(), success,
getSuccess(),
failure, getFailure());
}
protected abstract JavaScript getQuery();
protected JavaScript getSuccess() { return JavaScript.EMPTY; }
protected JavaScript getFailure() { return JavaScript.EMPTY; }
}
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers); }
}
class ThrottlingCucumberQuery extends CucumberQuery
{
JavaScript getQuery() { return new
ThrottlingDecorator(super.getQuery()); }
}
class NoTomatoAndAlertCucumberQuery extends CucumberQuery
{
JavaScript noTomatoes = new JavaScript(...);
JavaScript alert = new JavaScript(...);
JavaScript getQuery() { return
super.getQuery().append(noTomatoes).append(alert); }
}
Of course, if the cucumber script supports some kind of merging, it
would
have to provide insertion points, like:
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers;
${middle};
moreCucumbers); }
}
igor.vaynberg wrote:
so you got single level layering
but what about multi level?
lets say our default ajax behavior returns this:
JavaScript code = new JavaScript(
function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
now something down the road wants to search google for cucumbers
so it does
return code.merge(query,cucumbers);
something later down the road wants to exclude tomatoes from the
search
results, and also add an alert on failure, but since the previous
script
lost all the placeholders how would that work? i mean its really use
it
or
lose it.
unless the previous script that added cucumbers now provides its own
placeholders for all the previous placeholders, but these need to be
factored into functions or some such.
could you show me what that would look like with your code?
so...
JavaScript code = new JavaScript(
function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
one layer adds cucumbers to the query
the next layer excludes tomatoes and adds an alert on failure
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
A throttling decorator would look like this:
public static class ThrottlingDecorator extends JavaScript {
private static final JavaScript THROTTLER = new JavaScript(
wicketThrottler.throttle('${id}', ${milliseconds},
${function}););
public ThrottlingDecorator(final String id,
final Duration maxFrequency, final JavaScript script)
{
super(THROTTLER.merge(id, id, milliseconds,
maxFrequency
Re: JavaScript object
don't forget that a javascript decorator isa JavaScript, so you can nest
them arbitrarily:
public static class ThrottlingDecorator extends JavaScript {
}
JavaScript code = new WhateverDecorator(new ThrottlingDecorator(script));
i'm still not getting what you think is missing from this solution. it
could be that i don't
understand the requirements fully, but this solution i'm proposing
definitely decorates
to any number of levels you want.
igor.vaynberg wrote:
im not getting the warm and fuzzy about this. i want to, but im not.
take our base query which has the similar success and failure points as my
example. in order to facilitate those you still need the generic
ajaxcalldecorator design because those placeholders are inherited across
all layers, and JavaScript doesnt support this.
further what you have done is design a hierarchy where each layer builds
on
the previous. but that means each layer has to know the previous layers'
class so it can override the proper places. this is not true in our ajax
support. we need to be able to decorate things generically.
like what you have done today - add a parameter to the back of the url.
well, maybe someone after you wants to do the same. and maybe someone
after
that as well. so it somehow needs to be generic, and i think something
like
charsequence buildurl() {
return super.buildurl()+myparam=foo;
}
is the only way to do that unfortunately. i dont see how JavaScript will
make that easier.
maybe im just entirely missing the point.
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
oops i forgot the new virtual:
class abstract CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers; ${middle};
moreCucumbers).merge(getMiddle()); }
protected abstract Javascript getMiddle();
}
Jonathan Locke wrote:
yeah, it's a little tricky, but i think the inheritance hierarchy can
provide the levels you're looking for (sort of as it does now) with
overrides and calls to super. i'm not sure exactly what you are asking
me
to do, but the code might look like this (if i understand you right):
class QueryGoogle
{
JavaScript getScript()
{
final JavaScript script = new JavaScript(function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
return script.merge(query, getQuery(), success,
getSuccess(),
failure, getFailure());
}
protected abstract JavaScript getQuery();
protected JavaScript getSuccess() { return JavaScript.EMPTY; }
protected JavaScript getFailure() { return JavaScript.EMPTY; }
}
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers); }
}
class ThrottlingCucumberQuery extends CucumberQuery
{
JavaScript getQuery() { return new
ThrottlingDecorator(super.getQuery()); }
}
class NoTomatoAndAlertCucumberQuery extends CucumberQuery
{
JavaScript noTomatoes = new JavaScript(...);
JavaScript alert = new JavaScript(...);
JavaScript getQuery() { return
super.getQuery().append(noTomatoes).append(alert); }
}
Of course, if the cucumber script supports some kind of merging, it
would
have to provide insertion points, like:
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers;
${middle};
moreCucumbers); }
}
igor.vaynberg wrote:
so you got single level layering
but what about multi level?
lets say our default ajax behavior returns this:
JavaScript code = new JavaScript(
function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
now something down the road wants to search google for cucumbers
so it does
return code.merge(query,cucumbers);
something later down the road wants to exclude tomatoes from the
search
results, and also add an alert on failure, but since the previous
script
lost all the placeholders how would that work? i mean its really use
it
or
lose it.
unless the previous script that added cucumbers now provides its own
placeholders for all the previous placeholders, but these need to be
factored into functions or some such.
could you show me what that would look like with your code?
so...
JavaScript code = new JavaScript(
function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
one layer adds cucumbers to the query
the next layer excludes tomatoes and adds an alert on failure
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
A throttling decorator would look like this:
public static class ThrottlingDecorator extends JavaScript {
private static final JavaScript THROTTLER = new JavaScript(
wicketThrottler.throttle('${id}', ${milliseconds},
Re: JavaScript object
your buildurl example cannot benefit from JavaScript because it is not
constructing code. it is constructing something to be merged into code, and
the way you've coded it below is exactly right. you'd just merge that in
with getUrl() overrides and super exactly the way you'd think. but for
cases where it's code, you give users a bunch of nice extensible OO tools
for constructing scripts. that's certainly better than String, imo.
Jonathan Locke wrote:
don't forget that a javascript decorator isa JavaScript, so you can nest
them arbitrarily:
public static class ThrottlingDecorator extends JavaScript {
}
JavaScript code = new WhateverDecorator(new ThrottlingDecorator(script));
i'm still not getting what you think is missing from this solution. it
could be that i don't
understand the requirements fully, but this solution i'm proposing
definitely decorates
to any number of levels you want.
igor.vaynberg wrote:
im not getting the warm and fuzzy about this. i want to, but im not.
take our base query which has the similar success and failure points as
my
example. in order to facilitate those you still need the generic
ajaxcalldecorator design because those placeholders are inherited
across
all layers, and JavaScript doesnt support this.
further what you have done is design a hierarchy where each layer builds
on
the previous. but that means each layer has to know the previous layers'
class so it can override the proper places. this is not true in our ajax
support. we need to be able to decorate things generically.
like what you have done today - add a parameter to the back of the url.
well, maybe someone after you wants to do the same. and maybe someone
after
that as well. so it somehow needs to be generic, and i think something
like
charsequence buildurl() {
return super.buildurl()+myparam=foo;
}
is the only way to do that unfortunately. i dont see how JavaScript will
make that easier.
maybe im just entirely missing the point.
-igor
On 4/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
oops i forgot the new virtual:
class abstract CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers; ${middle};
moreCucumbers).merge(getMiddle()); }
protected abstract Javascript getMiddle();
}
Jonathan Locke wrote:
yeah, it's a little tricky, but i think the inheritance hierarchy can
provide the levels you're looking for (sort of as it does now) with
overrides and calls to super. i'm not sure exactly what you are
asking
me
to do, but the code might look like this (if i understand you right):
class QueryGoogle
{
JavaScript getScript()
{
final JavaScript script = new JavaScript(function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
return script.merge(query, getQuery(), success,
getSuccess(),
failure, getFailure());
}
protected abstract JavaScript getQuery();
protected JavaScript getSuccess() { return JavaScript.EMPTY; }
protected JavaScript getFailure() { return JavaScript.EMPTY; }
}
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers); }
}
class ThrottlingCucumberQuery extends CucumberQuery
{
JavaScript getQuery() { return new
ThrottlingDecorator(super.getQuery()); }
}
class NoTomatoAndAlertCucumberQuery extends CucumberQuery
{
JavaScript noTomatoes = new JavaScript(...);
JavaScript alert = new JavaScript(...);
JavaScript getQuery() { return
super.getQuery().append(noTomatoes).append(alert); }
}
Of course, if the cucumber script supports some kind of merging, it
would
have to provide insertion points, like:
class CucumberQuery
{
JavaScript getQuery() { return new JavaScript(cucumbers;
${middle};
moreCucumbers); }
}
igor.vaynberg wrote:
so you got single level layering
but what about multi level?
lets say our default ajax behavior returns this:
JavaScript code = new JavaScript(
function
wget(
http://www.google.com/q=${query},function(){${success}},function(){${failure}}
);
now something down the road wants to search google for cucumbers
so it does
return code.merge(query,cucumbers);
something later down the road wants to exclude tomatoes from the
search
results, and also add an alert on failure, but since the previous
script
lost all the placeholders how would that work? i mean its really use
it
or
lose it.
unless the previous script that added cucumbers now provides its own
placeholders for all the previous placeholders, but these need to be
factored into functions or some such.
could you show me what that would look like with your code?
so...
JavaScript code = new JavaScript(
function
wget(
Re: [vote] Release Wicket 1.2.6
On 20.4.2007, at 1.52, Martijn Dashorst wrote: [x] Release wicket 1.2.6 regardless if these four issues are resolved [ ] Release wicket 1.2.6 but I'll make sure these get fixed [ ] Don't release wicket 1.2.6 until these four issues are resolved
