Re: [Wicket-user] complex forms w/ dynamic name/id attributes
why are the names not unique?Which names?It should work fine building those forms. Just use setOptimizedRemoval(true) on the listviewso that it doesn't regenerate youre form everytime.johan On 2/13/06, VGJ [EMAIL PROTECTED] wrote: I understand simple wicket forms at least a little now...but I'mreally starting to struggle w/ things beyond the trivial when it comesto forms.I'm also having some trouble locating some real solidexamples or documentation...the API reference stops being helpful really quick.The wicket-examples aren't bad but aren't that greateither...am I missing some documentation somewhere that might behelping me better?The wiki doesn't appear to be complete just yet.I'm loving wicket but having a hard time taking it too far since the documentation seems to be so sparse!Anhow...let's say I've got a List of data...I map it to a table rowin wicket using tr wicket:id= ... and the list is displayed on thepage.Now I need to add a radio button list, textbox, and submit button for each item in the listwhich would submit the form thatthe entire table is wrapped in...how can this be done w/o generatingan error?Obviously, the names aren't unique so an exception isthrown. Here's an example...a table w/ a dynamic row-set...w/ nested radiobutton list(s)table border=1 width=100% cellpadding=3 cellspacing=0tr wicket:id=mydatalist span valign=top wicket:id=rclist id=statusrctdinput type=radio //tdtdinput type=radio / /tdtdinput type=radio //td/span...I'm stumped, can't find a good example of a RadioChoice beyond here's the control packed w/ a simple array as an example type of stuff.How do I programmatically set one of the controls checked if acertain condition is true?A lot of the stuff I'm doing these days pertains to dynamically building forms like this.Thanks in advance!-v---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
We are starting a Wicket project, we use JDK 1.4 because our old software can't run on 1.5. It's a problem, to move to 1.5, but we will eventually do it. But will take a few years. So I vote for waiting with Java 1.5 until Wicket version 3.0. On 2/14/06, wang lei [EMAIL PROTECTED] wrote: Here is my opinions: - should the post 1.2 version of Wicket involve both changes? Absolutely not. I support the constructor change ,because it force the programmer to do in a right way. I don't want wicket support JDK1.5 soon. I know generics can bring many benefits.But there is a long time before most of us move to JDK1.5. Some projects from my clients are stilling run on JDK1.4 even JDK1.3.One year ,at least, is necessary for waiting. My clients would just move to JDK1.4 easily,because they need to pay a lot of money and not sure the old software can move to the new JDK easily. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? No, one version is enough. Wicket2 or wicket3 are not important. I think if you move to JDK1.5 too soon.You will lose many users.It's not good for wicket. Wicket still has a long way to go. - how many of you s till require for current or future projects to run on JDK 1.4? In fact,this question is suitable.Most time,the clients choose the platform,instead of us. Many clients are running different jdk, I can't predict. But for you,i would prefer JDK1.4. - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? I never try to do that. 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！
Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
fine by me but should we make a SimplePageUnauthorizedComponentInstantiationListener(SignIn.class); to simplify itfor usersthen they can do (libray example:) getSecuritySettings().setUnauthorizedComponentInstantiationListener(new SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); // Create a simple authorization strategy, that checks all pages of type // Authenticated web page. SimplePageAuthorizationStrategy authorizationStrategy = new SimplePageAuthorizationStrategy(
AuthenticatedWebPage.class) { protected boolean isAuthorized() {// check whether the user is logged onreturn (((LibrarySession)Session.get()).isSignedIn());
} };Then for all the setSiginPage() users it is jus a matter of relacing it with the above.johanOn 2/14/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah. Another problem with having an application level signin pagesetting is that there might be multiple instead of just one (e.gdepending of the level of authentication, think of how how manybanking apps work), and that authentication might be done outside of
Wicket, in which case you'd rather redirect to a url.EelcoOn 2/13/06, Jonathan Locke [EMAIL PROTECTED] wrote: Eelco tells me that a couple people are complaining about this change and I
wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for 1.2.From here on out, I'd like to see us just fix bugs and
improve the examples and documentation for what we've got. The problem with the sign-in page setting is that (a) it's magical in nature and a bunch of stuff happens behind the scenes that is hard to find and
extend and (b) the setting will not necessarily be respected by Wicket in the future.In fact, if you use the wicket-auth-roles-examples project's authentication package (which I'm hoping will be moved into core in
2.0 when we adopt Java 5), the setting is totally ignored.This becomes very confusing to users who think that the sign-in page is a contract with wicket for authentication.It isn't and cannot be.Igor complained about this and
I agreed with his complaint and so it was removed. The big long scary names of those classes reflect exactly what the classes do.However, nobody really needs to use them directly.The intent of
wicket-auth-roles-examples (we could move this into wicket-auth-roles for 1.2 final if people like that idea) is to make a really simple way to do authentication in Wicket that is (a) not magical and (b) highly extensible
and (c) does not require that you understand much about how it works. Please check out my blog on JRoller where I very briefly discuss this code. And let us know if this is a better approach to authentication.It's my
strong feeling that it is a huge improvement over get/setSignInPage. Best,Jonathan---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
+1 for the Constructor refactoring to 1.3 +1 for Java 1.5 ASAP! I see more and more momentum for 1.5 out amongst our customers and the switch is going on already as more and more realise that it's really not such a scary move. And the fringing faces of the few bound to 1.4 should be weighted to the awe of all not-yet-wicketeers when they discover this extraterrestially excellent framework! Why delay excellency? ;-) | Per Ejeklint Mobile: +46 (0)70-5090052 Web: http://www.ejeklint.se Skype: callto://ejeklint --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
are we sure we just one to package that in the wicket.jar?Why not release it as a seperate jar? What is wrong with that? Then people can choose to use it or not.(just like extentions)We just have to sync the release cycle. On 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote: +1 on Java 5 sooner. for one thing, we can't fold the authentication package into the core until we adopt it. for another, the lack of typesafe models is something we ought to remedy as soon as we possibly can. so i like the idea of doing 1.3 VERY quickly (JUST the constructor change and associated ajax work over a few short weeks) and then immediately have HEAD for 2.0 be Java 5 based. and i'd like us to get 2.0 out pretty quickly too so that WIA can include stuff about typesafe models and so forth. On 2/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Here are mine: The questions I'm seeking answers to are the following:- should the post 1.2 version of Wicket involve both changes?No. The constructor changes first, we can call it 1.3 , and thatversion should be primarily just that change and some minor onesaround it.- should we make different releases for either change, and thus postponing 1.5 toWicket 3? Yes. If we call the constructor change Wicket 1.3, we can call the JDK1.5 version Wicket 2.0.- how many of you still require for current or future projects to run on JDK 1.4?- how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE?I agree with Igor that we should move to 1.5, and don't wait for ayear to do it. Not everyone will be happy with it, but we'll have avery decent version out with 1.3 which we should support for a longtime (by which I mean bug fixing, not so much back porting newfeatures).Moving to 1.5 will eleminate a few of the weak features we still haveand can't fix. As Wicket is all about Java code and strong typing, it sucks we can't have that strong typing in one of our major conceptsyet - the model. With generics we can have this. I think that alone isworth the move, and as a lot of other frameworks - either for UI stuff or other purposes - already moved to 1.5, I don't think it is tooearly. We are already a year further since our first 1.5 discussions.Eelco--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Re: Post 1.2 roadmap and Java 5
Dear Wickt people, here is my choice: Java 5. We ere working with java 5 for more than a year and with EJB3 coming up we have no plans to start a new project with java 1.4. And: java 1.6 is coming! Stefan Lindner -- Visionet GmbH, Am Weichselgarten 7, 91058 Erlangen Tel.: (09131)691-230, FAX: (09131)691-111 E-Mail: mailto:[EMAIL PROTECTED], Internet: http://www.visionet.de --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
having 1.3 with constructor change and fixes and maybe one or 2 things more (ajax related) looks fine to meand then 2.0 with java 5 support.I will then try to backport most wanted features and bug fixes if possible because i can't use
1.5 because manymany customers don't run 1.5 on there servers. And i think that will be so for the comming year. So my focus willthen be on 1.3.XjohanOn 2/14/06,
Martijn Dashorst [EMAIL PROTECTED] wrote:
All,We are of course very busy finalizing Wicket 1.2, and we /really/ hopeto get it done soon. This will benefit everyone. So I want to take alook beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.There are two very big things ahead of us: - constructor refactorwe have reached a limit to the support we want to providefor Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Manyhave been bitten by trying to retrieve an attribute from acomponent tag in the page constructor.We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the componentconstructor, which sets the parent of the component. public MyPage() {WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));c.add(new Label(bar2));c.add(new Label(bar3));add(c); } will become:
public MyPage() { WebMarkupContainer c = new WebMarkupContainer(this, foo); new TextField(c, bar1); new Label(c, bar2);
new Label(c, bar3); }This opens up a lot of better markup parsing strategies for thecore. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward. - java 5 supportThis is something a lot of people are waiting for. I understand thatmany people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,can't move to java 1.5 as a server platform. We don't know howmany users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only supportso many projects. Supporting both a 1.4 and 1.5 project willdrain our resources too far, and won't be possible. So we have to
make a choice.The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus
postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to runon JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run
1.5 code on a 1.4 JRE?Thanks for your answers,Martijn--Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
Hi Igor, I meant something different. What happens, when the user enters the URL http://localhost/foo/ in its browser? I guess, this address is sent to the web server. If it is a passive one, it might redirect the browser to http://localhost/foo/index.html (note, the directory is the same). But the wicket-servlet tells the browser to try it again at http://localhost/foo?page=0 (which is a different directory). Is this correct so far? Just curious, why does the wicket-servlet processes this request, when the servlet-mapping is set to the URL-pattern /foo/*? Tom PS: Please excuse my trivial wordings, these are my first deeper steps in webapp development. Igor Vaynberg wrote: you should put index.html in your context root and have a metaredirect to /foo inside something like this: html head meta http-equiv=Refresh content=0; url=foo /head /html -Igor On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still have a serious problem with resources ( e.g. graphics). The servlet mapping in the web.xml looks like this: servlet-mapping servlet-nameMyWebApplication/servlet-name url-pattern/foo/*/url-pattern /servlet-mapping When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic is shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying the home page with the URL http://localhost:8080/foo/, most likely because it redirects the request to http://localhost:8080/foo?path=0, which is a directory change. Is there a possibility to redirect to http://localhost:8080/foo/index.html http://localhost:8080/foo/index.html or something similar, so the relative paths work as expected? -- Thanks in advance, Tom PS: I'm not experienced with web applications, so please excuse these dumb questions. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
We've tried Retroweaver with our desktop applications and it failed
completely for non-trivial stuff. A few days ago I've tried
Retrotranslator (did not know about it before) and so far I'm very happy
with it and not had any crash.
--
Cheers,
Tom
Jesse Sightler wrote:
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut over now and keep a 1.2 version as a maintenance
branch.
--
Jess
On 2/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing
Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
sure. but call it something more like UnauthorizedPageInstantiationRedirector or even just SimpleAuthenticator.On 2/14/06, Johan Compagner
[EMAIL PROTECTED] wrote:fine by me but should we make a SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); to simplify itfor usersthen they can do (libray example:) getSecuritySettings().setUnauthorizedComponentInstantiationListener(new SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); // Create a simple authorization strategy, that checks all pages of type // Authenticated web page. SimplePageAuthorizationStrategy authorizationStrategy = new SimplePageAuthorizationStrategy(
AuthenticatedWebPage.class) { protected boolean isAuthorized() {// check whether the user is logged onreturn (((LibrarySession)Session.get()).isSignedIn());
} };Then for all the setSiginPage() users it is jus a matter of relacing it with the above.johan
On 2/14/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah. Another problem with having an application level signin pagesetting is that there might be multiple instead of just one (e.gdepending of the level of authentication, think of how how manybanking apps work), and that authentication might be done outside of
Wicket, in which case you'd rather redirect to a url.EelcoOn 2/13/06, Jonathan Locke
[EMAIL PROTECTED] wrote: Eelco tells me that a couple people are complaining about this change and I
wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for 1.2.From here on out, I'd like to see us just fix bugs and
improve the examples and documentation for what we've got. The problem with the sign-in page setting is that (a) it's magical in nature and a bunch of stuff happens behind the scenes that is hard to find and
extend and (b) the setting will not necessarily be respected by Wicket in the future.In fact, if you use the wicket-auth-roles-examples project's authentication package (which I'm hoping will be moved into core in
2.0 when we adopt Java 5), the setting is totally ignored.This becomes very confusing to users who think that the sign-in page is a contract with wicket for authentication.It isn't and cannot be.Igor complained about this and
I agreed with his complaint and so it was removed. The big long scary names of those classes reflect exactly what the classes do.However, nobody really needs to use them directly.The intent of
wicket-auth-roles-examples (we could move this into wicket-auth-roles for 1.2 final if people like that idea) is to make a really simple way to do authentication in Wicket that is (a) not magical and (b) highly extensible
and (c) does not require that you understand much about how it works. Please check out my blog on JRoller where I very briefly discuss this code. And let us know if this is a better approach to authentication.It's my
strong feeling that it is a huge improvement over get/setSignInPage. Best,Jonathan---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
then i prefer SimplePageAuthenticator to be in line wit hthe SimplePageAuthroizationStrategy.But then we have a name that is not directly logical to throw into a setUnauthorizedComponentInstantiationListener
But i guess its fine.On 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote:
sure. but call it something more like UnauthorizedPageInstantiationRedirector or even just SimpleAuthenticator.
On 2/14/06, Johan Compagner
[EMAIL PROTECTED] wrote:fine by me but should we make a SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); to simplify itfor usersthen they can do (libray example:) getSecuritySettings().setUnauthorizedComponentInstantiationListener(new SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); // Create a simple authorization strategy, that checks all pages of type // Authenticated web page. SimplePageAuthorizationStrategy authorizationStrategy = new SimplePageAuthorizationStrategy(
AuthenticatedWebPage.class) { protected boolean isAuthorized() {// check whether the user is logged onreturn (((LibrarySession)Session.get()).isSignedIn());
} };Then for all the setSiginPage() users it is jus a matter of relacing it with the above.johan
On 2/14/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah. Another problem with having an application level signin pagesetting is that there might be multiple instead of just one (e.gdepending of the level of authentication, think of how how manybanking apps work), and that authentication might be done outside of
Wicket, in which case you'd rather redirect to a url.EelcoOn 2/13/06, Jonathan Locke
[EMAIL PROTECTED] wrote: Eelco tells me that a couple people are complaining about this change and I
wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for 1.2.From here on out, I'd like to see us just fix bugs and
improve the examples and documentation for what we've got. The problem with the sign-in page setting is that (a) it's magical in nature and a bunch of stuff happens behind the scenes that is hard to find and
extend and (b) the setting will not necessarily be respected by Wicket in the future.In fact, if you use the wicket-auth-roles-examples project's authentication package (which I'm hoping will be moved into core in
2.0 when we adopt Java 5), the setting is totally ignored.This becomes very confusing to users who think that the sign-in page is a contract with wicket for authentication.It isn't and cannot be.Igor complained about this and
I agreed with his complaint and so it was removed. The big long scary names of those classes reflect exactly what the classes do.However, nobody really needs to use them directly.The intent of
wicket-auth-roles-examples (we could move this into wicket-auth-roles for 1.2 final if people like that idea) is to make a really simple way to do authentication in Wicket that is (a) not magical and (b) highly extensible
and (c) does not require that you understand much about how it works. Please check out my blog on JRoller where I very briefly discuss this code. And let us know if this is a better approach to authentication.It's my
strong feeling that it is a huge improvement over get/setSignInPage. Best,Jonathan---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
In the current version of 1.2 the home page shouldn't be redirected if it was justmounted on / if it was mounted to another path then a redirect is done (in 1.1 this was an option what to do with the home page: redirect to bookmarkable varant, redirect to path=x or don't redirect) johanOn 2/14/06, Tom S. [EMAIL PROTECTED] wrote: Hi Igor,I meant something different. What happens, when the user enters the URLhttp://localhost/foo/ in its browser? I guess, this address is sent tothe web server. If it is a passive one, it might redirect the browser to http://localhost/foo/index.html (note, the directory is the same). Butthe wicket-servlet tells the browser to try it again at http://localhost/foo?page=0 (which is a different directory). Is thiscorrect so far?Just curious, why does the wicket-servlet processes this request, whenthe servlet-mapping is set to the URL-pattern /foo/*? TomPS: Please excuse my trivial wordings, these are my first deeper stepsin webapp development.Igor Vaynberg wrote: you should put index.html in your context root and have a metaredirect to /foo inside something like this: html head meta http-equiv=Refresh content=0; url=""> /head /html -Igor On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still have a serious problem with resources ( e.g. graphics). The servlet mapping in the web.xml looks like this:servlet-mappingservlet-nameMyWebApplication/servlet-nameurl-pattern/foo/*/url-pattern /servlet-mapping When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic is shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying the home page with the URL http://localhost:8080/foo/, most likely because it redirects the request to http://localhost:8080/foo?path=0, which is a directory change. Is there a possibility to redirect to http://localhost:8080/foo/index.html http://localhost:8080/foo/index.html or something similar, so the relative paths work as expected? -- Thanks in advance, Tom PS: I'm not experienced with web applications, so please excuse these dumb questions. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
Hi Johan, Do you also remember, where this option can be set? Thanks in advance, Tom Johan Compagner wrote: In the current version of 1.2 the home page shouldn't be redirected if it was just mounted on / if it was mounted to another path then a redirect is done (in 1.1 this was an option what to do with the home page: redirect to bookmarkable varant, redirect to path=x or don't redirect) johan On 2/14/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Igor, I meant something different. What happens, when the user enters the URL http://localhost/foo/ in its browser? I guess, this address is sent to the web server. If it is a passive one, it might redirect the browser to http://localhost/foo/index.html (note, the directory is the same). But the wicket-servlet tells the browser to try it again at http://localhost/foo?page=0 (which is a different directory). Is this correct so far? Just curious, why does the wicket-servlet processes this request, when the servlet-mapping is set to the URL-pattern /foo/*? Tom PS: Please excuse my trivial wordings, these are my first deeper steps in webapp development. Igor Vaynberg wrote: you should put index.html in your context root and have a metaredirect to /foo inside something like this: html head meta http-equiv=Refresh content=0; url=foo /head /html -Igor On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still have a serious problem with resources ( e.g. graphics). The servlet mapping in the web.xml looks like this: servlet-mapping servlet-nameMyWebApplication/servlet-name url-pattern/foo/*/url-pattern /servlet-mapping When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic is shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying the home page with the URL http://localhost:8080/foo/, most likely because it redirects the request to http://localhost:8080/foo?path=0, which is a directory change. Is there a possibility to redirect to http://localhost:8080/foo/index.html http://localhost:8080/foo/index.html or something similar, so the relative paths work as expected? -- Thanks in advance, Tom PS: I'm not experienced with web applications, so please excuse these dumb questions. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new
Re: [Wicket-user] Post 1.2 roadmap
Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Here is my opinion:+1 for the Constructor refactoring to 1.3 for JDK5 it's better to split another wicket-jdk5.jar so we can benefit from it *now*.And merging both together when wicket 2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package, say,
download one wicket-dep.zip that contains:wicket.jarwicket-jdk5.jarwicket-spring.jarwicket-spring-annot.jarwicket-auth-roles.jarwicket-auth-roles-anont.jaror even better, pack all into one big
wicket-all.jar just like Spring does.On 2/14/06,
Martijn Dashorst [EMAIL PROTECTED] wrote:
All,We are of course very busy finalizing Wicket 1.2, and we /really/ hopeto get it done soon. This will benefit everyone. So I want to take alook beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.There are two very big things ahead of us: - constructor refactorwe have reached a limit to the support we want to providefor Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Manyhave been bitten by trying to retrieve an attribute from acomponent tag in the page constructor.We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the componentconstructor, which sets the parent of the component. public MyPage() {WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));c.add(new Label(bar2));c.add(new Label(bar3));add(c); }
will become:
public MyPage() { WebMarkupContainer c = new WebMarkupContainer(this, foo); new TextField(c, bar1); new Label(c, bar2);
new Label(c, bar3); }This opens up a lot of better markup parsing strategies for thecore. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward. - java 5 supportThis is something a lot of people are waiting for. I understand thatmany people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,can't move to java 1.5 as a server platform. We don't know howmany users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only supportso many projects. Supporting both a 1.4 and 1.5 project willdrain our resources too far, and won't be possible. So we have to
make a choice.The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus
postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to runon JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run
1.5 code on a 1.4 JRE?Thanks for your answers,Martijn--Living a wicket life...Martijn Dashorst -
http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-- Ingram ChenJava [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwanblog: http://www.javaworld.com.tw/roller/page/ingramchen
Re: [Wicket-user] Post 1.2 roadmap
that would be very hard to maintain.For example if you have a panel that is rewritten by using only the new parent in constructor params.And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it.So i do think it is all or nothing.johan On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb:- constructor refactorWow, that's a /major/ change and will probably effect every customcomponent and every application written using Wicket.I see the benefit of having a complete component hierarchy availably right at the initialization of a class.But wouldn't it suffice to just make the new constructors available, andput a clear statement in the API docs? Then maybe deprecate the publicadd() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core.Just get rid of markup, it sucks anyway ;)- java 5 support +1---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
another java5 jar that is an add on for the normal wicket.jar?If we introduce generics i think it will be ALL over the place throughout the complete code base of wicket.There is no real seperation.johan
On 2/14/06, Ingram Chen [EMAIL PROTECTED] wrote:
Here is my opinion:+1 for the Constructor refactoring to 1.3 for JDK5 it's better to split another wicket-jdk5.jar so we can benefit from it *now*.And merging both together when wicket
2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package, say,
download one wicket-dep.zip that contains:wicket.jarwicket-jdk5.jarwicket-spring.jarwicket-spring-annot.jarwicket-auth-roles.jarwicket-auth-roles-anont.jaror even better, pack all into one big
wicket-all.jar just like Spring does.On 2/14/06,
Martijn Dashorst [EMAIL PROTECTED] wrote:
All,We are of course very busy finalizing Wicket 1.2, and we /really/ hopeto get it done soon. This will benefit everyone. So I want to take alook beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.There are two very big things ahead of us: - constructor refactorwe have reached a limit to the support we want to providefor Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Manyhave been bitten by trying to retrieve an attribute from acomponent tag in the page constructor.We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the componentconstructor, which sets the parent of the component. public MyPage() {WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));c.add(new Label(bar2));c.add(new Label(bar3));add(c); }
will become:
public MyPage() { WebMarkupContainer c = new WebMarkupContainer(this, foo); new TextField(c, bar1); new Label(c, bar2);
new Label(c, bar3); }This opens up a lot of better markup parsing strategies for thecore. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward. - java 5 supportThis is something a lot of people are waiting for. I understand thatmany people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,can't move to java 1.5 as a server platform. We don't know howmany users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only supportso many projects. Supporting both a 1.4 and 1.5 project willdrain our resources too far, and won't be possible. So we have to
make a choice.The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus
postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to runon JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run
1.5 code on a 1.4 JRE?Thanks for your answers,Martijn--Living a wicket life...Martijn Dashorst -
http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-- Ingram ChenJava [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwanblog: http://www.javaworld.com.tw/roller/page/ingramchen
Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
yes that is for SimplePageAuthorizationStrategy even easier to use. Only one thing to do/create.johanOn 2/14/06, Mark Derricutt [EMAIL PROTECTED] wrote:On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote: then i prefer SimplePageAuthenticator to be in line wit hthe SimplePageAuthroizationStrategy.But then we have a name that is not directly logical to throw into a setUnauthorizedComponentInstantiationListener But i guess its fine.In my small app I've just made my SimplePageAuthroizationStrategy based class implement IUnauthorizedComponentInstantiationListener and then:myauth = new MyAuth(); setAuthenticationStrategy(myauth);setUnauthorizedComponentInstantiationListener(myauth);It keeps the logic in the same place which suites me.-- i like my video games - mamma said they are gonna melt my brains i like my video games - i don't care what daddy said; they're my reality- henning pauly
[Wicket-user] Example web-applications
Hi, Are there any (open source) wicket-examples available (except the small tutorials), which would help a newbie (like me) very much in finding a lot of answers/solutions for dumb n00b questions? -- Cheers, Tom --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Example web-applications
i think the component reference examples (in our examples project) and all the others are pretty good explaining the basicsbesides that we have examples of spring (in the wicket cvs repository)and in the wicket-stuff cvs repository we have a lot of other example projects (ajax examples like dojo and scriptaculous) and the phonebook example is a good hibernate database example.besides that there is wiki.johanOn 2/14/06, Tom S. [EMAIL PROTECTED] wrote:Hi,Are there any (open source) wicket-examples available (except the small tutorials), which would help a newbie (like me) very much in finding alot of answers/solutions for dumb n00b questions?--Cheers,Tom--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Simplest way to change Date format
Hello, I have a Label that displays a java.util.Date, but I'd like to change the way it is displayed. What is the simplest way to change the format for the label? I tried searching the mailing list but I think it only made me more confused. Thanks. Steve --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params. And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing. I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? That's an option we discussed, and as usual is has opponents and proponents. I am against this as we would end up doing extra work supporting it, probably resulting in a half baked solution. Furthermore, it wouldn't be enough incentive for people to make to move. I am always in favor of clarity and breaking early in these matters. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
After reading everybody's posts and thinking what I myself would want to
have in future wicket releases:
JDK 1.5 support is here for too long not to have it in. I know it's
tough for the people who need to deploy on 1.4 in the future but Os is
supposed to drive innovation. How to do it if wicket doesn't get all the
marvels as generics and annotations in 1.5 while JDK 1.6 is almost beta
? It's gone too far :-), it's just my oppinion, please don't take it as
a critique, it's not. I just believe that in the end 1.5 will bring a
lot more good than bad to wicket users. And I suggest for us/others who
will need 1.4 to use a retrotranslated
(http://retrotranslator.sourceforge.net/ is alive and kicking, is
actively developed in contrast to retroweaver, and people report good
experiences with it) version of a Wicket for JDK 1.5.
Martijn Dashorst wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
preferable not
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
I'm the fortunate one, I can choose the paltform in the majority of my
company's projects. so go jdk1.5. I'm running 1.4 code on it anyway.
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
If it passes all the tests I believe it's acceptable.
Thanks for your answers,
Thanks a lot wicket team for your efforts. It feels bad not having the
time and skills to get involved in development.
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Yeah. One of our most important use of generics would be IModel. It's
just not possible to seperate that from core without having to
maintain seperate code bases.
Eelco
On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote:
another java5 jar that is an add on for the normal wicket.jar?
If we introduce generics i think it will be ALL over the place throughout
the complete code base of wicket.
There is no real seperation.
johan
On 2/14/06, Ingram Chen [EMAIL PROTECTED] wrote:
Here is my opinion:
+1 for the Constructor refactoring to 1.3
for JDK5 it's better to split another wicket-jdk5.jar so we can benefit
from it *now*.
And merging both together when wicket 2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package,
say,
download one wicket-dep.zip that contains:
wicket.jar
wicket-jdk5.jar
wicket-spring.jar
wicket-spring-annot.jar
wicket-auth-roles.jar
wicket-auth-roles-anont.jar
or even better, pack all into one big wicket-all.jar just like Spring
does.
On 2/14/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new
WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this,
foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is
necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand
that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of
you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only
support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have
to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out:
http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Ingram Chen
Java [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwan
blog: http://www.javaworld.com.tw/roller/page/ingramchen
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
Re: [Wicket-user] Example web-applications
And there have been several people that have been writing things. Please see the Wiki for links. For more full features samples from our side, please see (from CVS) wicket-phonebook and wicket-stuff-examples (cd app example). Eelco On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote: i think the component reference examples (in our examples project) and all the others are pretty good explaining the basics besides that we have examples of spring (in the wicket cvs repository) and in the wicket-stuff cvs repository we have a lot of other example projects (ajax examples like dojo and scriptaculous) and the phonebook example is a good hibernate database example. besides that there is wiki. johan On 2/14/06, Tom S. [EMAIL PROTECTED] wrote: Hi, Are there any (open source) wicket-examples available (except the small tutorials), which would help a newbie (like me) very much in finding a lot of answers/solutions for dumb n00b questions? -- Cheers, Tom --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Simplest way to change Date format
If it is a static label, why not just do it in your model? There's
many ways to do that, and here's one:
public class MyPage extends WebPage {
...
public MyPage() {
add(new Label(new PropertyModel(this, getDateFormatted(;
}
private Date getDate() { ... }
private String getDateFormatted() {
return myDateFormat.format(getDate());
}
Overriding the converter is another way, but that more work than
necesarry; you'll usually do that either to have uniformity in your
application and do that on a application level, or do it for
components that need to do input and output and override
Component.getConverter
Eelco
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Example web-applications
Thanks for the example links. I'll take a look at it. Are there any real-world wicket-driven applications available for investigation? ;) Maybe using Java 1.4 and not requiring Maven? Tom Eelco Hillenius wrote: And there have been several people that have been writing things. Please see the Wiki for links. For more full features samples from our side, please see (from CVS) wicket-phonebook and wicket-stuff-examples (cd app example). Eelco On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote: i think the component reference examples (in our examples project) and all the others are pretty good explaining the basics besides that we have examples of spring (in the wicket cvs repository) and in the wicket-stuff cvs repository we have a lot of other example projects (ajax examples like dojo and scriptaculous) and the phonebook example is a good hibernate database example. besides that there is wiki. johan On 2/14/06, Tom S. [EMAIL PROTECTED] wrote: Hi, Are there any (open source) wicket-examples available (except the small tutorials), which would help a newbie (like me) very much in finding a lot of answers/solutions for dumb n00b questions? -- Cheers, Tom --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
it processes because the url http://localhost/foo/index.html matches the /foo/* mapping. see the /foo/ in the url, the /foo/* mapping will match /foo/index.html fragment of the url. i am assuming you are deploying the wicket app in the root context, so users should really be starting at http://localhost/index.html.when your users hit http://localhost/foo/ it will be processed by the wicket servlet. since no page is specified the homepage will be retrieved. does this clear things up?On 2/14/06, Tom S. [EMAIL PROTECTED] wrote: Hi Igor,I meant something different. What happens, when the user enters the URLhttp://localhost/foo/ in its browser? I guess, this address is sent tothe web server. If it is a passive one, it might redirect the browser to http://localhost/foo/index.html (note, the directory is the same). Butthe wicket-servlet tells the browser to try it again at http://localhost/foo?page=0 (which is a different directory). Is thiscorrect so far?Just curious, why does the wicket-servlet processes this request, whenthe servlet-mapping is set to the URL-pattern /foo/*? TomPS: Please excuse my trivial wordings, these are my first deeper stepsin webapp development.Igor Vaynberg wrote: you should put index.html in your context root and have a metaredirect to /foo inside something like this: html head meta http-equiv=Refresh content=0; url=""> /head /html -Igor On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still have a serious problem with resources ( e.g. graphics). The servlet mapping in the web.xml looks like this:servlet-mappingservlet-nameMyWebApplication/servlet-nameurl-pattern/foo/*/url-pattern /servlet-mapping When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic is shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying the home page with the URL http://localhost:8080/foo/, most likely because it redirects the request to http://localhost:8080/foo?path=0, which is a directory change. Is there a possibility to redirect to http://localhost:8080/foo/index.html http://localhost:8080/foo/index.html or something similar, so the relative paths work as expected? -- Thanks in advance, Tom PS: I'm not experienced with web applications, so please excuse these dumb questions. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
On Tuesday 14 Feb 2006 11:43, Eelco Hillenius wrote: move. I am always in favor of clarity and breaking early in these matters. I would certainly rather see wicket become a better framework than be held back by backwards compatibility. Those who are not willing to refactor their ui code can simply keep using wicket 1.2. It is a good product now and always will be! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
does this clear things up? No, not really. it processes because the url http://localhost/foo/index.html matches the /foo/* mapping. see the /foo/ in the url, the /foo/* mapping will match /foo/index.html fragment of the url. This fully is clear, but why http://localhost/foo?page=0 is processed by the /foo/*-mapping? And why does the wicket-servlet redirects to http://localhost/foo?page=0 and not to http://localhost/foo/xyz.abc? I'll ask these things, because this might be the problem why my resource (graphics) cannot not be found. Tom Igor Vaynberg wrote: it processes because the url http://localhost/foo/index.html matches the /foo/* mapping. see the /foo/ in the url, the /foo/* mapping will match /foo/index.html fragment of the url. i am assuming you are deploying the wicket app in the root context, so users should really be starting at http://localhost/index.html. when your users hit http://localhost/foo/ it will be processed by the wicket servlet. since no page is specified the homepage will be retrieved. does this clear things up? On 2/14/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Igor, I meant something different. What happens, when the user enters the URL http://localhost/foo/ in its browser? I guess, this address is sent to the web server. If it is a passive one, it might redirect the browser to http://localhost/foo/index.html (note, the directory is the same). But the wicket-servlet tells the browser to try it again at http://localhost/foo?page=0 (which is a different directory). Is this correct so far? Just curious, why does the wicket-servlet processes this request, when the servlet-mapping is set to the URL-pattern /foo/*? Tom PS: Please excuse my trivial wordings, these are my first deeper steps in webapp development. Igor Vaynberg wrote: you should put index.html in your context root and have a metaredirect to /foo inside something like this: html head meta http-equiv=Refresh content=0; url=foo /head /html -Igor On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still have a serious problem with resources ( e.g. graphics). The servlet mapping in the web.xml looks like this: servlet-mapping servlet-nameMyWebApplication/servlet-name url-pattern/foo/*/url-pattern /servlet-mapping When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic is shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying the home page with the URL http://localhost:8080/foo/, most likely because it redirects the request to http://localhost:8080/foo?path=0, which is a directory change. Is there a possibility to redirect to http://localhost:8080/foo/index.html http://localhost:8080/foo/index.html or something similar, so the relative paths work as expected? -- Thanks in advance, Tom PS: I'm not experienced with web applications, so please excuse these dumb questions. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your
Re: [Wicket-user] URL redirect
Why should it redirect to /foo/xyz.abc?You can do that if you mount bookmarkable pages i guess.What kind of resource is not found?Can you give an example?johan On 2/14/06, Thomas Singer [EMAIL PROTECTED] wrote: does this clear things up?No, not really. it processes because the url http://localhost/foo/index.html matches the /foo/* mapping. see the /foo/ in the url, the /foo/* mapping will match /foo/index.html fragment of the url. This fully is clear, but why http://localhost/foo?page=0 is processed bythe /foo/*-mapping? And why does the wicket-servlet redirects to http://localhost/foo?page=0 and not to http://localhost/foo/xyz.abc?I'll ask these things, because this might be the problem why my resource(graphics) cannot not be found. TomIgor Vaynberg wrote: it processes because the url http://localhost/foo/index.html matches the /foo/* mapping. see the /foo/ in the url, the /foo/* mapping will match /foo/index.html fragment of the url. i am assuming you are deploying the wicket app in the root context, so users should really be starting at http://localhost/index.html . when your users hit http://localhost/foo/ it will be processed by the wicket servlet. since no page is specified the homepage will be retrieved. does this clear things up? On 2/14/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Igor, I meant something different. What happens, when the user enters the URL http://localhost/foo/ in its browser? I guess, this address is sent to the web server. If it is a passive one, it might redirect the browser to http://localhost/foo/index.html (note, the directory is the same). But the wicket-servlet tells the browser to try it again at http://localhost/foo?page=0 (which is a different directory). Is this correct so far? Just curious, why does the wicket-servlet processes this request, when the servlet-mapping is set to the URL-pattern /foo/*? Tom PS: Please excuse my trivial wordings, these are my first deeper steps in webapp development. Igor Vaynberg wrote: you should put index.html in your context root and have a metaredirect to /foo inside something like this: html head meta http-equiv=Refresh content=0; url="" /head /html -Igor On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still have a serious problem with resources ( e.g. graphics). The servlet mapping in the web.xml looks like this:servlet-mappingservlet-nameMyWebApplication/servlet-name url-pattern/foo/*/url-pattern/servlet-mapping When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic is shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying the home page with the URL http://localhost:8080/foo/, most likely because it redirects the request to http://localhost:8080/foo?path=0, which is a directory change. Is there a possibility to redirect to http://localhost:8080/foo/index.html http://localhost:8080/foo/index.html or something similar, so the relative paths work as expected? -- Thanks in advance, Tom PS: I'm not experienced with web applications, so please excuse these dumb questions. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user https://lists.sourceforge.net/lists/listinfo/wicket-user--- This SF.net email is sponsored by:
Re: [Wicket-user] Post 1.2 roadmap
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm +1 for the 1.5 change and the constructor change. I think upgrading
to 1.5 has many advantages and while it sucks for those left on 1.4 (or
god forbid 1.3!) we can't keep dragging our feet for stragglers.
Eelco Hillenius wrote:
Yeah. One of our most important use of generics would be IModel. It's
just not possible to seperate that from core without having to
maintain seperate code bases.
Eelco
On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote:
another java5 jar that is an add on for the normal wicket.jar?
If we introduce generics i think it will be ALL over the place throughout
the complete code base of wicket.
There is no real seperation.
johan
On 2/14/06, Ingram Chen [EMAIL PROTECTED] wrote:
Here is my opinion:
+1 for the Constructor refactoring to 1.3
for JDK5 it's better to split another wicket-jdk5.jar so we can benefit
from it *now*.
And merging both together when wicket 2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package,
say,
download one wicket-dep.zip that contains:
wicket.jar
wicket-jdk5.jar
wicket-spring.jar
wicket-spring-annot.jar
wicket-auth-roles.jar
wicket-auth-roles-anont.jar
or even better, pack all into one big wicket-all.jar just like Spring
does.
On 2/14/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new
WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this,
foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is
necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand
that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of
you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only
support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have
to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out:
http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Ingram Chen
Java [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwan
blog: http://www.javaworld.com.tw/roller/page/ingramchen
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
Re: [Wicket-user] Post 1.2 roadmap
i think wicket starting out on 1.4 will need to stabilize properly on 1.4 before leaping to tiger. even though tiger has many tasty features like annotations and generics but since servers are still quite 1.4 friendly than 1.5, its important to consider that. although if it has to change to 1.5, it should quickly make that jump before the user base grows too big so dat users wont have issues then also if wicket suddenly leverages features in Tiger which many developers may still be learning, it may suddenly affect the learning curve of wicket. on the overall, i want to vote for wicket staying at 1.4 for a while more On 2/14/06, John Patterson [EMAIL PROTECTED] wrote: On Tuesday 14 Feb 2006 11:43, Eelco Hillenius wrote: move. I am always in favor of clarity and breaking early in these matters.I would certainly rather see wicket become a better framework than be heldback by backwards compatibility.Those who are not willing to refactor theirui code can simply keep using wicket 1.2.It is a good product now andalways will be!---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user-- The more life's risk you take, the more life's reward you get - MeAladejebi Ayodeji A., Project Leads PentaSoft Technologies Nigeria LimitedFloor 1, AP Plaza, Ademola Adetokunbo Crescent, Wuse IIAbuja, Nigeria |Tel: 234-09-5233478 | Fax: 234-09-5233470Interested in Java Development?Visit my blog: Ayodeji Aladejebi's JBlog | http://blog.dabarobjects.com/Community: Visit Cowblock.net, Nigeria
Re: [Wicket-user] Post 1.2 roadmap
On Feb 13, 2006, at 4:53 PM, Martijn Dashorst wrote: All, - constructor refactor we have reached a limit to the support we want to provide for Ajax and javascript. In order to provide the best support +1 on the constructor refactor, just means I'll have to convert a few things over once its done .. oh well :) - java 5 support This is something a lot of people are waiting for. I understand that many people want, Igor states /need/, Java 5 support in Wicket. +1 on java 5 support, I've had this in production for at least a year ... and the benefits outweigh any drawbacks. The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? no, get that out the door, and do this for 1.3 or future .. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? bundle it all in one, so the pain is localized and controlled. - how many of you still require for current or future projects to run on JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? Thanks for your answers, Martijn -- Living a wicket life... Martijn Dashorst - http://www.jroller.com/page/dashorst Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel? cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
On Feb 13, 2006, at 5:53 PM, Martijn Dashorst wrote: The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? +1 on the upgrade to 1.5 +1 on adding parent to the constructor 1.2 will serve well for those who can't be bothered to upgrade their JVM, and it has the added benefit of not having to upgrade their framework :-) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
Why should it redirect to /foo/xyz.abc? Because I've entered /foo/ and a typical plain-html-webserver redirects to /foo/index.html. You can do that if you mount bookmarkable pages i guess. I have no clue, how to do that, esp. with the home page. What kind of resource is not found? Can you give an example? I've tried to sketch that in my original posting. Sorry, if it wasn't clear enough. I'll try with different wordings: I enter the URL http://localhost:8080/foo/ in the browser. My Index.html (and the page content ariving my browser) contains a graphic reference to graphics/logo.png (it is found and displayed correctly when I enter the URL http://localhost:8080/foo/graphics/logo.png). Since the wicket-servlet obviously is redirecting to http://localhost:8080/foo?page=0, the browser obviously expects the graphic to be at http://localhost:8080/graphics/logo.png (note the missing /foo after the port!). -- Cheers, Tom Johan Compagner wrote: Why should it redirect to /foo/xyz.abc? You can do that if you mount bookmarkable pages i guess. What kind of resource is not found? Can you give an example? johan On 2/14/06, *Thomas Singer* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: does this clear things up? No, not really. it processes because the url http://localhost/foo/index.html matches the /foo/* mapping. see the /foo/ in the url, the /foo/* mapping will match /foo/index.html fragment of the url. This fully is clear, but why http://localhost/foo?page=0 is processed by the /foo/*-mapping? And why does the wicket-servlet redirects to http://localhost/foo?page=0 and not to http://localhost/foo/xyz.abc? I'll ask these things, because this might be the problem why my resource (graphics) cannot not be found. Tom Igor Vaynberg wrote: it processes because the url http://localhost/foo/index.html matches the /foo/* mapping. see the /foo/ in the url, the /foo/* mapping will match /foo/index.html fragment of the url. i am assuming you are deploying the wicket app in the root context, so users should really be starting at http://localhost/index.html http://localhost/index.html. when your users hit http://localhost/foo/ it will be processed by the wicket servlet. since no page is specified the homepage will be retrieved. does this clear things up? On 2/14/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Igor, I meant something different. What happens, when the user enters the URL http://localhost/foo/ in its browser? I guess, this address is sent to the web server. If it is a passive one, it might redirect the browser to http://localhost/foo/index.html (note, the directory is the same). But the wicket-servlet tells the browser to try it again at http://localhost/foo?page=0 (which is a different directory). Is this correct so far? Just curious, why does the wicket-servlet processes this request, when the servlet-mapping is set to the URL-pattern /foo/*? Tom PS: Please excuse my trivial wordings, these are my first deeper steps in webapp development. Igor Vaynberg wrote: you should put index.html in your context root and have a metaredirect to /foo inside something like this: html head meta http-equiv=Refresh content=0; url=foo /head /html -Igor On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still have a serious problem with resources ( e.g. graphics). The servlet mapping in the web.xml looks like this: servlet-mapping servlet-nameMyWebApplication/servlet-name url-pattern/foo/*/url-pattern /servlet-mapping When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic is shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying the home page with the URL
Re: [Wicket-user] Post 1.2 roadmap
+1 for Jonathan Locke´s statement. regardsOn 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote: +1 on Java 5 sooner. for one thing, we can't fold the authentication package into the core until we adopt it. for another, the lack of typesafe models is something we ought to remedy as soon as we possibly can. so i like the idea of doing 1.3 VERY quickly (JUST the constructor change and associated ajax work over a few short weeks) and then immediately have HEAD for 2.0 be Java 5 based. and i'd like us to get 2.0 out pretty quickly too so that WIA can include stuff about typesafe models and so forth. On 2/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Here are mine: The questions I'm seeking answers to are the following:- should the post 1.2 version of Wicket involve both changes?No. The constructor changes first, we can call it 1.3 , and thatversion should be primarily just that change and some minor onesaround it.- should we make different releases for either change, and thus postponing 1.5 toWicket 3? Yes. If we call the constructor change Wicket 1.3, we can call the JDK1.5 version Wicket 2.0.- how many of you still require for current or future projects to run on JDK 1.4?- how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE?I agree with Igor that we should move to 1.5, and don't wait for ayear to do it. Not everyone will be happy with it, but we'll have avery decent version out with 1.3 which we should support for a longtime (by which I mean bug fixing, not so much back porting newfeatures).Moving to 1.5 will eleminate a few of the weak features we still haveand can't fix. As Wicket is all about Java code and strong typing, it sucks we can't have that strong typing in one of our major conceptsyet - the model. With generics we can have this. I think that alone isworth the move, and as a lot of other frameworks - either for UI stuff or other purposes - already moved to 1.5, I don't think it is tooearly. We are already a year further since our first 1.5 discussions.Eelco--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap (Java {1.}5)
Please ensure, that wicket still can be used on old 1.4 platforms (e.g. with retrotranslator). Not every provider has already switched to Java 1.5. -- Cheers, Tom Tom S. wrote: Java 5 support would be a really big plus (esp. with tools like Retrotranslator and Retroweaver) for me as well. We've tried Retroweaver with our desktop applications and it failed completely for non-trivial stuff. A few days ago I've tried Retrotranslator (did not know about it before) and so far I'm very happy with it and not had any crash. -- Cheers, Tom --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Re: Simplest way to change Date format
This is neither simple nor clever, but it's one way:
public class WicketDateConverter implements IConverter {
private SimpleDateFormat format;
public WicketDateConverter(String formatStr) {
format = new SimpleDateFormat(formatStr);
}
public Object convert(Object value, Class c) {
if (value instanceof Calendar) value = ((Calendar)
value).getTime();
return value == null || value.equals() ? :
format.format(value);
}
public Locale getLocale() {
return Locale.getDefault();
}
public void setLocale(Locale locale) {
// won't be paying attention to this anyway
}
}
Then, in a Page or Panel where you need to display a date,
// if you want to use it in several places on a page
private final WicketDateConverter dateAndTime = new
WicketDateConverter(MMM d, h:mm a);
And for the actual Label:
add(new Label(time) {
public IConverter getConverter() {
return dateAndTime;
}
});
All of this is certifiably nuts, but it's the only way I've found to
crank out dates in whatever format I want for a certain Label. You could
also subclass Label as SimpleDateLabel to avoid having to override
getConverter all the time. Guess I didn't bother that because I figure
the API develop a better way eventually.
Nathan
http://technically.us/n8/
On Tue, 2006-02-14 at 10:27 -0500, Steve Knight wrote:
Hello,
I have a Label that displays a java.util.Date, but I'd like to change
the way it is displayed. What is the simplest way to change the
format for the label?
I tried searching the mailing list but I think it only made me more confused.
Thanks.
Steve
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
Why should it redirect to /foo/xyz.abc?Because I've entered /foo/ and a typical plain-html-webserver redirects to /foo/index.html.Thats not true many serve you the index.html on that dir but in the url you mostly just see /At least for homepages this is mostly the case. What kind of resource is not found? Can you give an example?I've tried to sketch that in my original posting. Sorry, if it wasn'tclear enough. I'll try with different wordings:I enter the URL http://localhost:8080/foo/ in the browser. My Index.html(and the page content ariving my browser) contains a graphic referenceto graphics/logo.png (it is found and displayed correctly when I enter the URL http://localhost:8080/foo/graphics/logo.png). Since thewicket-servlet obviously is redirecting tohttp://localhost:8080/foo?page=0 , the browser obviously expects thegraphic to be at http://localhost:8080/graphics/logo.png (note themissing /foo after the port!). so you just want to mix wicket pages and resources in the root of youre webapplication?Or are you also serving index.html (a plain resource) in the /foo/ dir what is mapped as the wicket servlet url? That shouldn't be done. What does that index.html do?? Move it to the real root of youre webapplication./foo is there for dynamic pages.johan
Re: [Wicket-user] Re: Simplest way to change Date format
It's an area that might see a bit of improvement. The converter code
is completely generic, but unfortunately that doesn't help users
implement their own converters.
Would you mind opening up an RFE for this?
Eelco
On 2/14/06, Nathan Hamblen [EMAIL PROTECTED] wrote:
This is neither simple nor clever, but it's one way:
public class WicketDateConverter implements IConverter {
private SimpleDateFormat format;
public WicketDateConverter(String formatStr) {
format = new SimpleDateFormat(formatStr);
}
public Object convert(Object value, Class c) {
if (value instanceof Calendar) value = ((Calendar)
value).getTime();
return value == null || value.equals() ? :
format.format(value);
}
public Locale getLocale() {
return Locale.getDefault();
}
public void setLocale(Locale locale) {
// won't be paying attention to this anyway
}
}
Then, in a Page or Panel where you need to display a date,
// if you want to use it in several places on a page
private final WicketDateConverter dateAndTime = new
WicketDateConverter(MMM d, h:mm a);
And for the actual Label:
add(new Label(time) {
public IConverter getConverter() {
return dateAndTime;
}
});
All of this is certifiably nuts, but it's the only way I've found to
crank out dates in whatever format I want for a certain Label. You could
also subclass Label as SimpleDateLabel to avoid having to override
getConverter all the time. Guess I didn't bother that because I figure
the API develop a better way eventually.
Nathan
http://technically.us/n8/
On Tue, 2006-02-14 at 10:27 -0500, Steve Knight wrote:
Hello,
I have a Label that displays a java.util.Date, but I'd like to change
the way it is displayed. What is the simplest way to change the
format for the label?
I tried searching the mailing list but I think it only made me more
confused.
Thanks.
Steve
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
Thats not true many serve you the index.html on that dir but in the url you mostly just see / At least for homepages this is mostly the case. Visually it does not change to /foo/index.html, but it behaves like this, because the resources are fetched relative to this path. so you just want to mix wicket pages and resources in the root of youre webapplication? First, /foo/ should be the root of our web-application. According to our provider, we later can map a domain to such a directory, so www.company.com maps to http://ourserver/foo/. At least, that's how I understood it. Or are you also serving index.html (a plain resource) in the /foo/ dir what is mapped as the wicket servlet url? No, there is no index.html anywhere on our server, I just used it to explain my felt difference to a plain html-web-server. -- Cheers, Tom Johan Compagner schrieb: Why should it redirect to /foo/xyz.abc? Because I've entered /foo/ and a typical plain-html-webserver redirects to /foo/index.html. Thats not true many serve you the index.html on that dir but in the url you mostly just see / At least for homepages this is mostly the case. What kind of resource is not found? Can you give an example? I've tried to sketch that in my original posting. Sorry, if it wasn't clear enough. I'll try with different wordings: I enter the URL http://localhost:8080/foo/ in the browser. My Index.html (and the page content ariving my browser) contains a graphic reference to graphics/logo.png (it is found and displayed correctly when I enter the URL http://localhost:8080/foo/graphics/logo.png). Since the wicket-servlet obviously is redirecting to http://localhost:8080/foo?page=0 http://localhost:8080/foo?page=0, the browser obviously expects the graphic to be at http://localhost:8080/graphics/logo.png (note the missing /foo after the port!). so you just want to mix wicket pages and resources in the root of youre webapplication? Or are you also serving index.html (a plain resource) in the /foo/ dir what is mapped as the wicket servlet url? That shouldn't be done. What does that index.html do?? Move it to the real root of youre webapplication. /foo is there for dynamic pages. johan --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Hi,
The main trunk of TestNG (http:/testng.org/) is JDK 1.5 source base. Still we are able to release it
for JDK1.4. The trick is simple: a compiler flag. There is still some small restriction: the code
should not use JDK1.5-only API. If you can avoid this, than I can definitely pass you the details of
how you can build/compiler JDK1.5 source code to be compatible on priori JVMs.
hth,
./alex
--
.w( the_mindstorm )p.
#: Martijn Dashorst changed the world a bit at a time by saying (astral date:
2/14/2006 2:53 AM) :#
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] recommend HTML editor for Wicket user
I am not only new to Wicket; I am also new to web programming. I can read HTML, but Im not fluent in writing it. Any suggestions for a free HTML editor that is appropriate for Wicket users? I presume it should be text-centric rather than a WYSIWYG editor, because we need to keep things clean, small and readable at the tag level. But it would probably be nice if there were a way to view the result at the touch of a button. Also, it should make it easy to produce correct XHTML, especially for someone who has trouble remembering the names of tags.
Re: [Wicket-user] recommend HTML editor for Wicket user
Frank, There are several options. But by far the best one is use a plugin for your IDE. NetBeans and IntelliJ IDEA both have very decent markup editors, with tag completion. Eclipse has a couple of plugins of varying quality. You might want to check out the WTP package. Eclipse has a built in browser, but I tend not to use that, as it gets in the way of editing the file. As I am rather fluent in HTML I usually know what the final result looks like. A very nice workflow is to start Wicket using Jetty launcher, an Eclipse plugin, and run your application in development mode (in your application constructor do: configure(development); This will instruct Wicket to scan for resource updates and will reload your markup as you change it and press the save button. If you run in debug mode, Eclipse will try to hot swap the code as you change it in your application. So you can update that behavior of the onclick method of your button and links! If you don't mind paying a minor fee, you could see if MyEclipse works for you. I don't have other preferences. For basic editing stuff on a windows box I use UltraEdit. Probably the best plain text editor around. Martijn On 2/14/06, Frank Silbermann [EMAIL PROTECTED] wrote: I am not only new to Wicket; I am also new to web programming. I can read HTML, but I'm not fluent in writing it. Any suggestions for a free HTML editor that is appropriate for Wicket users? I presume it should be text-centric rather than a WYSIWYG editor, because we need to keep things clean, small and readable at the tag level. But it would probably be nice if there were a way to view the result at the touch of a button. Also, it should make it easy to produce correct XHTML, especially for someone who has trouble remembering the names of tags. -- Living a wicket life... Martijn Dashorst - http://www.jroller.com/page/dashorst Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] URL redirect
wicket just does everything under /foo?xxxSo if you have plain web resources that are not served by wicket through shared resourcesthen just take that path into account in youre html files On 2/14/06, Tom S. [EMAIL PROTECTED] wrote: Thats not true many serve you the index.html on that dir but in the url you mostly just see / At least for homepages this is mostly the case.Visually it does not change to /foo/index.html, but it behaves like this, because the resources are fetched relative to this path. so you just want to mix wicket pages and resources in the root of youre webapplication?First, /foo/ should be the root of our web-application. According to our provider, we later can map a domain to such a directory, so www.company.commaps to http://ourserver/foo/. At least, that's how I understood it. Or are you also serving index.html (a plain resource) in the /foo/ dir what is mapped as the wicket servlet url?No, there is no index.html anywhere on our server, I just used it to explainmy felt difference to a plain html-web-server. --Cheers,TomJohan Compagner schrieb: Why should it redirect to /foo/xyz.abc? Because I've entered /foo/ and a typical plain-html-webserver redirects to /foo/index.html. Thats not true many serve you the index.html on that dir but in the url you mostly just see / At least for homepages this is mostly the case. What kind of resource is not found? Can you give an example? I've tried to sketch that in my original posting. Sorry, if it wasn't clear enough. I'll try with different wordings: I enter the URL http://localhost:8080/foo/ in the browser. My Index.html (and the page content ariving my browser) contains a graphic reference to graphics/logo.png (it is found and displayed correctly when I enter the URL http://localhost:8080/foo/graphics/logo.png). Since the wicket-servlet obviously is redirecting to http://localhost:8080/foo?page=0 http://localhost:8080/foo?page=0, the browser obviously expects the graphic to be at http://localhost:8080/graphics/logo.png (note the missing /foo after the port!). so you just want to mix wicket pages and resources in the root of youre webapplication? Or are you also serving index.html (a plain resource) in the /foo/ dir what is mapped as the wicket servlet url? That shouldn't be done. What does that index.html do?? Move it to the real root of youre webapplication. /foo is there for dynamic pages. johan---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs. java.util.concurrent and StringBuilder are both supported.-- Jess http://www.jroller.com/page/jsight/On 2/14/06, Erik van Oosten [EMAIL PROTECTED] wrote:I have no personal experience with retrowaever. However, there are many success stories on the internet. I have at least one colleague that usedit without problems.If I understand correctly, there is one slight drawback: you can not usethe new java 5 APIs (like StringBuilder and java.util.concurrent).However, you do get all the new language stuff: generics, extended forloops, static imports, autoboxing/unboxing, varargs, enumerations andannotations.But since the move to java 5 is all about generics and not about API's I would say: go for both!Regards, Erik.JasonB schreef: As Jesse referenced, once we move to Java 1.5 we can still release Java 1.4 versions via tools such as Retroweaver... assuming that the tool works as advertised. Has anyone had more experience in these types of tools?- Jason B.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
On 2/15/06, Jesse Sightler [EMAIL PROTECTED] wrote: Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs. java.util.concurrent and StringBuilder are both supported. Interesting - does it make use of the concurrent-backport and map the bytecode over?-- i like my video games - mamma said they are gonna melt my brainsi like my video games - i don't care what daddy said; they're my reality - henning pauly
Re: [Wicket-user] Re: Simplest way to change Date format
I tried Nathan's suggestion and it seems to work well. Not exactly simple though. I believe RFE [ 1361336 ] already covers this. Thank you both. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Just curious, can you be more specific about problems with Retroweaver?
Thanks,
Gili
Tom S. wrote:
Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
We've tried Retroweaver with our desktop applications and it failed
completely for non-trivial stuff. A few days ago I've tried
Retrotranslator (did not know about it before) and so far I'm very happy
with it and not had any crash.
--
Cheers,
Tom
Jesse Sightler wrote:
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut over now and keep a 1.2 version as a maintenance
branch.
--
Jess
On 2/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this,
foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is
necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I
understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of
you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only
support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we
have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5
Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
Re: [Wicket-user] Post 1.2 roadmap
Instead of introducing extra arguments to the constructor, why not simply move all this logic into a new method? That is, introduce Component.bind(Component parent). We'd benefit from the fact that Wicket components could become JavaBeans and method-based binding is more flexible than constructor-based binding. From past experience, whenever classes require arguments in their constructors there is always some flexibility lost. For example, you absolutely cannot invoke any code before super() if you subclass such a class so if the value of one of the arguments needs to be calculated or modified in any way prior to the super() call you're out of luck. Gili Timo Stamm wrote: Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params. And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing. I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- http://www.desktopbeautifier.com/ --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] recommend HTML editor for Wicket user
2006/2/14, Martijn Dashorst [EMAIL PROTECTED]: Frank,There are several options. But by far the best one is use a plugin foryour IDE. NetBeans and IntelliJ IDEA both have very decent markup editors, with tag completion. Eclipse has a couple of plugins ofvarying quality. You might want to check out the WTP package.Eclipse has a built in browser, but I tend not to use that, as it getsin the way of editing the file. As I am rather fluent in HTML I usually know what the final result looks like.A very nice workflow is to start Wicket using Jetty launcher, anEclipse plugin, and run your application in development mode (in yourapplication constructor do: configure(development); This will instruct Wicket to scan for resource updates and will reloadyour markup as you change it and press the save button. If you run indebug mode, Eclipse will try to hot swap the code as you change it in your application. So you can update that behavior of the onclickmethod of your button and links!If you don't mind paying a minor fee, you could see if MyEclipse works for you.I don't have other preferences. For basic editing stuff on a windows box I use UltraEdit. Probably the best plain text editor around. If you are looking for a free editoruse PSPad. Martijn Dirk On 2/14/06, Frank Silbermann [EMAIL PROTECTED] wrote: I am not only new to Wicket; I am also new to web programming.I can read HTML, but I'm not fluent in writing it.Any suggestions for a free HTML editor that is appropriate for Wicket users? I presume it should be text-centric rather than a WYSIWYG editor, because we need to keep things clean, small and readable at the tag level.But it would probably be nice if there were a way to view the result at the touch of a button.Also, it should make it easy to produce correct XHTML, especially for someone who has trouble remembering the names of tags.--Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1 ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] recommend HTML editor for Wicket user
Ok, here what I do, I seperate classes and HTML in seperate folders, I use Dreamweaver for HTML, it has the option to add attribute to the tags and new tags, so I did, I added wicket:id and I added the wicket tags (remove, panel,...) On 2/15/06, Dirk Markert [EMAIL PROTECTED] wrote: 2006/2/14, Martijn Dashorst [EMAIL PROTECTED]: Frank,There are several options. But by far the best one is use a plugin for your IDE. NetBeans and IntelliJ IDEA both have very decent markup editors, with tag completion. Eclipse has a couple of plugins ofvarying quality. You might want to check out the WTP package.Eclipse has a built in browser, but I tend not to use that, as it getsin the way of editing the file. As I am rather fluent in HTML I usually know what the final result looks like.A very nice workflow is to start Wicket using Jetty launcher, anEclipse plugin, and run your application in development mode (in yourapplication constructor do: configure(development); This will instruct Wicket to scan for resource updates and will reloadyour markup as you change it and press the save button. If you run indebug mode, Eclipse will try to hot swap the code as you change it in your application. So you can update that behavior of the onclickmethod of your button and links!If you don't mind paying a minor fee, you could see if MyEclipse works for you.I don't have other preferences. For basic editing stuff on a windows box I use UltraEdit. Probably the best plain text editor around. If you are looking for a free editoruse PSPad. Martijn Dirk On 2/14/06, Frank Silbermann [EMAIL PROTECTED] wrote: I am not only new to Wicket; I am also new to web programming.I can read HTML, but I'm not fluent in writing it.Any suggestions for a free HTML editor that is appropriate for Wicket users? I presume it should be text-centric rather than a WYSIWYG editor, because we need to keep things clean, small and readable at the tag level.But it would probably be nice if there were a way to view the result at the touch of a button.Also, it should make it easy to produce correct XHTML, especially for someone who has trouble remembering the names of tags.--Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1 ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Regards, Ali
