Re: rename classes and methods from *Javascript* to *JavaScript*

2010-12-08 Thread Johan Compagner
+1 On Tue, Dec 7, 2010 at 20:55, Igor Vaynberg igor.vaynb...@gmail.com wrote: +1 to make it consistent, dont care which way its spelled. -igor On Tue, Dec 7, 2010 at 9:51 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: what shall we do with

MarkupUtil.isMarkupHtml5Compliant() bug ?!

2010-12-08 Thread Martin Grigorov
Hi Juergen, I just tried to use MarkupUtil.isMarkupHtml5Compliant() for the new HTML5 input types and it failed with: Caused by: java.lang.NullPointerException at org.apache.wicket.markup.html.MarkupUtil$1.component(MarkupUtil.java:56) at

MarkupUtil.isMarkupHtml5Compliant() bug ?!

2010-12-08 Thread Martin Grigorov
Hi Juergen, I just tried to use MarkupUtil.isMarkupHtml5Compliant() for the new HTML5 input types and it failed with: Caused by: java.lang.NullPointerException at org.apache.wicket.markup.html.MarkupUtil$1.component(MarkupUtil.java:56) at

HTML 5 and Wicket: configuration from markup?

2010-12-08 Thread Martijn Dashorst
In HTML 5 it is possible to use attributes like required, autocomplete etc. Currently Wicket ignores such attributes and does not parse them into anything meaningful, except IIRC the markup id. What we could do is the following: public class TextField ... { @Override protected

wicket 1.5

2010-12-08 Thread Cristi Manole
Hello, When do you guys plan to go live with wicket 1.5 final? Or when is it safe to expect it? Thank you, Cristi Manole

Re: HTML 5 and Wicket: configuration from markup?

2010-12-08 Thread Jeremy Thomerson
On Wed, Dec 8, 2010 at 10:28 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: In HTML 5 it is possible to use attributes like required, autocomplete etc. Currently Wicket ignores such attributes and does not parse them into anything meaningful, except IIRC the markup id. What we could

Re: wicket 1.5

2010-12-08 Thread Jeremy Thomerson
On Wed, Dec 8, 2010 at 10:32 AM, Cristi Manole cristiman...@gmail.com wrote: Hello, When do you guys plan to go live with wicket 1.5 final? Or when is it safe to expect it? Thank you, Cristi Manole Well, we're likely close to a release candidate release. History shows that we'll have a

Re: MarkupUtil.isMarkupHtml5Compliant() bug ?!

2010-12-08 Thread Juergen Donnerstag
Interesting. I thought I had a testcase with exactly that DOCTYPE. In any case it returns the DOCTYPE of the page only, irrespective of Panel or Border etc. getMarkup() returning null means no markup found which would explain the NPE as well. You are sure about your source code and markup?

Re: HTML 5 and Wicket: configuration from markup?

2010-12-08 Thread Martin Grigorov
On Wed, Dec 8, 2010 at 5:37 PM, Jeremy Thomerson jer...@wickettraining.comwrote: On Wed, Dec 8, 2010 at 10:28 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: In HTML 5 it is possible to use attributes like required, autocomplete etc. Currently Wicket ignores such attributes and does

Re: MarkupUtil.isMarkupHtml5Compliant() bug ?!

2010-12-08 Thread Martin Grigorov
The NPE happens with #getAssociatedMarkup() and at this point the MarkupContainer is a Form Replacing it with #getMarkup() returned the page's markup, i.e. all html, and its markupstream had 'null' doctype. I'll investigate further but you can also take a look at the application. It is in

Re: HTML 5 and Wicket: configuration from markup?

2010-12-08 Thread Igor Vaynberg
it cannot be a setting on application level because it would break component libraries. -igor On Wed, Dec 8, 2010 at 6:37 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Wed, Dec 8, 2010 at 10:28 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: In HTML 5 it is possible to use

Re: MarkupUtil.isMarkupHtml5Compliant() bug ?!

2010-12-08 Thread Martin Grigorov
Correction, my bad. The Form's getMarkup() returns just : form wicket:id=form input wicket:id=number type=number min=3.0 max=10.0 onchange=console.log(this.value)/br/ input type=submit value=Submit/ /form so there is no doctype. On Wed, Dec 8, 2010 at 5:48 PM, Martin Grigorov

Re: HTML 5 and Wicket: configuration from markup?

2010-12-08 Thread Jeremy Thomerson
On Wed, Dec 8, 2010 at 10:44 AM, Martin Grigorov mgrigo...@apache.org wrote: Could we create an Html5AutoConfigurationBehavior that could be added to components if people wanted to auto-configure their components from markup?  We might even provide an icomponentinstantiationlistener to

Re: wicket 1.5

2010-12-08 Thread Cristi Manole
Thank you, Jeremy. I am planning to start migrating from 1.3 to 1.5 as soon as possible. It's a very big application so it's going to take at least a couple of months anyway. I am not as worried about defects as I am about API changes. Would you say it's a safe assumption that's not going to

Re: wicket 1.5

2010-12-08 Thread Martijn Dashorst
the biggest change between 1.3 and 1.5 is AFAIK the generification of IModel in 1.4. You could start your migration towards 1.4 first and tackle that. The inner workings of 1.4 and 1.3 are not too different. Martijn On Wed, Dec 8, 2010 at 6:18 PM, Cristi Manole cristiman...@gmail.com wrote:

Re: wicket 1.5

2010-12-08 Thread Cristi Manole
I am aware of the changes from 1.3 to 1.4. There are apps we've done that use 1.4. But what I meant was between 1.5M3 and 1.5 Final. Are you planning (big) API changes for 1.5? On Wed, Dec 8, 2010 at 12:24 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: the biggest change between 1.3

Re: wicket 1.5

2010-12-08 Thread Jeremy Thomerson
On Wed, Dec 8, 2010 at 11:18 AM, Cristi Manole cristiman...@gmail.com wrote: I am not as worried about defects as I am about API changes. Would you say it's a safe assumption that's not going to change (much)? Once we get to a release candidate, we make every effort to not change APIs. Of

Re: wicket 1.5

2010-12-08 Thread Cristi Manole
cool, tks a lot! On Wed, Dec 8, 2010 at 12:31 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Wed, Dec 8, 2010 at 11:18 AM, Cristi Manole cristiman...@gmail.com wrote: I am not as worried about defects as I am about API changes. Would you say it's a safe assumption that's not