Re: [Wicket-user] Modifying a div-id
You are aware that in valid HTML the ID of an element should be
unique?
No, I was not aware of this issue, but already wondered, why IDEA
complained. I've changed all id's to class'es and now it should be HTML
conform, right?
--
Cheers,
Tom
Martijn Dashorst schrieb:
Tom,
You are aware that in valid HTML the ID of an element should be
unique? I think that in this case you really mean to use a class.
div wicket:id=news class=newsEntryHot
div wicket:id=date class=newsDatexxx/div
div wicket:id=headline class=newsHeadlinexxx/div
div wicket:id=message class=newsContentxxx/div
/div
And probably even better:
div wicketid=news class=news
...
/div
IModel HOTMODEL = new Model(hot);
IModel NOTMODEL = new Model();
protected void populateItem(ListItem item) {
item.add(new AttributeModifier(class, true, hot ? HOTMODEL : NOTMODEL) {
protected String newValue(final String currentValue, final
String replacementValue)
{
return currentValue + + replacementValue;
}
});
// etc.
}
this will generate the following div for a hot item, and the next for
a not so hot item:
div class=news hotetc/div
div class=newsetc/div
This gives you more power in your CSS to use it to its full potential.
Martijn
On 2/12/06, Tom S. [EMAIL PROTECTED] wrote:
Eelco, thank you very much. I've stripped the redundant span-tags and used
it like that (for those who are interested):
div wicket:id=news id=newsEntryHot
div id=newsDate wicket:id=date06-01-05/div
div id=newsHeadline wicket:id=headlineApp released/div
div id=newsContent wicket:id=messageBla bla/div
/div
and
public class NewsListView extends ListView {
...
private final Model hotModel = new Model(newsEntryHot);
private final Model normalModel = new Model(newsEntryNormal);
public NewsListView(List newsEntries) {
super(news, newsEntries);
}
protected void populateItem(ListItem item) {
final NewsItem news = (NewsItem)item.getModelObject();
item.add(new AttributeModifier(id, true,
news.isHot() ? hotModel : normalModel));
item.add(new Label(date, DATE_FORMAT.format(news.getDate(;
item.add(new Label(headline, news.getHeadline()));
item.add(new Label(message, news.getMessage()));
}
}
--
Cheers,
Tom
Eelco Hillenius schrieb:
or in case you use old skool AttributeModifier
outerDiv.add(new AttributeModifier(id, true, new Model(id)));
Eelco
On 2/12/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah, AttributeModifier is the right way to go. Especially in your
case, because you probably want to do something like this:
Your listview:
...
protected abstract void populateItem(final ListItem item) {
NewsItem newsItem = (NewsItem)item.getModelObject();
String id = (newsItem.isCool()) ? newsEntryHot : newsEntryBoring;
WebMarkupContainer outerDiv = new WebMarkupContainer(outer);
outerDiv.add(new SimpleAttributeModifier(id, id));
item.add(outerDiv);
... // etc
}
Eelco
On 2/12/06, Tom S. [EMAIL PROTECTED] wrote:
Hi all,
I'm new to Wicket and so far I like it. :)
I want to show a small news-list on a page and use a ListView for that. In
the html-page it looks like this:
span wicket:id=news
div id=newsEntryHot
div id=newsDate
span wicket:id=date06-01-05/span
/div
div id=newsHeadline
span wicket:id=headlineApp released/span
/div
div id=newsContent
span wicket:id=messageBla bla/span
/div
/div
/span
We have defined different looks for hot and normal news. Hot news should
have the outer div with id=newsEntryHot, normal ones with a different id.
The information is locally available as a boolean property of the NewsEntry.
How do I change the id-parameter? I've found the AttributeModifier class,
but have not clue, whether it is the right thing and/or how to use it, esp.
the related model.
Thanks in advance,
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=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
[Wicket-user] Graphics, css, html and classes
Hi, At the moment I have following project structure: [root] + [resources] | + style.css | + graphic/logo.png + [src] + [com.blabla.pages] + Index.java + Index.html Index.html references style.css and graphic/logo.png relative to [resources] (which is in the classpath) to ensure the resulting page can reach these resources. But when editing the Index.html, they are not reachable, because they are not available relative to the current package. How do you manage such resources? -- 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] Modifying a div-id
Regarding this issue yes, but I don't know about the rest of your page ;-)MartijnOn 2/13/06, Thomas Singer
[EMAIL PROTECTED] wrote: You are aware that in valid HTML the ID of an element should be
unique?No, I was not aware of this issue, but already wondered, why IDEAcomplained. I've changed all id's to class'es and now it should be HTMLconform, right?--Cheers,Tom
Martijn Dashorst schrieb: Tom, You are aware that in valid HTML the ID of an element should be unique? I think that in this case you really mean to use a class. div wicket:id=news class=newsEntryHot
div wicket:id=date class=newsDatexxx/div div wicket:id=headline class=newsHeadlinexxx/div div wicket:id=message class=newsContentxxx/div
/div And probably even better: div wicketid=news class=news ... /div IModel HOTMODEL = new Model(hot);
IModel NOTMODEL = new Model(); protected void populateItem(ListItem item) { item.add(new AttributeModifier(class, true, hot ? HOTMODEL : NOTMODEL) { protected String newValue(final String currentValue, final
String replacementValue) { return currentValue + + replacementValue; } }); // etc. } this will generate the following div for a hot item, and the next for
a not so hot item: div class=news hotetc/div div class=newsetc/div This gives you more power in your CSS to use it to its full potential.
Martijn On 2/12/06, Tom S. [EMAIL PROTECTED] wrote: Eelco, thank you very much. I've stripped the redundant span-tags and used it like that (for those who are interested):
div wicket:id=news id=newsEntryHotdiv id=newsDate wicket:id=date06-01-05/divdiv id=newsHeadline wicket:id=headlineApp released/div
div id=newsContent wicket:id=messageBla bla/div/div and public class NewsListView extends ListView {
... private final Model hotModel = new Model(newsEntryHot); private final Model normalModel = new Model(newsEntryNormal);
public NewsListView(List newsEntries) { super(news, newsEntries); } protected void populateItem(ListItem item) { final NewsItem news = (NewsItem)item.getModelObject();
item.add(new AttributeModifier(id, true,news.isHot() ? hotModel : normalModel)); item.add(new Label(date, DATE_FORMAT.format(
news.getDate(; item.add(new Label(headline, news.getHeadline())); item.add(new Label(message, news.getMessage())); } }
-- Cheers, Tom Eelco Hillenius schrieb: or in case you use old skool AttributeModifierouterDiv.add
(new AttributeModifier(id, true, new Model(id))); Eelco On 2/12/06, Eelco Hillenius [EMAIL PROTECTED]
wrote: Yeah, AttributeModifier is the right way to go. Especially in your case, because you probably want to do something like this: Your listview:
... protected abstract void populateItem(final ListItem item) { NewsItem newsItem = (NewsItem)item.getModelObject(); String id = (
newsItem.isCool()) ? newsEntryHot : newsEntryBoring; WebMarkupContainer outerDiv = new WebMarkupContainer(outer); outerDiv.add(new SimpleAttributeModifier(id, id));
item.add(outerDiv); ... // etc } Eelco On 2/12/06, Tom S.
[EMAIL PROTECTED] wrote: Hi all, I'm new to Wicket and so far I like it. :) I want to show a small news-list on a page and use a ListView for that. In
the html-page it looks like this: span wicket:id=news div id=newsEntryHot div id=newsDate
span wicket:id=date06-01-05/span /div div id=newsHeadlinespan wicket:id=headlineApp released/span
/divdiv id=newsContentspan wicket:id=messageBla bla/span/div
/div /span We have defined different looks for hot and normal news. Hot news should
have the outer div with id=newsEntryHot, normal ones with a different id. The information is locally available as a boolean property of the NewsEntry.
How do I change the id-parameter? I've found the AttributeModifier class, but have not clue, whether it is the right thing and/or how to use it, esp. the related model.
Thanks in advance, 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 theweb.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 theweb.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
[Wicket-user] Wicket goodie: Versioned form blog entry
Someone asked about how I did my optimistic locking form, so I took 15 minutes and wrote a short entry on my blog.http://www.jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form Martijn-- Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
Re: [Wicket-user] Wicket goodie: Versioned form blog entry
Great, thank you. 2006/2/13, Martijn Dashorst [EMAIL PROTECTED]: Someone asked about how I did my optimistic locking form, so I took 15 minutes and wrote a short entry on my blog. http://www.jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form Martijn-- Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
Re: [Wicket-user] Wicket goodie: Versioned form blog entry
nice but i do it already a little bid different.Because what we want is that person A alters field X and person B field Y then it may pass.(ok it can be that those 2 fields are related to each other but then a validator must handle that) The big trick we needed to fix was that a form input that is not changed by person A (but is submitted ofcourse) will not overwrite anything in the model object. So we now keep the string references of the rendered output and compare with that instead of with the real objects value to compare if the value is changed.johanOn 2/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote: Someone asked about how I did my optimistic locking form, so I took 15 minutes and wrote a short entry on my blog. http://www.jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form Martijn-- Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
Re: [Wicket-user] Graphics, css, html and classes
some ideasMake those resources also PackageResources so inside the src dir.Or set a hard path ../../../ in Index.html to style.css and logo.pngAnd then fix that path at runtime johan On 2/13/06, Tom S. [EMAIL PROTECTED] wrote: Hi,At the moment I have following project structure:[root]+ [resources]| + style.css| + graphic/logo.png+ [src] + [com.blabla.pages] + Index.java + Index.htmlIndex.html references style.css and graphic/logo.png relative to [resources](which is in the classpath) to ensure the resulting page can reach theseresources. But when editing the Index.html, they are not reachable, because they are not available relative to the current package.How do you manage such resources?--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 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] Graphics, css, html and classes
>From within style.css the references to images is always local to the style.So when I need to add a style.css to a wicket markup file, and I want previewability, I usually do something like this:wicket:remove style src="">/wicket:removestyle src=""> On 2/13/06, Johan Compagner [EMAIL PROTECTED] wrote: some ideasMake those resources also PackageResources so inside the src dir.Or set a hard path ../../../ in Index.html to style.css and logo.pngAnd then fix that path at runtime johan On 2/13/06, Tom S. [EMAIL PROTECTED] wrote: Hi,At the moment I have following project structure:[root]+ [resources]| + style.css| + graphic/logo.png+ [src] + [com.blabla.pages] + Index.java + Index.html Index.html references style.css and graphic/logo.png relative to [resources](which is in the classpath) to ensure the resulting page can reach theseresources. But when editing the Index.html, they are not reachable, because they are not available relative to the current package.How do you manage such resources?--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 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 -- Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
Re: [Wicket-user] Graphics, css, html and classes
OK, for styles, this works, but how to do that with images? What about moving the html-files to the resources directory? Maybe there is an easy way to tell Wicket where it should search for them. Cheers, Tom Martijn Dashorst schrieb: From within style.css the references to images is always local to the style. So when I need to add a style.css to a wicket markup file, and I want previewability, I usually do something like this: wicket:remove style src=../../../../../../../webapp/style/style.css/style /wicket:remove style src=style/style.css/style On 2/13/06, *Johan Compagner* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: some ideas Make those resources also PackageResources so inside the src dir. Or set a hard path ../../../ in Index.html to style.css and logo.png And then fix that path at runtime johan On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, At the moment I have following project structure: [root] + [resources] | + style.css | + graphic/logo.png + [src] + [com.blabla.pages] + Index.java + Index.html Index.html references style.css and graphic/logo.png relative to [resources] (which is in the classpath) to ensure the resulting page can reach these resources. But when editing the Index.html, they are not reachable, because they are not available relative to the current package. How do you manage such resources? -- 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 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 -- 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=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Graphics, css, html and classes
that is possible but then you have to writer youre own ResourceFinder or ResourceLocator.On 2/13/06, Thomas Singer [EMAIL PROTECTED] wrote:OK, for styles, this works, but how to do that with images? What about moving the html-files to the resources directory? Maybe there isan easy way to tell Wicket where it should search for them.Cheers,TomMartijn Dashorst schrieb:From within style.css the references to images is always local to the style. So when I need to add a style.css to a wicket markup file, and I want previewability, I usually do something like this: wicket:remove style src=""> /wicket:remove style src="" On 2/13/06, *Johan Compagner* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: some ideas Make those resources also PackageResources so inside the src dir. Or set a hard path ../../../ in Index.html to style.css and logo.png And then fix that path at runtime johan On 2/13/06, *Tom S.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, At the moment I have following project structure: [root] + [resources] | + style.css | + graphic/logo.png + [src]+ [com.blabla.pages]+ Index.java+ Index.html Index.html references style.css and graphic/logo.png relative to [resources] (which is in the classpath) to ensure the resulting page can reach these resources. But when editing the Index.html, they are not reachable, because they are not available relative to the current package. How do you manage such resources? -- 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 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 -- 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 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] URL redirect
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 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 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Autocompleting TextField
I saw that there is an autocompleting TextField in the scriptaculous examples at wicket-stuff. Is this the prefered way of doing it in 1.2? Or is it a behaviour one should use somehow? /Mats --- 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
[Wicket-user] ApplicationSettings.setSigninPage moved?
Hey all,Where abouts has ApplicationSettings.setSigninPage moved to/changed to? Just pulled out a new HEAD build and its no longer there, and no sign of it on any other class. http://papernapkin.org/pastebin/app/view/236 shows using IUnauthorizedComponentInstantiationListener which I havn't seen before, but also mentions setSigninPage on securitySettings (which it doesn't appear to exist, at least not on sourceforge's anonymous cvs HEAD). Cheers,Mark-- 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] URL redirect
you should put index.html in your context root and have a metaredirect to /foo insidesomething like this:htmlhead meta http-equiv=Refresh content=0; url="" /head/html-IgorOn 2/13/06, Tom S. [EMAIL PROTECTED] wrote: OK, I now can read my html files from a different location. But I still havea serious problem with resources ( e.g. graphics). The servlet mapping in theweb.xml looks like this: servlet-mapping servlet-nameMyWebApplication/servlet-name url-pattern/foo/*/url-pattern /servlet-mappingWhen I open the URL http://localhost:8080/foo/graphics/logo.png, the graphicis shown. In the Index.html (my home page), it is references as graphics/logo.png. Unfortunately it cannot be found when displaying thehome page with the URL http://localhost:8080/foo/, most likely because itredirects the request to http://localhost:8080/foo?path=0, which is adirectory change.Is there a possibility to redirect to http://localhost:8080/foo/index.html or something similar, so the relative paths work as expected?--Thanks in advance,TomPS: I'm not experienced with web applications, so please excuse these dumbquestions.--- 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] Autocompleting TextField
it is not part of the core, so preferred way does not apply to it. it is just an implementation. if you like it go ahead and use it.i dont know if we will be providing an implementation as part of the core. depends on how complex the _javascript_ needs to be to draw the drop down part and how cross browser it will be. -IgorOn 2/13/06, Mats Norén [EMAIL PROTECTED] wrote: I saw that there is an autocompleting TextField in the scriptaculousexamples atwicket-stuff. Is this the prefered way of doing it in1.2? Or is it a behaviour one should use somehow?/Mats--- 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
[Wicket-user] complex forms w/ dynamic name/id attributes
I understand simple wicket forms at least a little now...but I'm really starting to struggle w/ things beyond the trivial when it comes to forms. I'm also having some trouble locating some real solid examples or documentation...the API reference stops being helpful really quick. The wicket-examples aren't bad but aren't that great either...am I missing some documentation somewhere that might be helping 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 row in wicket using tr wicket:id= ... and the list is displayed on the page. Now I need to add a radio button list, textbox, and submit button for each item in the listwhich would submit the form that the entire table is wrapped in...how can this be done w/o generating an error? Obviously, the names aren't unique so an exception is thrown. Here's an example...a table w/ a dynamic row-set...w/ nested radio button list(s) table border=1 width=100% cellpadding=3 cellspacing=0 tr wicket:id=mydatalist span valign=top wicket:id=rclist id=statusrc td input type=radio / /td td input type=radio / /td td input 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 a certain 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 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] ApplicationSettings.setSigninPage moved?
yes it is removed and the replacement is: setUnauthorizedComponentInstantiationListener()see the library examplegetSecuritySettings().setUnauthorizedComponentInstantiationListener(new IUnauthorizedComponentInstantiationListener()
{ public void onUnauthorizedInstantiation(final Component component) {// If there is a sign in page class declared, and the unauthorized// component is a page, but it's not the sign in page
if (component instanceof Page){ // Redirect to intercept page to let the user sign in throw new RestartResponseAtInterceptPageException(
SignIn.class);}else{ // The component was not a page, so throw an exception throw new UnauthorizedInstantiationException(
component.getClass());} } }); // 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());
} };On 2/13/06, Mark Derricutt [EMAIL PROTECTED] wrote:
Hey all,Where abouts has ApplicationSettings.setSigninPage moved to/changed to? Just pulled out a new HEAD build and its no longer there, and no sign of it on any other class.
http://papernapkin.org/pastebin/app/view/236 shows using IUnauthorizedComponentInstantiationListener which I havn't seen before, but also mentions setSigninPage on securitySettings (which it doesn't appear to exist, at least not on sourceforge's anonymous cvs HEAD).
Cheers,Mark-- 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] Autocompleting TextField
I think such a component would be very implementation dependend, and the dojo/scriptaculous components are probably a better way to go. They have the backing power of useful javascript libraries and don't suffer from a not invented here syndrome. I think such a component would distract too much from our wicket core responsibilities: create a focused framework. IMO the current ajax implementation is already on the border: it provides needed functionality to be able to pull off some very interesting automagic partial page updates, but I don't want us going the scriptaculous/dojo way. Martijn On 2/13/06, Igor Vaynberg [EMAIL PROTECTED] wrote: it is not part of the core, so preferred way does not apply to it. it is just an implementation. if you like it go ahead and use it. i dont know if we will be providing an implementation as part of the core. depends on how complex the javascript needs to be to draw the drop down part and how cross browser it will be. -Igor On 2/13/06, Mats Norén [EMAIL PROTECTED] wrote: I saw that there is an autocompleting TextField in the scriptaculous examples at wicket-stuff. Is this the prefered way of doing it in 1.2? Or is it a behaviour one should use somehow? /Mats --- 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 -- 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] ApplicationSettings.setSigninPage moved?
hm... a little out of topic, but I am just getting confuse recentlyWhy a simple, common task like setSignInPage() becomes so complex ? I need to learn 4 class to accomplish :IUnauthorizedComponentInstantiationListener
RestartResponseAtInterceptPageExceptionUnauthorizedInstantiationExceptionSimplePageAuthorizationStrategyand the name of class and method are long and complex !Should'nt Wicket provide simplifed default implemention out of box ?
I am *afraid* upgrading to wicket 1.2On 2/14/06, Johan Compagner [EMAIL PROTECTED]
wrote:yes it is removed and the replacement is: setUnauthorizedComponentInstantiationListener()
see the library examplegetSecuritySettings().setUnauthorizedComponentInstantiationListener(new IUnauthorizedComponentInstantiationListener()
{ public void onUnauthorizedInstantiation(final Component component) {// If there is a sign in page class declared, and the unauthorized// component is a page, but it's not the sign in page
if (component instanceof Page){ // Redirect to intercept page to let the user sign in throw new RestartResponseAtInterceptPageException(
SignIn.class);}else{ // The component was not a page, so throw an exception throw new UnauthorizedInstantiationException(
component.getClass());} } }); // 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());
} };On 2/13/06, Mark Derricutt
[EMAIL PROTECTED] wrote:
Hey all,Where abouts has ApplicationSettings.setSigninPage moved to/changed to? Just pulled out a new HEAD build and its no longer there, and no sign of it on any other class.
http://papernapkin.org/pastebin/app/view/236 shows using IUnauthorizedComponentInstantiationListener which I havn't seen before, but also mentions setSigninPage on securitySettings (which it doesn't appear to exist, at least not on sourceforge's anonymous cvs HEAD).
Cheers,Mark-- 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
-- Ingram ChenJava [EMAIL PROTECTED]Institue of BioMedical Sciences Academia Sinica Taiwanblog:
http://www.javaworld.com.tw/roller/page/ingramchen
[Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
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
[Wicket-user] Post 1.2 roadmap
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=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
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 that version should be primarily just that change and some minor ones around it. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? Yes. If we call the constructor change Wicket 1.3, we can call the JDK 1.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 a year to do it. Not everyone will be happy with it, but we'll have a very decent version out with 1.3 which we should support for a long time (by which I mean bug fixing, not so much back porting new features). Moving to 1.5 will eleminate a few of the weak features we still have and 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 concepts yet - the model. With generics we can have this. I think that alone is worth 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 too early. 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 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
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=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
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] Post 1.2 roadmap
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
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?
- 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
--
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] Post 1.2 roadmap
Say what? Running out of things to work on? That's a joke, right? May
I remind you that we are doing this largely in our spare time, and
have been doing that for a long time already?
Eelco
On 2/13/06, Gili [EMAIL PROTECTED] wrote:
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
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?
- 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
--
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
---
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
We /will/ evaluate all bugs, issues and patches before we bring out
any final release. We can't make any guarantees on fixes and schedules
however.
On 2/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Say what? Running out of things to work on? That's a joke, right? May
I remind you that we are doing this largely in our spare time, and
have been doing that for a long time already?
Eelco
On 2/13/06, Gili [EMAIL PROTECTED] wrote:
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
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?
- 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
--
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
---
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
Re: [Wicket-user] Post 1.2 roadmap
may i humbly suggest you do not post off topic.-IgorOn 2/13/06, Gili [EMAIL PROTECTED]
wrote:Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?On a related note, I believe RFE #1167649 can be closed as fixed.Thanks,GiliMartijn 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?- should we make different releases for either change, and thus postponing 1.5 toWicket 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, whichenables 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 theweb.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--http://www.desktopbeautifier.com/---
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
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.
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
Re: [Wicket-user] Post 1.2 roadmap
Yes, you are correct, that is exactly what I meant. The pace of development seems to be quite nice. :)-- JessOn 2/14/06, Eelco Hillenius [EMAIL PROTECTED] wrote: I think you mean pace of releasing. The pace of development isactually very high, and is - unfortunately - the main reason why wedidn't bring out a release yet :)Eelco Based on the current pace of development, a 2.0 release would probably not land until late this year at the earliest, I would think.Does that make 1.5 sound a little better?---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] Post 1.2 roadmap
I am sorry,i forget the time for 2.0 release. ButI still have doubt aboutone year is enough. I never used Retrotranslator and other retroweaver tools.I am not sure it can run in different jdk with problems.So i avoid it. Stick with the old version is not bad, we seldom change the version for consistence.The last sentence is my fault.There is a wrong word "projects" insteadof "objects". I just want to way "retroweaver" is not a good choice,just a solution for urgency. - Original Message - From: Jesse Sightler To: wicket-user@lists.sourceforge.net Sent: Tuesday, February 14, 2006 1:17 PM Subject: Re: [Wicket-user] Post 1.2 roadmap On 2/13/06, wang lei [EMAIL PROTECTED] wrote: Here is my opinions: - should the post 1.2 version of Wicket involve both changes?Absolutely not.I s upport 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. Based on the current pace of development, a 2.0 release would probably not land until late this year at the earliest, I would think. Does that make 1.5 sound a little better?And 1.4 users would have two choices:Use the new version through Retrotranslator Stick with the old version until they can safely migrateI don't think either of those options is particularly bad. - 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. Of course, it would also gain users thanks to the nicer development environment. :) - 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.I'm not sure what you mean... just that you've never tried it? Or do you have some obje ction to this approach? Thanks,Jesshttp://www.jroller.com/page/jsight/__赶快注册雅虎超大容量免费邮箱?http://cn.mail.yahoo.com
Re: [Wicket-user] Post 1.2 roadmap
All,
I am for 1.5. I am in the happy situation where I have complete control
over deployment of my apps. Not everyone is. I would rather have it
sooner than later, but if it's best for the community as a whole, I am
glad to wait until after the Constructor refactoring. Just not too much
after. :-)
Should I find myself in the position of supporting jdk 1.5, I'd give
retroweaver a try. Whether I use it would depend on how well it works,
of course.
Thanks,
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?
- 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___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Philip A. Chapman
Application Development:
Java, Visual Basic (MCP), PostgreSQL, MySQL, MSSQL
Linux, Windows 9x, Windows NT, Windows 2000, Windows XP
signature.asc
Description: OpenPGP digital signature
