Wicket Stuff commit access
Dear Wicket developers, I need wicketstuff commit acces for jWicket. My username at github is StefanLindner -- Stefan
RE: Future hosting of wicket stuff
+1 for Apache. Let's keep Wicketstuff as close as possible to wicket. Stefan
RE: [vote] Revert WICKET-2846
-1 Stefan
RE: [Vote] Release wicketstuff-core 1.4.7
[ x ] - release wicketstuff-core 1.4.7
AW: [vote] Release Wicket 1.4.9
[x] Yes, release Stefan
RE: wicket 1.5 build is failing because of 1.6 deps...
It's just the question: Will 1.5 sttill be available for the public in 2011 or 2012? Or 2013 when Wicket 1.5 is accepted by dinosours that want to stay with 1.3. The same argument as for java 1.5 is: stay with Wicket 1.4. oder even 1.3 I'ts quite stable. AND: It's old, it's outdated then. You can safely use it. No risk to be up to date. Stefan -Ursprüngliche Nachricht- Von: Neil Curzon [mailto:neil.cur...@gmail.com] Gesendet: Dienstag, 22. Dezember 2009 04:33 An: dev@wicket.apache.org Betreff: Re: wicket 1.5 build is failing because of 1.6 deps... -1 to JDK 1.6 The possibility of excluding even 1% of potential users for the negligible benefit of using 1.6-specific features would be a bad decision. 1.5 is simply the right jdk to be developing frameworks in for now. Pro 1.6 crowd: Understand that the argument is not that anybody's organization *should* stay with JDK 1.5, but that some organizations *will* stay at 1.5 regardless of whether you think they should be up to date. If the jump from 1.5 to 1.6 was as big as the jump from 1.4 to 1.5, I would be firmly in the pro-1.6 camp, but the benefits just aren't worth the costs. On Sat, Dec 19, 2009 at 4:57 PM, Vit Rozkovec wrote: > + 1 to move on. > > Just that it is the way it is does not mean it has to be the way it is. > > Vitek > > > >> I don't like it either but thats just the way it is in the enterprise >> business ;-( >> >> --- Original Nachricht --- >> Absender: Johan Compagner >> Datum: 15.12.2009 12:42 >> >> >>> i cant believe that..java 6 is already out for years.. they are already >>> at >>> update 17.. >>> java 5 was sep 2004! >>> java 6 dec 2006 >>> >>> thats already 3 years ago.. >>> >>> I cant beleive that there are many still on java 5 they really should >>> upgrade because java 6 didnt maybe bring much api wise >>> but performance wise it was quite a good jump. >>> >>> Besides that when wicket 1.5 will be released we will be i guess at least >>> half next year >>> then java 7 is almost there. (i think... java 7 is just a bit question >>> mark) >>> >>> >>> >>> On Tue, Dec 15, 2009 at 12:36, Carl-Eric Menzel < >>> cm.wic...@users.bitforce.com> wrote: >>> >>> >>> On Tue, 15 Dec 2009 11:44:23 +0100 Martijn Dashorst wrote: > I was going to propose a vote in that direction... as JDK 1.5 has been > shelved... > > > It'll be years until Java 1.6 is as common as 1.5 is now. There are many organizations who have only just completed the move to 1.5. I think going to a strict requirement for Java 1.6 would be a really bad idea, especially since it does not offer as many significant new benefits as 1.5 did. Offering 1.6-specific features in a separate jar would be a simple and pretty good solution, I think. Stuff like the typesafe model would thus be available for those who need it, without leaving anybody needlessly stranded. Carl-Eric >>> >> >> >> > >
RE: [vote] release wicket 1.4.5
+1 Stefan
RE: New german Wicket book (was: Re: wicket 1.5 build is failing because of 1.6 deps...)
Amazon just informed me that it is available and will be shipped today. Stefan -Ursprüngliche Nachricht- Von: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] Gesendet: Dienstag, 15. Dezember 2009 14:35 An: dev@wicket.apache.org Betreff: New german Wicket book (was: Re: wicket 1.5 build is failing because of 1.6 deps...) Since the question about availability came up now :-) We (Roland Förther, Carl-Eric Menzel, Olaf Siefart) just released our new german-language Wicket book, called "Wicket: Komponentenbasierte Webanwendungen in Java", published by dpunkt Verlag. I was told a few minutes ago that it was shipped to retailers and distributors like Amazon.de yesterday. It should probably be available in the stores by the end of this week or at the latest early next week. Carl-Eric -- Carl-Eric Menzel Das neue deutschsprachige Wicketbuch: Wicket: Komponentenbasierte Webanwendungen in Java http://www.wicketbuch.de/ On Tue, 15 Dec 2009 13:52:32 +0100 Michael Mosmann wrote: > Am Dienstag, den 15.12.2009, 13:39 +0100 schrieb Carl-Eric Menzel: > > Carl-Eric Menzel > > Das neue deutschsprachige Wicketbuch: > > Wicket: Komponentenbasierte Webanwendungen in Java > > http://www.wicketbuch.de/ > > Hi, > > .. bei Amazon ist es immer noch nicht lieferbar. Bei dpunkt gibt es > keine Entsprechende Info.. da ich lieber bei Amazon bestellen würde > hier meine Frage: Ist es über dpunkt lieferbar? Wann ist es über > Amazon lieferbar? > > Danke:) > > Michael Mosmann > >
RE: wicket 1.5 build is failing because of 1.6 deps...
+1 for moving toJava 6. Java 5 already has reached it's "End of Service Life" http://java.sun.com/javase/downloads/index_jdk5.jsp and java 7 is coming in early 2010. I remember some people on the list discussed some java7 enhancement that might help making wicket development easier. Asuming that the wicket 1.5 development will last as long as the 1.4 development we can expect wicket 1.5 in late 2010/early 2011. Wicket 1.5 seems to come along with - API breaks - new/enhanced ajax And Wicket 1.5 will last long into 2011 (Wicket 1.5.1, 1.5.2 etc). So why not go to Java6? I think it will be not an easy task to obtain an maintain Java 5 in 2011/2012! Stefan -Ursprüngliche Nachricht- Von: James Carman [mailto:jcar...@carmanconsulting.com] Gesendet: Dienstag, 15. Dezember 2009 13:26 An: dev@wicket.apache.org Betreff: Re: wicket 1.5 build is failing because of 1.6 deps... -1 to moving to 1.6. My client, a global consumer products company, is not on 1.6 yet and it took me YEARS to get 1.5. So, I don't see it happening anytime soon unfortunately. On Tue, Dec 15, 2009 at 7:13 AM, Steve Swinsburg wrote: > Huh? As has been said, Snow Leopard (OS X 10.6) has Java 1.6 by default. > Leopard (OS X 10.5) even has it installed, just not linked by default. > > +1 to moving to Java 1.6. Java 1.5 is past EOL. > > cheers, > Steve > > > > On 15/12/2009, at 10:47 PM, Johan Compagner wrote: > >> mac's should be totally ignored in this area (and all other area's if you >> ask me) >> apple and java is the biggest pile of crap i ever worked with >> >> >> On Tue, Dec 15, 2009 at 12:45, Matej Knopp wrote: >> >>> They do, on snow leopard :) >>> >>> Anyway, I don't feel too strongly about it, certainly won't block 1.6 >>> if others think it's a good idea. >>> >>> -Matej >>> >>> On Tue, Dec 15, 2009 at 12:43 PM, Martijn Dashorst >>> wrote: At our company we've been deploying to 1.6 for over 2 years now. I know... since I'm on a (32bit) Mac and all my co-workers were able to compile against 1.6 leaving me behind... Now that even developers on Macs have Java 6, I seriously think that 1.5 is a dead platform. Martijn On Tue, Dec 15, 2009 at 12:38 PM, Matej Knopp >>> wrote: > I really don't think our core should depend on 1.6. Those few methods > can easyly be put to util classes. Typesafe models can be moved to > separate sub project. I know it makes the build more complicated > again, but 1.6 isn't that common, especially not in production. > > -Matej > > On Tue, Dec 15, 2009 at 12:36 PM, Carl-Eric Menzel > wrote: >> On Tue, 15 Dec 2009 11:44:23 +0100 >> Martijn Dashorst wrote: >> >>> I was going to propose a vote in that direction... as JDK 1.5 has been >>> shelved... >>> >> >> It'll be years until Java 1.6 is as common as 1.5 is now. There are >>> many >> organizations who have only just completed the move to 1.5. I think >> going to a strict requirement for Java 1.6 would be a really bad idea, >> especially since it does not offer as many significant new benefits as >> 1.5 did. >> >> Offering 1.6-specific features in a separate jar would be a simple and >> pretty good solution, I think. Stuff like the typesafe model would thus >> be available for those who need it, without leaving anybody needlessly >> stranded. >> >> Carl-Eric >> > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 >>> > >
RE: [vote] release wicket 1.4.4
[x] release wicket 1.4.4
RE: taking the I out of Interface
I don't have a problem with breaking compatibility. Makeing a step forward and making things better always leaves behind something. Mostly something not so good. I like the way wicket names interfaces with I... and we followed this conventiun in our coding rules. But taking a look at some of our wicket projects shows that we use only a few of Wicket's I... directly - IModel (sure) - ITab - IColumn - ILinkListener - IUnauthorizedComponentInstantiationListener That's nearly all. Only very few others and only one occurence per project. Stefan. -Ursprüngliche Nachricht- Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Gesendet: Samstag, 3. Oktober 2009 03:03 An: dev@wicket.apache.org Betreff: Re: taking the I out of Interface for people who are going to say that this is going to break compatibility: please look through your code and count the number of places where you implement a wicket-specific interface directly. we would like to know how often and what these interfaces are. thanks, -igor On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg wrote: > is it perhaps time to take the I out of our interface names? wicket > has been the only project i have ever worked on/used that follows this > convention, is it time for a change? > > this is not meant as a flamewar about which convention is teh > aw3s0m3st, simply a discussion of whether or not we should switch. > > -igor >
RE: [vote] release 1.4.2 attempt 2
Hello Igor, > [x] Yes release > [ ] No, don't release it and here is why... Stefan
RE: [vote] release 1.4.2
[x] Yes release [ ] No, don't release it and here is why...
RE: [vote] release 1.4.1
[x ] Yes release [ ] No, don't release it -igor
RE: [vote] release wicket 1.4.0
[X ] Yes release 1.4.0 [ ] No, don't release it
RE: 1.4-rc5 - built - but needs to be tested
Tested a few near production applications. No obvious problems found, everything seems to run stable.
RE: Build 1.4-rc5 this weekend?
Yes, it would be very helpful if this cn be fixed before 1.4 goes final. -Ursprüngliche Nachricht- Von: mbrictson [mailto:m...@55minutes.com] Gesendet: Mittwoch, 3. Juni 2009 22:21 An: dev@wicket.apache.org Betreff: Re: Build 1.4-rc5 this weekend? I would very much appreciate a fix for WICKET-2033 before 1.4 goes final. This issue is causing invalid XHTML markup when an ajax form submit is used: the onclick for AjaxButton gets an unescaped "&" instead of "&" (ampersand amp semicolon). https://issues.apache.org/jira/browse/WICKET-2033 I've added a patch to the JIRA ticket, but I'm not familiar enough with the internals of Wicket to know whether the fix is entirely appropriate. Jeremy Thomerson-5 wrote: > > Can everyone please review open issues against 1.4 and see if there is > anything that would prevent me from building 1.4-rc5 this weekend? > Hopefully we could build it and then promote it fairly quickly to > final. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > -- View this message in context: http://www.nabble.com/Build-1.4-rc5-this-weekend--tp23840463p23858735.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
RE: Praise for 1.4 migration
I totally agree to Don's words. That's what I always posted on this list. The 1.4 Generics are real helpful extension to 1.3! -Ursprüngliche Nachricht- Von: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] Gesendet: Sonntag, 1. März 2009 10:48 An: dev@wicket.apache.org Betreff: Praise for 1.4 migration http://donhass.com/2009/02/28/wicket-14-migration/ -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Migrate from 2.0 to 1.4
I remember that I saw a sed script on wicket's wiki some time ago. The scrip did the trick of transforming new Xyz(this, ...) to add(new Xyz...). But I can't find it anymore. Does anybody (the author?) remember this script? Stefan
RE: PDF's filename for dynamically generated PDFs
Hi Matej,
calling
webResponse.setHeader("Content-Disposition", "attachment;
filename=\"yourfile.pdf\"");
has he same effect as
webResponse.setAttachmentHeader("thisIsMySuggesteFilename.pdf");
It displays a dialog window with the choice s to open or to save the PDF
document.
But many thanks for your suggestion
Stefan
-Ursprüngliche Nachricht-
Von: Matej Knopp [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 30. August 2008 01:49
An: dev@wicket.apache.org
Betreff: Re: PDF's filename for dynamically generated PDFs
Perhaps Content-Disposition: Inline; filename="yourfile.pdf" header
could do the trick?
http://www.ietf.org/rfc/rfc2183.txt
-Matej
On Sat, Aug 30, 2008 at 1:40 AM, Stefan Lindner <[EMAIL PROTECTED]> wrote:
> Perhaps this is a general HTML/servlet question but I run into this
> prblem under wicket. I have a link that dynamically generates a pdf. The
> PDF is displayes in apopup page. I use Igor's pattern (see
> http://www.nabble.com/Stream-Excel-to-the-client-td5363673.html#a5364044
> ) and it works very well. The dynamically generated PDF is displayed in
> a popup window. Now, when I try to save the PDF the propsed filaname
> looks like
>
>
> http___localhost_8080_AIOnline_app__wicket_interface=AI-Artikel_2_pdfVer
> sion__ILinkListener__.pdf
>
> Is it possible to have a more meaningful file name suggestion? Having
>
>webResponse.setAttachmentHeader("thisIsMySuggesteFilename.pdf");
>
> gives the appearing dialog a good hint if I klick the save button" but
> the PDF is not automatically displayed in a popup window. Is there any
> resolution for this problem od is this a general HTML/servlet problem?
>
> Stefan
>
PDF's filename for dynamically generated PDFs
Perhaps this is a general HTML/servlet question but I run into this
prblem under wicket. I have a link that dynamically generates a pdf. The
PDF is displayes in apopup page. I use Igor's pattern (see
http://www.nabble.com/Stream-Excel-to-the-client-td5363673.html#a5364044
) and it works very well. The dynamically generated PDF is displayed in
a popup window. Now, when I try to save the PDF the propsed filaname
looks like
http___localhost_8080_AIOnline_app__wicket_interface=AI-Artikel_2_pdfVer
sion__ILinkListener__.pdf
Is it possible to have a more meaningful file name suggestion? Having
webResponse.setAttachmentHeader("thisIsMySuggesteFilename.pdf");
gives the appearing dialog a good hint if I klick the save button" but
the PDF is not automatically displayed in a popup window. Is there any
resolution for this problem od is this a general HTML/servlet problem?
Stefan
Wicket 1.4M3 DateTextField
The DateTextField class reads like
Class DateTextField {
private IConverter converter = null;
public DateTextField(String id, IModel model, String
datePattern)
{
super(id, model, Date.class);
this.datePattern = datePattern;
this.converter = new SqlDateConverter() {};
}
public IConverter getConverter(Class type)
{
if (converter == null)
{
return super.getConverter(type);
}
else
{
return converter;
}
}
}
So it never uses my own Dateconverter since the local veriable
"converter" is always "not null". Of cource, I can override the
getConverter method but that seems not to be the optimal way when I
already registered my own DateConverter in my Application class. What do
think about this?
Stefan
RE: New wicketstuff-dojo project
The current wicketstuff dojo project seems to be no longer supported? I wrote some emails to the listed project maintainers but I received only one reply with no further plan on this project. Sooner or later the current wicketstuff dojo will stop to work with wicket 1.4/1.5. So I definitely prefer to have a new attempt wit dojo 1.1 that is maintained and up-to-date. Stefan
Wicket 1.4 trunk tests fail
Compiling current wicket 1.4 trunk with Java 1.5_15 fails some tests eg.e. INFO - Application- [WicketTester$DummyWebApplication] destroy: Wicket JMX initializer INFO - Application- [WicketTester$DummyWebApplication] destroy: Wicket JMX initializer ERROR - Initializer- WicketTester$DummyWebApplication-3:type=Application javax.management.InstanceNotFoundException: WicketTester$DummyWebApplication-3:type=Application at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMB eanServerInterceptor.java:1010) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(De faultMBeanServerInterceptor.java:354) at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.ja va:527) at org.apache.wicket.jmx.Initializer.destroy(Initializer.java:75) at org.apache.wicket.Application.callDestroyers(Application.java:789) at org.apache.wicket.Application.internalDestroy(Application.java:909) at org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplic ation.java:499) at org.apache.wicket.protocol.http.MockWebApplication.destroy(MockWebApplic ation.java:684) at org.apache.wicket.examples.hangman.WordGeneratorTest.tearDown(WordGenera torTest.java:60) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery .java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java :216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBoote r.java:313) at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) ERROR - Initializer- WicketTester$DummyWebApplication-3:type=Application,name=ApplicationSett ings javax.management.InstanceNotFoundException: WicketTester$DummyWebApplication-3:type=Application,name=ApplicationSett ings at com.sun.jmx.interceptor.DefaultMBeanSe
Re: [vote] release Wicket 1.4-m3
[X] release 1.4-m3 Stefan
AW: Wicket 1.4: AjaxButton inconsitency
Wouldn't it be nice to have
class AjaxButton {
T getModelObject();
onSubmit(AjaxRequestTarget target, Form form)
}
Of course only if Components will still be generic. I think this is a nice case
where Generic Components make sense.
Stefan
-Ursprüngliche Nachricht-
Von: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Juni 2008 06:41
An: dev@wicket.apache.org
Betreff: Re: Wicket 1.4: AjaxButton inconsitency
the types of form and button do not have to correlate. furthremore the model of
the button dictates the value attribute, so it should really be class
ajaxbutton extends button
-igor
On Sun, Jun 22, 2008 at 2:18 PM, Stefan Lindner <[EMAIL PROTECTED]> wrote:
> Yes, I know that the wicket developers are rethinking Generics. But I
> think the current 1.4M2 implementation of AjaxButton is not very
> helpful. The AjaxButton componet is the replacement for
> AjaxsubmitButton (written down in the JavaDoc).
>
> Now I have a Form
>
>MyForm {
> ...
> new AjaxButon {
> onSubmit(AjaxRequestTarget target, Form form) {
> }
> }
>}
>
> Why is the Form in the onSubmit method marked as ? Why is the
> method in the M2 implementation
>
>public abstract class AjaxButton extends Button {
> ...
> public AjaxButton(String id, final Form< ? > form)
> ...
>}
>
> Should the implementaion not be
>
>public abstract class AjaxButton extends Button {
> ...
> public AjaxButton(String id, final Form form)
> ...
> onSubmit(AjaxRequestTarget target, Form form)
> ...
>}
>
> so that the onSubmit method can be overrritten like
>
>@Override
>onSubmit(AjaxRequestTarget target, Form form) {
> X modelObject = form.getModelObject();
>}
>
> Currently the situation is
>
>@Override
>onSubmit(AjaxRequestTarget target, Form form) {
> Object modelObject = form.getModelObject();
>}
>
> and a typecat is needed.
>
> Stefan
>
Wicket 1.4: AjaxButton inconsitency
Yes, I know that the wicket developers are rethinking Generics. But I
think the current 1.4M2 implementation of AjaxButton is not very
helpful. The AjaxButton componet is the replacement for AjaxsubmitButton
(written down in the JavaDoc).
Now I have a Form
MyForm {
...
new AjaxButon {
onSubmit(AjaxRequestTarget target, Form form) {
}
}
}
Why is the Form in the onSubmit method marked as ? Why is the method
in the M2 implementation
public abstract class AjaxButton extends Button {
...
public AjaxButton(String id, final Form< ? > form)
...
}
Should the implementaion not be
public abstract class AjaxButton extends Button {
...
public AjaxButton(String id, final Form form)
...
onSubmit(AjaxRequestTarget target, Form form)
...
}
so that the onSubmit method can be overrritten like
@Override
onSubmit(AjaxRequestTarget target, Form form) {
X modelObject = form.getModelObject();
}
Currently the situation is
@Override
onSubmit(AjaxRequestTarget target, Form form) {
Object modelObject = form.getModelObject();
}
and a typecat is needed.
Stefan
Re: [vote] release wicket-1.3.4
[ x ] release wicket 1.3.4 [ ] don't release wicket 1.3.4, because... Stefan
Wicket 1.4: AjaxLazyLoadPanel not generic
I'm sorry for bringing the Generic discussion back again, but shouldn't AjaxLazyLoadPanel be generic too? It extends Panle which itself is generic. Stefan
Wicket 1.4 and wicket.ajax.ClientEvent
Wicket 2.0 had a Class called "wicket.ajax.ClientEvent" where all the event names like "onchange" where defined in an enum. This enum class was used as Parameter for e.g. the Constructor "new AjaxFormComponentUpdatingBehavior(ClientEvent.CHANGE)". Are there plans for implementing this in Wicket 1.4 again? Stefan
RE: Wicket 1.4: getApplication final?
Eelco Hillenius: > It's one of these methods we actually wanted to get rid off in the long term. It would be best to have just one way to get the > application: MyApplication.get(). Same goes for session and request cycle. OK! So we will switch to the static style solutin. Thank you! Stefan
Re: Wicket 1.4: getApplication final?
Igor:
>that doesnt really help much as it only works for that one compnent
class. it is much nicer to have one global solution such as
>MyApplication.get(). but thats just my two cents.
>
>-igor
>
>>On Sun, Jun 15, 2008 at 1:15 PM, Stefan Lindner <[EMAIL PROTECTED]>
wrote:
>> Why is the Component's getApplication method final? In formwer Wicket
>> versions I could have
>>
>>class MyApplication extends Application.
>>
>>class MyComponent {
>>public MyApplication getApplication() {
>>return
(MyApplication)(super.getApplication());
>>}
>>}
>>
>> This made life a bit easier.
>>
>> Stefan
That might be your "two cents", but is there a real reason why
getApplicationis final? :-)
We have a lot of generic Pages like
public abstract class VWebPage extends WebPage {
@SuppressWarnings("unchecked")
public A getMyApplication() {
return (A)(super.getApplication());
}
}
and application pages like
public abstract class MyAppsWebPage extends VWebPage{
public MyAppsWebPage() {
super();
}
public MyAppsWebPage(final IModel model) {
super(model);
}
}
A concrete Page or an Application then is
public class MyRealPage extends MyAppsWebPage {
...
getApplication().callMyApplicationsMethod
}
This might not be Wicket's intended way to use getApplication But is
there a real serious reason to make getApplication final? Which problem
so I run into when I use this pattern?
Stefan
Wicket 1.4: getApplication final?
Why is the Component's getApplication method final? In formwer Wicket
versions I could have
class MyApplication extends Application.
class MyComponent {
public MyApplication getApplication() {
return (MyApplication)(super.getApplication());
}
}
This made life a bit easier.
Stefan
Re: Error in current trunk 1.4
I don't want to create too much noise on this list. I will cuntinue to use 1.4M2 so the developers might have the patience to solve real problems. Stefan
Re: Error in current trunk 1.4
org.apache.wicket.Application.callDestroyers(Application.java:789) at org.apache.wicket.Application.internalDestroy(Application.java:909) at org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:499) at org.apache.wicket.protocol.http.MockWebApplication.destroy(MockWebApplication.java:683) at org.apache.wicket.examples.hangman.WordGeneratorTest.tearDown(WordGeneratorTest.java:60) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) -Ursprüngliche Nachricht- Von: Johan Compagner [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 8. Juni 2008 14:30 An: dev@wicket.apache.org Betreff: Re: Error in current trunk 1.4 Test all work.. You are building and testing with java 6? It shoukd be done with 5 for now On 6/7/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > Yes! Of course some tests fail during maven build but that is not > unusual for trunk. > > -Ursprüngliche Nachricht- > Von: Johan Compagner [mailto:[EMAIL PROTECTED] > Gesendet: Samstag, 7. Juni 2008 00:50 > An: dev@wicket.apache.org > Betreff: Re: Error in current trunk 1.4 > > so you have an exception purely at runtime but it compiles correct? > > On Fri, Jun 6, 2008 at 10:17 PM, Stefan Lindner <[EMAIL PROTECTED]> wrote: > >> The class AutoLinkResolver has an inner interface in line 510 >> >>private static interface ITagReferenceResolver >> >> this leads to the following exception when an application is deployed: >> >>ERROR [[/Test]] Exception starting filter Test >>java.lang.NoClassDefFoundError: >> org/apache/wicket/markup/resolver/AutoLinkResolver$ITagReferenceResolver >>at >> org.apache.wicket.protocol.http.WebApplication.internalInit(WebApplic >> a >> ti >> on.java:529) >> at >> org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:5 >> 5 >> 8) >> >> When I make the interface public the applicatioin gets deployed >> correctly. >> >> Shall I report a bug or is this already solved by a developer? >> >> Stefan >> >
AW: Error in current trunk 1.4
Yes! Of course some tests fail during maven build but that is not unusual for trunk. -Ursprüngliche Nachricht- Von: Johan Compagner [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 7. Juni 2008 00:50 An: dev@wicket.apache.org Betreff: Re: Error in current trunk 1.4 so you have an exception purely at runtime but it compiles correct? On Fri, Jun 6, 2008 at 10:17 PM, Stefan Lindner <[EMAIL PROTECTED]> wrote: > The class AutoLinkResolver has an inner interface in line 510 > >private static interface ITagReferenceResolver > > this leads to the following exception when an application is deployed: > >ERROR [[/Test]] Exception starting filter Test >java.lang.NoClassDefFoundError: > org/apache/wicket/markup/resolver/AutoLinkResolver$ITagReferenceResolver >at > org.apache.wicket.protocol.http.WebApplication.internalInit(WebApplica > ti > on.java:529) > at > org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:55 > 8) > > When I make the interface public the applicatioin gets deployed > correctly. > > Shall I report a bug or is this already solved by a developer? > > Stefan >
Error in current trunk 1.4
The class AutoLinkResolver has an inner interface in line 510 private static interface ITagReferenceResolver this leads to the following exception when an application is deployed: ERROR [[/Test]] Exception starting filter Test java.lang.NoClassDefFoundError: org/apache/wicket/markup/resolver/AutoLinkResolver$ITagReferenceResolver at org.apache.wicket.protocol.http.WebApplication.internalInit(WebApplicati on.java:529) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:558) When I make the interface public the applicatioin gets deployed correctly. Shall I report a bug or is this already solved by a developer? Stefan
Re: Scriptaculous events onStart + onEnd
Thank you for your response! I think, I'll contact you directly to avoid
confusion on the dev list.
Stefan
-Ursprüngliche Nachricht-
Von: Ryan Sonnek [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 7. Mai 2008 23:07
An: dev@wicket.apache.org
Betreff: Re: Scriptaculous events onStart + onEnd
for sure. i'd be very interested in collaborating.
i went through the scriptaculous documentation yesterday, but i haven't made
any changes yet. if you have a patch for new features, or changes, feel free
to send them my way.
On Wed, May 7, 2008 at 4:03 PM, Stefan Lindner <[EMAIL PROTECTED]> wrote:
> Dear Ryan,
>
> are you interrested in any collaboration concerning Wicket integration
> of Scriptaculous? E.G. gererifying things like DraggableTarget? I did
> not yet receive any response from you.
>
> Stefan
>
> -Ursprüngliche Nachricht-
> Von: Ryan Sonnek [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 6. Mai 2008 15:51
> An: dev@wicket.apache.org
> Betreff: Re: Scriptaculous events onStart + onEnd
>
> Thanks for the post!
>
> I'm all for extending the scriptaculous project if there are useful
> additions! can you point me to the scriptaculous documentation for
> these hooks? what are they typically used for?
>
> On Tue, May 6, 2008 at 7:40 AM, Stefan Lindner <[EMAIL PROTECTED]>
> wrote:
>
> > Dear Ryan,
> >
> > I have implemented the Scriptaculous dragAndDrop events onStart und
> > onEnd. The implementation is experimental at the moment but it works
> > fine. To do a proper implementation I need to extend the
> > DraggabeBehavior class. Are you interrested in a collaboration in
> > development of Scriptaculous for wicket? Or should I simply generate
> > a patch? The questions I want do discuss are:
> >
> > 1. The DraggableBehavior class has a common respond-method,
> > currently commented as //no callback...yet
> >
> > 2. Now it would be possible to something like
> >
> >enum DragEventType = {NONE, ON_START, ON_END}
> >
> >private DragEventType dragEventType = none;
> >
> >protected DragEventType getEventType( return dragEventType;
> > );
> >
> >
> >protected void respond(AjaxRequestTarget target) {
> >// extract eventType from target
> >dragEventType = extractedEventType;
> >}
> >
> >-
> >
> >The client could do
> >@Overwrite
> >protected void respond(AjaxRequestTarget target) {
> >super(target);
> >
> >switch (getEventType()) {
> >case ON_START
> >case ONENDSTART
> >}
> >}
> >
> > 3. Or we could do something like
> >
> >protected void onStart(AjaxRequestTarget target){}
> >
> >protected void onEnd(AjaxRequestTarget target){}
> >
> >protected void respond(AjaxRequestTarget target) {
> >// extract eventType from target
> >if (eventType == onStart)
> >onStart();
> >else fi (eventType == onEnd)
> >onEnd();
> >}
> >
> >-
> >
> >The client could do
> >@Overwrite
> >protected void onEnd(AjaxRequestTarget target) {
> > // do onEnd processing
> >}
> >
> > 4. In both cases we need something like
> >
> >public void setOnStart(boolean
> > createOnStartListender) ...
> >
> >public void setOnEnd(boolean createOnEndListender) ...
> >
> > 5. We also could implement the onHover event of the DraggableTarget
> > to complete the drag and drop events.
> >
> > Please let me know which was you want to go.
> >
> > Keep on Wicket!
> >
> > Stefan Lindner
> >
> >
>
Re: Scriptaculous events onStart + onEnd
Dear Ryan,
are you interrested in any collaboration concerning Wicket integration of
Scriptaculous? E.G. gererifying things like DraggableTarget? I did not yet
receive any response from you.
Stefan
-Ursprüngliche Nachricht-
Von: Ryan Sonnek [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 6. Mai 2008 15:51
An: dev@wicket.apache.org
Betreff: Re: Scriptaculous events onStart + onEnd
Thanks for the post!
I'm all for extending the scriptaculous project if there are useful additions!
can you point me to the scriptaculous documentation for these hooks? what are
they typically used for?
On Tue, May 6, 2008 at 7:40 AM, Stefan Lindner <[EMAIL PROTECTED]> wrote:
> Dear Ryan,
>
> I have implemented the Scriptaculous dragAndDrop events onStart und
> onEnd. The implementation is experimental at the moment but it works
> fine. To do a proper implementation I need to extend the
> DraggabeBehavior class. Are you interrested in a collaboration in
> development of Scriptaculous for wicket? Or should I simply generate a
> patch? The questions I want do discuss are:
>
> 1. The DraggableBehavior class has a common respond-method, currently
> commented as //no callback...yet
>
> 2. Now it would be possible to something like
>
>enum DragEventType = {NONE, ON_START, ON_END}
>
>private DragEventType dragEventType = none;
>
>protected DragEventType getEventType( return dragEventType; );
>
>
>protected void respond(AjaxRequestTarget target) {
>// extract eventType from target
>dragEventType = extractedEventType;
>}
>
>-
>
>The client could do
>@Overwrite
>protected void respond(AjaxRequestTarget target) {
>super(target);
>
>switch (getEventType()) {
>case ON_START
>case ONENDSTART
>}
>}
>
> 3. Or we could do something like
>
>protected void onStart(AjaxRequestTarget target){}
>
>protected void onEnd(AjaxRequestTarget target){}
>
>protected void respond(AjaxRequestTarget target) {
>// extract eventType from target
>if (eventType == onStart)
>onStart();
>else fi (eventType == onEnd)
>onEnd();
>}
>
>-
>
>The client could do
>@Overwrite
>protected void onEnd(AjaxRequestTarget target) {
>// do onEnd processing
>}
>
> 4. In both cases we need something like
>
>public void setOnStart(boolean createOnStartListender)
> ...
>
>public void setOnEnd(boolean createOnEndListender) ...
>
> 5. We also could implement the onHover event of the DraggableTarget to
> complete the drag and drop events.
>
> Please let me know which was you want to go.
>
> Keep on Wicket!
>
> Stefan Lindner
>
>
Re: Scriptaculous events onStart + onEnd
Hi Ryan,
the documentationURL is http://wiki.script.aculo.us/scriptaculous/show/Draggable
I'm building a calendar application with the ability to
a) klick on an appointment to edit the appointment in a ModalWindow
a) drag and drop the appointment to another free slot in a day's column. So I
have to use an AjaxFallbackLink as the draggable Component. The problem now
with Scriptaculous is that a AjaxFallbackLink generates an onClick event after
it was dropped. So I must distinguish between a pseudo-klick following a drag
operation and a real klick. So I register the onEnd event and set an internal
flag. That was the original reason to implement the onEnd event.
Stefan
-Ursprüngliche Nachricht-
Von: Ryan Sonnek [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 6. Mai 2008 15:51
An: dev@wicket.apache.org
Betreff: Re: Scriptaculous events onStart + onEnd
Thanks for the post!
I'm all for extending the scriptaculous project if there are useful additions!
can you point me to the scriptaculous documentation for these hooks? what are
they typically used for?
On Tue, May 6, 2008 at 7:40 AM, Stefan Lindner <[EMAIL PROTECTED]> wrote:
> Dear Ryan,
>
> I have implemented the Scriptaculous dragAndDrop events onStart und
> onEnd. The implementation is experimental at the moment but it works
> fine. To do a proper implementation I need to extend the
> DraggabeBehavior class. Are you interrested in a collaboration in
> development of Scriptaculous for wicket? Or should I simply generate a
> patch? The questions I want do discuss are:
>
> 1. The DraggableBehavior class has a common respond-method, currently
> commented as //no callback...yet
>
> 2. Now it would be possible to something like
>
>enum DragEventType = {NONE, ON_START, ON_END}
>
>private DragEventType dragEventType = none;
>
>protected DragEventType getEventType( return dragEventType; );
>
>
>protected void respond(AjaxRequestTarget target) {
>// extract eventType from target
>dragEventType = extractedEventType;
>}
>
>-
>
>The client could do
>@Overwrite
>protected void respond(AjaxRequestTarget target) {
>super(target);
>
>switch (getEventType()) {
>case ON_START
>case ONENDSTART
>}
>}
>
> 3. Or we could do something like
>
>protected void onStart(AjaxRequestTarget target){}
>
>protected void onEnd(AjaxRequestTarget target){}
>
>protected void respond(AjaxRequestTarget target) {
>// extract eventType from target
>if (eventType == onStart)
>onStart();
>else fi (eventType == onEnd)
>onEnd();
>}
>
>-
>
>The client could do
>@Overwrite
>protected void onEnd(AjaxRequestTarget target) {
>// do onEnd processing
>}
>
> 4. In both cases we need something like
>
>public void setOnStart(boolean createOnStartListender)
> ...
>
>public void setOnEnd(boolean createOnEndListender) ...
>
> 5. We also could implement the onHover event of the DraggableTarget to
> complete the drag and drop events.
>
> Please let me know which was you want to go.
>
> Keep on Wicket!
>
> Stefan Lindner
>
>
Scriptaculous events onStart + onEnd
Dear Ryan,
I have implemented the Scriptaculous dragAndDrop events onStart und
onEnd. The implementation is experimental at the moment but it works
fine. To do a proper implementation I need to extend the
DraggabeBehavior class. Are you interrested in a collaboration in
development of Scriptaculous for wicket? Or should I simply generate a
patch? The questions I want do discuss are:
1. The DraggableBehavior class has a common respond-method, currently
commented as //no callback...yet
2. Now it would be possible to something like
enum DragEventType = {NONE, ON_START, ON_END}
private DragEventType dragEventType = none;
protected DragEventType getEventType( return dragEventType; );
protected void respond(AjaxRequestTarget target) {
// extract eventType from target
dragEventType = extractedEventType;
}
-
The client could do
@Overwrite
protected void respond(AjaxRequestTarget target) {
super(target);
switch (getEventType()) {
case ON_START
case ONENDSTART
}
}
3. Or we could do something like
protected void onStart(AjaxRequestTarget target){}
protected void onEnd(AjaxRequestTarget target){}
protected void respond(AjaxRequestTarget target) {
// extract eventType from target
if (eventType == onStart)
onStart();
else fi (eventType == onEnd)
onEnd();
}
-
The client could do
@Overwrite
protected void onEnd(AjaxRequestTarget target) {
// do onEnd processing
}
4. In both cases we need something like
public void setOnStart(boolean createOnStartListender)
...
public void setOnEnd(boolean createOnEndListender) ...
5. We also could implement the onHover event of the DraggableTarget to
complete the drag and drop events.
Please let me know which was you want to go.
Keep on Wicket!
Stefan Lindner
AW: [vote] update servlet-api dependency to 2.5
[x] servletapi 2.4 ftw!
RE: [#WICKET-1157] Generic internationalization for Enums
Great! And thank you all (wicket developers) for starting Wicket 1.4 now. Wicket with Generic really rocks! -Ursprüngliche Nachricht- Von: John Krasnay [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 11. April 2008 22:25 An: dev@wicket.apache.org Betreff: Re: [#WICKET-1157] Generic internationalization for Enums On Fri, Apr 11, 2008 at 05:02:47PM -0300, Bruno Borges wrote: > Guys, now that trunk is *generic*, take a look at this issue. ;-) > > https://issues.apache.org/jira/browse/WICKET-1157 > > Regards, > -- > Bruno Borges > blog.brunoborges.com.br > +55 1185657739 Thanks, Bruno! I happen to have an imminent need for both of these components. +1 for inclusion in 1.4 core. jk
RE: planning for Wicket 3.0
Nino Saturnino Martinez Vazquez Wael wrote: >Argh! I like java and I like wicket, what boundarys are you guys reaching that java cant solve? And I then the future in short will be all about alternative languages in jvm, like jruby scala python etc. Why not keep it safe a little longer, but I guess it does not matter if its totally compatible with regular java (only thing that could be annoying is when looking at the source). I think the final target for Wicket 5.0 is brainfuck (http://www.muppetlabs.com/~breadbox/bf/). The Scala implementatioin is just a step towards Brainfuck. But remember: just wicket itself will be written in Scala and because Scala is fully compatible with Java, you can continue to write your code with Java. You just jave to ensure that your Apllication server (Tomcat, Weblogic, etc.) supports Scala. Keep on Wicket! Stefan
RE: VOTE: Issue 1371 wicket.properties cannot be found in OSGi
[ ] do it for 1.3 [x] do it for 1.4
Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1 -Ursprüngliche Nachricht- Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] Gesendet: Montag, 17. März 2008 09:13 An: Wicket Development; Wicket Users Betreff: [vote] Release 1.4 with only generics and stop support for 1.3 This thread is for voting only. Use the [discuss] thread for voicing your opinion or asking questions. This makes counting the votes much easier. The discussion on our development list makes it clear that a lot of folks are anxious for generified models. Most users if not all wish us to release a quick release which is 1.3 + generics. The consequence is that the core team will stop to support 1.3, and that everybody that wishes updates will have to migrate to 1.4, and upgrade to Java 5. Everybody is invited to vote! Please use [ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3 [ ] -1, I need a supported version running on Java 1.4 Let your voices be heard! Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
AW: Planning Wicket Next Generation
That would lead to the same situation as a year ago. The 1.4 (= 1.3 + generics only + no support) users will stuck with this release while 1.5 (=1.3 + generics + new features and may be api breaks) is the future. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jeremy Thomerson Gesendet: Samstag, 15. März 2008 06:38 An: dev@wicket.apache.org Betreff: Re: Planning Wicket Next Generation It may be unlikely, but I foresee a potential problem with this. A lot of us are talking about moving our production apps to this release that includes generics. That means our bread and butter is dependent on it. What if we push out a 1.4-M1 that has generics (+ miscellaneous), then everyone starts working on other things, and in the meantime we discover a bug in M1 that effects us? We can't necessarily just drop in 1.4-M2, because there are likely to be API breaks. Do we all have to manage adding patches to the release (1.4-M1-plus-custom-patches)? That's one of the reasons many companies won't allow a milestone / beta release to be depended on in production. Can we think of another solution? Perhaps 1.4 goes out quick, and to ease the concern of supporting 1.3 / 1.4/ 1.5 concurrently, 1.4 only has limited support - for urgent / critical patches? Or someone from among us that really want generics would be willing to do the merges / etc associated with supporting it? I'm just throwing ideas out there - feel free to shoot me down with a much better idea. Jeremy Thomerson On Fri, Mar 14, 2008 at 6:47 PM, Martijn Dashorst < [EMAIL PROTECTED]> wrote: > This is the plan. > > x-m1 is 1.3 + generics (+ any bugs that could be solved in the mean time). > > x-m2 is what we are planning now. > > Martijn > > On 3/14/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > > And if the wicket core developers do not want to have 1.3 + 1.4 + > > 2.0 in > parallel: I believe that we old wicket 2.0 users could live with xM1 > (=1.3+ Generics) > > > > That means: > > 1. Not need to support more than 2 branches/Versions 2. Very quick > > generics for wicket based upan a stable release 3. We old Wicket 2 > > users now can mitgrate to xM1, having new features > and Generics > > 4. We old Wicket 2 users have to suffer a few API changes until > releasing x but I think we can live with this. > > > > Stefan > > > > -Ursprüngliche Nachricht- > > Von: Martin Benda [mailto:[EMAIL PROTECTED] > > Gesendet: Freitag, 14. März 2008 22:49 > > > > An: dev@wicket.apache.org > > Betreff: Re: Planning Wicket Next Generation > > > > ...and the answer is: We would like to see java5-only major release > *ASAP* If you are going to add many new features in the next major > release, those poor "early 2.0 adopters" (like me and my co-workers) > will have to wait another 6-12 months... > > > > +1 for 1.4 = 1.3 + java5 :-) > > > > Bendis > > > > Dne Friday 14 of March 2008 22:32:35 Igor Vaynberg napsal(a): > > > the question, sounds like, is not whether or not java5 will make > > it > into the next major release - that has always been a given, > > the > question is whether or not the next "major" release should > > simply be > 1.3+java5 stuff ONLY which would allow it to be > > released very > quickly... > > > > > > -igor > > > > > > > > > On Fri, Mar 14, 2008 at 2:25 PM, Martin Benda > > > > <[EMAIL PROTECTED]> wrote: > > > > Dear Wicket devs, > > > > > > > > we are in the same situation too :-) For more than a year we > > are > > stuck to the dead 2.0 branch and are still hopefully > > awaiting the > > new generified major release. Old 2.0 with a few > > patches works > quite > > > > fine but we won't probably survive waiting another year for the > > 1.4/2.0 > release... > > > > > > > > So I'm totally +1 for adding only generics and other Java 1.5 > > > > features in the next major release... > > > > > > > > Regards, > > > > Bendis > > > > > > > > Dne Friday 14 of March 2008 22:14:56 Stefan Lindner napsal(a): > > > > > Dear Philip, > > > > > > > > > > we are in the same situation. Just starting a new project, > > we > > > discussed to write a generic wrapper for all the wicket > > classes > > > (Model, Component, etc.). We are waiting for a > > generic wicket > > wersion > now for a year. H
RE: Planning Wicket Next Generation
And if the wicket core developers do not want to have 1.3 + 1.4 + 2.0 in parallel: I believe that we old wicket 2.0 users could live with xM1 (=1.3 + Generics) That means: 1. Not need to support more than 2 branches/Versions 2. Very quick generics for wicket based upan a stable release 3. We old Wicket 2 users now can mitgrate to xM1, having new features and Generics 4. We old Wicket 2 users have to suffer a few API changes until releasing x but I think we can live with this. Stefan -Ursprüngliche Nachricht- Von: Martin Benda [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 14. März 2008 22:49 An: dev@wicket.apache.org Betreff: Re: Planning Wicket Next Generation ...and the answer is: We would like to see java5-only major release *ASAP* If you are going to add many new features in the next major release, those poor "early 2.0 adopters" (like me and my co-workers) will have to wait another 6-12 months... +1 for 1.4 = 1.3 + java5 :-) Bendis Dne Friday 14 of March 2008 22:32:35 Igor Vaynberg napsal(a): > the question, sounds like, is not whether or not java5 will make it > into the next major release - that has always been a given, the > question is whether or not the next "major" release should simply be > 1.3+java5 stuff ONLY which would allow it to be released very > quickly... > > -igor > > > On Fri, Mar 14, 2008 at 2:25 PM, Martin Benda > > <[EMAIL PROTECTED]> wrote: > > Dear Wicket devs, > > > > we are in the same situation too :-) For more than a year we are > > stuck to the dead 2.0 branch and are still hopefully awaiting the > > new generified major release. Old 2.0 with a few patches works quite > > fine but we won't probably survive waiting another year for the 1.4/2.0 > > release... > > > > So I'm totally +1 for adding only generics and other Java 1.5 > > features in the next major release... > > > > Regards, > > Bendis > > > > Dne Friday 14 of March 2008 22:14:56 Stefan Lindner napsal(a): > > > Dear Philip, > > > > > > we are in the same situation. Just starting a new project, we > > > discussed to write a generic wrapper for all the wicket classes > > > (Model, Component, etc.). We are waiting for a generic wicket > > wersion > now for a year. Having a genierfied wicket version (let's > > call it > 1.4M1 or 2.0M1) wohlg make us sooo happ. > > > > > > Migration to wicket 1.3 was impossible because of heavy generic > > usage > all around our code. It's hard to imagine how to use > > wicket's model > without generics. > > > > > > I totally agree with your opinion: "Quit punishing us 2.0 early > > > adopters already". > > > > > > It is still a pleasuere to use OLD wicket 2.0 and it still works > > > pretty stable. And I am sure it will be much more pleasure to work > > > with a generified wicket 1.4/2.0 > > Stefan > > > > -Ursprüngliche Nachricht- > Von: Philip A. Chapman > > [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 14. März 2008 22:00 > > > An: dev@wicket.apache.org > Betreff: Re: Planning Wicket Next > > Generation > > > > > > ++1 > > > > > > I've been waiting on generics since 2.0 was killed. As an early > > > adopter of 2.0, I've been struggling with a few projects that > > where > written against 2.0. So far, I've fought off the urge to > > convert to > 1.3 simply because it doesn't make sense to rewrite > > for 1.3, then > again for 1.4. Also, these projects make *heavy* > > use of generics and > it would be a terrible pain to re-write them > > without. I'd rather go > straight to the generics version. Quit > > punishing us 2.0 early adopters > already. > > > > > > Jeremy Thomerson wrote: > > > > I definitely don't have any votes in this, but I have several > > > > production apps running with Wicket, and use 1.5 / generics in > > all > > of them. Has there been any discussion of a faster release > > that > > ONLY includes generics? Last I remember, someone had the > > generics > > patch(es) basically done, and just needed to apply them. > > > > > > > > I would really like to see generics soon, but if they get put > > in > > with all the other features for 1.4, it would be 6-9 months > > (at > > least) before I could use them. > > > > > > > > Jeremy Thomerson > > > > -- sent from a wi
RE: Planning Wicket Next Generation
Dear Philip, we are in the same situation. Just starting a new project, we discussed to write a generic wrapper for all the wicket classes (Model, Component, etc.). We are waiting for a generic wicket wersion now for a year. Having a genierfied wicket version (let's call it 1.4M1 or 2.0M1) wohlg make us sooo happ. Migration to wicket 1.3 was impossible because of heavy generic usage all around our code. It's hard to imagine how to use wicket's model without generics. I totally agree with your opinion: "Quit punishing us 2.0 early adopters already". It is still a pleasuere to use OLD wicket 2.0 and it still works pretty stable. And I am sure it will be much more pleasure to work with a generified wicket 1.4/2.0 Stefan -Ursprüngliche Nachricht- Von: Philip A. Chapman [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 14. März 2008 22:00 An: dev@wicket.apache.org Betreff: Re: Planning Wicket Next Generation -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ++1 I've been waiting on generics since 2.0 was killed. As an early adopter of 2.0, I've been struggling with a few projects that where written against 2.0. So far, I've fought off the urge to convert to 1.3 simply because it doesn't make sense to rewrite for 1.3, then again for 1.4. Also, these projects make *heavy* use of generics and it would be a terrible pain to re-write them without. I'd rather go straight to the generics version. Quit punishing us 2.0 early adopters already. Jeremy Thomerson wrote: > I definitely don't have any votes in this, but I have several production apps > running with Wicket, and use 1.5 / generics in all of them. Has there been > any discussion of a faster release that ONLY includes generics? Last I > remember, someone had the generics patch(es) basically done, and just needed > to apply them. > > I would really like to see generics soon, but if they get put in with all the > other features for 1.4, it would be 6-9 months (at least) before I could use > them. > > Jeremy Thomerson > -- sent from a wireless device > > -Original Message- > From: "Johan Compagner" <[EMAIL PROTECTED]> > To: dev@wicket.apache.org > Sent: 3/14/08 4:23 PM > Subject: Re: Planning Wicket Next Generation > > Its not that revolutionairy. > For example if 1.4 was just 1.3+generics then if your project like > vocus thats already on 1.5 it would be a drop in replacement. So api > and 'feature' wise not much has happend then, only easy of development > (for most not all are fans ;)) > > On 3/14/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote: >> On 3/14/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >>> is the next release an evolution or revolution? :) i think first we >>> need to make a list of all major things we want to go into it, and >>> then decide. >> I think it counts as revolutionary: abandoning Java 1.4 is >> revolutionary I think. >> >>> > 2 - are we going to timebox the milestones, or plan on features added? >>> >>> personally i think we should come up with a list of all the features >>> we want, throw them into a backlog, and timebox it. >> See the wishlist: >> http://cwiki.apache.org/WICKET/wicket-14-wish-list.html >> >>> > 3 - how many milestones do we plan? >>> id like 6. 1-4 dev, 5-6 stabalizaton. we were never able to get away >>> with just one beta release before, most bugs are found after we put >>> out the first beta...so i dont expect a lot of bugs to be found >>> until the last dev milestone goes out. >> Fine with me. >> >>> > 4 - which features go into each milestone? >>> what are the features? :) >> :D >> >> http://cwiki.apache.org/WICKET/wicket-14-wish-list.html >> >> Martijn >> >> -- >> Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.1 >> is released Get it now: >> http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 >> > > - -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2udTAdpynRSGw3URAiruAKCHqTPX+C5cmsxYqNTGHHX8SiADOwCeL5s0 vFUNXH0nPIfR1A/qOIknqkU= =dsVB -END PGP SIGNATURE-
AW: [VOTE] Release Apache Wicket 1.3.2
Thank you, it's so easy, as you wrote. My browser seems to have a problem with his cache. He does not find the file. On another computer it works. Sorry for my confusing emails. Stefan -Ursprüngliche Nachricht- Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] Gesendet: Montag, 10. März 2008 11:16 An: dev@wicket.apache.org Betreff: Re: [VOTE] Release Apache Wicket 1.3.2 It is already there. You only need to browse the maven repo. Why is that so hard? http://repo1.maven.org/maven2/org/apache/wicket/wicket/1.3.1/wicket-1.3.1-javadoc.jar Or even better: mvn eclipse:eclipse -DdownloadSources=true will do that automatically for you. Martijn On 3/10/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > I did not mean "include it into the wicket download-zip". I think of > providing a separate file, just the documentation. I think it would be not a > great effort to change the build file. > > Stefan > > > -Ursprüngliche Nachricht- > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > > Gesendet: Montag, 10. März 2008 10:40 > > An: dev@wicket.apache.org > Betreff: Re: [VOTE] Release Apache Wicket 1.3.2 > > > http://repo1.maven.org/maven2/org/apache/wicket/wicket/1.3.1/wicket-1.3.1-javadoc.jar > > Adding this to the download triples the download size which is not > very friendly. > > Martijn > > On 3/10/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > > Of course this is done through maven but If I download a new distribution > (as a simple developer who uses wicket) I have to build the javadoc by myself > (i need maven to install etc). Wouldn't it be nice to have a precompiled > javadoc.jar? > > > > -Ursprüngliche Nachricht- > > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > > Gesendet: Montag, 10. März 2008 09:46 > > An: dev@wicket.apache.org > > Betreff: Re: [VOTE] Release Apache Wicket 1.3.2 > > > > > > That is done through maven. > > > > Martijn > > > > On 3/10/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > > > +1 for releasing it > > > > > > Would it be possible to pack a javadoc.jar within the distribution, od > > > to distribute a separate javadoc.jar file? > > > > > > > > > Stefan > > > > > > > > > -- > > Buy Wicket in Action: http://manning.com/dashorst > > Apache Wicket 1.3.1 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.1 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
RE: [VOTE] Release Apache Wicket 1.3.2
I did not mean "include it into the wicket download-zip". I think of providing a separate file, just the documentation. I think it would be not a great effort to change the build file. Stefan -Ursprüngliche Nachricht- Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] Gesendet: Montag, 10. März 2008 10:40 An: dev@wicket.apache.org Betreff: Re: [VOTE] Release Apache Wicket 1.3.2 http://repo1.maven.org/maven2/org/apache/wicket/wicket/1.3.1/wicket-1.3.1-javadoc.jar Adding this to the download triples the download size which is not very friendly. Martijn On 3/10/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > Of course this is done through maven but If I download a new distribution (as > a simple developer who uses wicket) I have to build the javadoc by myself (i > need maven to install etc). Wouldn't it be nice to have a precompiled > javadoc.jar? > > -Ursprüngliche Nachricht- > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 10. März 2008 09:46 > An: dev@wicket.apache.org > Betreff: Re: [VOTE] Release Apache Wicket 1.3.2 > > > That is done through maven. > > Martijn > > On 3/10/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > > +1 for releasing it > > > > Would it be possible to pack a javadoc.jar within the distribution, od > > to distribute a separate javadoc.jar file? > > > > > > Stefan > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.1 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
RE: [VOTE] Release Apache Wicket 1.3.2
Of course this is done through maven but If I download a new distribution (as a simple developer who uses wicket) I have to build the javadoc by myself (i need maven to install etc). Wouldn't it be nice to have a precompiled javadoc.jar? -Ursprüngliche Nachricht- Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] Gesendet: Montag, 10. März 2008 09:46 An: dev@wicket.apache.org Betreff: Re: [VOTE] Release Apache Wicket 1.3.2 That is done through maven. Martijn On 3/10/08, Stefan Lindner <[EMAIL PROTECTED]> wrote: > +1 for releasing it > > Would it be possible to pack a javadoc.jar within the distribution, od > to distribute a separate javadoc.jar file? > > > Stefan > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
RE: [VOTE] Release Apache Wicket 1.3.2
+1 for releasing it Would it be possible to pack a javadoc.jar within the distribution, od to distribute a separate javadoc.jar file? Stefan
Timeline for 1.4 oder 2.0
Dear wicket developers, I have to start a new wicket project in the next few weeks. Is there any timeline for starting wicket 1.4/2.0 development (Java 3 wicket)? Stefan Lindner
AW: 1.4/2.0 annotations support
@HomePage wuold not be very handy. Assume you have more than one page annotated with @HomePage. Which should be the REAL homepage? Or should this result in an error message during deployment? Stefan -Ursprüngliche Nachricht- Von: Eduardo Ito [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 10. Januar 2008 14:29 An: dev@wicket.apache.org Betreff: Re: 1.4/2.0 annotations support I agree... What is the *advantage* of putting the mount definition in an annotation? Following the same pattern, we would create a bunch of annotations like @PageSettings, @HomePage, etc... argh! On 1/10/08, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > I suggest we take a look at annotations for: > > * the mount with a page > > A disadvantage to doing that imho is that you'll have those > definitions scattered throughout. Right now we steer people to do it > in one place. > > Eelco > -- Eduardo Issao Ito Summa Technologies "Discipline is never an end in itself, only a means to an end"
AW: beta 5 this weekend?
You are asking the same question as I do for myself. How and when can we wicket 2.0 users can continue to use current wicket versions. -Ursprüngliche Nachricht- Von: Philip A. Chapman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 22. Oktober 2007 17:32 An: dev@wicket.apache.org Betreff: Re: beta 5 this weekend? On Mon, 2007-10-22 at 11:13 +0200, Johan Compagner wrote: > but i am already in a none api break mode at this time I still hope > that all the refactoring we have done in 1.3 will result in a much > stabler api from now on For example i don't see the major interfaces > like all the model interfaces/classes change now much anymore. > I guess the same is true for validators/behaviors. There are a few projects that I have been holding out for the wicket 1.4/1.5/whatever with generics. When you say "now on", it seems as if you think the API is pretty stable for the foreseeable future and that maybe we will not be moving to generics any time soon? Am I the very last one holding out hope for wicket to pick generics back up? I'd kinda like to know where we are heading and how long it might take so that I can either plan for continuing to support our branch of old 2.0 or down-grade (cross-grade?) my projects to 1.3. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
