Re: rename classes and methods from *Javascript* to *JavaScript*
+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 http://issues.apache.org/jira/browse/WICKET-715? If we want to change it / make it consistent, we should change it anytime soon -Juergen
MarkupUtil.isMarkupHtml5Compliant() bug ?!
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 org.apache.wicket.markup.html.MarkupUtil$1.component(MarkupUtil.java:1) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:142) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:118) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:919) at org.apache.wicket.markup.html.MarkupUtil.isMarkupHtml5Compliant(MarkupUtil.java:52) at org.wicketstuff.html5.markup.html.form.NumberField.onInitialize(NumberField.java:38) at org.apache.wicket.Component.fireInitialize(Component.java:989) at org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992) at org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:972) at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:162) at org.wicketstuff.html5.markup.html.form.NumberFieldDemo.init(NumberFieldDemo.java:19) So I changed MarkupUtil line 56: MarkupResourceStream rs = comp.getAssociatedMarkup().getMarkupResourceStream(); with MarkupResourceStream rs = comp.getMarkup().getMarkupResourceStream(); and now there is no NPE but it returns null for doctype. The page HTML looks like: http://pastie.org/1359239 The code is at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jdk-1.6-parent/wicket-html5-parent see NumberFieldDemo in examples and NumberField in impl project. martin-g
MarkupUtil.isMarkupHtml5Compliant() bug ?!
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 org.apache.wicket.markup.html.MarkupUtil$1.component(MarkupUtil.java:1) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:142) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:118) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:919) at org.apache.wicket.markup.html.MarkupUtil.isMarkupHtml5Compliant(MarkupUtil.java:52) at org.wicketstuff.html5.markup.html.form.NumberField.onInitialize(NumberField.java:38) at org.apache.wicket.Component.fireInitialize(Component.java:989) at org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992) at org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:972) at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:162) at org.wicketstuff.html5.markup.html.form.NumberFieldDemo.init(NumberFieldDemo.java:19) So I changed MarkupUtil line 56: MarkupResourceStream rs = comp.getAssociatedMarkup().getMarkupResourceStream(); with MarkupResourceStream rs = comp.getMarkup().getMarkupResourceStream(); and now there is no NPE but it returns null for doctype. The page HTML looks like: http://pastie.org/1359239 The code is at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jdk-1.6-parent/wicket-html5-parent see NumberFieldDemo in examples and NumberField in impl project. martin-g
HTML 5 and Wicket: configuration from markup?
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 void onInitialize()
{
super.onInitialize();
setRequired(getMarkupAttributes().containsKey(required)));
setEnabled(getMarkupAttributes().containsKey(enabled)));
}
}
By doing this in onInitialize() we don't override anything done in
onConfigure, but we would negate anything set on the component prior
to it being added to the page. For example:
TextField tf = new TextField( ... );
tf.setRequired(false);
add(tf);
input type=text wicket:id= required
would ultimately result in a required field
Another thing is that if/when we allow this, the next thing folks want
is to make it conditional... and then we have Wicket JSPs...
So I'm not sure if it is a good idea to enable component configuration
from the markup.
Martijn
wicket 1.5
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?
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 do is the following:
public class TextField ... {
�...@override
protected void onInitialize()
{
super.onInitialize();
setRequired(getMarkupAttributes().containsKey(required)));
setEnabled(getMarkupAttributes().containsKey(enabled)));
}
}
By doing this in onInitialize() we don't override anything done in
onConfigure, but we would negate anything set on the component prior
to it being added to the page. For example:
TextField tf = new TextField( ... );
tf.setRequired(false);
add(tf);
input type=text wicket:id= required
would ultimately result in a required field
Another thing is that if/when we allow this, the next thing folks want
is to make it conditional... and then we have Wicket JSPs...
So I'm not sure if it is a good idea to enable component configuration
from the markup.
Martijn
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
automagically add this to all components for users. Or, make it a
markup setting on the application.
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: wicket 1.5
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 few of those first. Nobody here is going to give you dates, because they can't. Even if I commercially through weight behind 1.5, I couldn't force a release unless it was voted in, so it's impossible to give dates. But, that said, we're getting close to the first RC, which is a very promising sign. When the first RC is available, please migrate your applications to it. The more apps we get running on it, the better it is tested, and the quicker we can get 1.5.0. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: MarkupUtil.isMarkupHtml5Compliant() bug ?!
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? Juergen On Wed, Dec 8, 2010 at 5:27 PM, Martin Grigorov martin.grigo...@gmail.com wrote: 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 org.apache.wicket.markup.html.MarkupUtil$1.component(MarkupUtil.java:1) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:142) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:118) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:919) at org.apache.wicket.markup.html.MarkupUtil.isMarkupHtml5Compliant(MarkupUtil.java:52) at org.wicketstuff.html5.markup.html.form.NumberField.onInitialize(NumberField.java:38) at org.apache.wicket.Component.fireInitialize(Component.java:989) at org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992) at org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:972) at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:162) at org.wicketstuff.html5.markup.html.form.NumberFieldDemo.init(NumberFieldDemo.java:19) So I changed MarkupUtil line 56: MarkupResourceStream rs = comp.getAssociatedMarkup().getMarkupResourceStream(); with MarkupResourceStream rs = comp.getMarkup().getMarkupResourceStream(); and now there is no NPE but it returns null for doctype. The page HTML looks like: http://pastie.org/1359239 The code is at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jdk-1.6-parent/wicket-html5-parent see NumberFieldDemo in examples and NumberField in impl project. martin-g
Re: HTML 5 and Wicket: configuration from markup?
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 not parse them
into anything meaningful, except IIRC the markup id.
What we could do is the following:
public class TextField ... {
@Override
protected void onInitialize()
{
super.onInitialize();
setRequired(getMarkupAttributes().containsKey(required)));
setEnabled(getMarkupAttributes().containsKey(enabled)));
}
}
By doing this in onInitialize() we don't override anything done in
onConfigure, but we would negate anything set on the component prior
to it being added to the page. For example:
TextField tf = new TextField( ... );
tf.setRequired(false);
add(tf);
input type=text wicket:id= required
would ultimately result in a required field
Another thing is that if/when we allow this, the next thing folks want
is to make it conditional... and then we have Wicket JSPs...
So I'm not sure if it is a good idea to enable component configuration
from the markup.
Martijn
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
automagically add this to all components for users. Or, make it a
markup setting on the application.
instanctiationlistener will not work because the markup is not available
yet at construction time of FormComponent
I like the idea with markupsettings
using getFlag() to check those two (required and enabled) will not work too
because the method returns boolean, there is no unknown/unset state
And I *don't* like the idea of Wicket JSP thingie. We can use the markup to
facilitate the configuration (i.e. save some boilerplate in .java) but not
for any logic
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: MarkupUtil.isMarkupHtml5Compliant() bug ?!
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 wicketstuff's SVN repo (link below). On Wed, Dec 8, 2010 at 5:41 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: 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? Juergen On Wed, Dec 8, 2010 at 5:27 PM, Martin Grigorov martin.grigo...@gmail.com wrote: 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 org.apache.wicket.markup.html.MarkupUtil$1.component(MarkupUtil.java:1) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:142) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:118) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:919) at org.apache.wicket.markup.html.MarkupUtil.isMarkupHtml5Compliant(MarkupUtil.java:52) at org.wicketstuff.html5.markup.html.form.NumberField.onInitialize(NumberField.java:38) at org.apache.wicket.Component.fireInitialize(Component.java:989) at org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992) at org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:972) at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:162) at org.wicketstuff.html5.markup.html.form.NumberFieldDemo.init(NumberFieldDemo.java:19) So I changed MarkupUtil line 56: MarkupResourceStream rs = comp.getAssociatedMarkup().getMarkupResourceStream(); with MarkupResourceStream rs = comp.getMarkup().getMarkupResourceStream(); and now there is no NPE but it returns null for doctype. The page HTML looks like: http://pastie.org/1359239 The code is at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jdk-1.6-parent/wicket-html5-parent see NumberFieldDemo in examples and NumberField in impl project. martin-g
Re: HTML 5 and Wicket: configuration from markup?
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 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 void onInitialize()
{
super.onInitialize();
setRequired(getMarkupAttributes().containsKey(required)));
setEnabled(getMarkupAttributes().containsKey(enabled)));
}
}
By doing this in onInitialize() we don't override anything done in
onConfigure, but we would negate anything set on the component prior
to it being added to the page. For example:
TextField tf = new TextField( ... );
tf.setRequired(false);
add(tf);
input type=text wicket:id= required
would ultimately result in a required field
Another thing is that if/when we allow this, the next thing folks want
is to make it conditional... and then we have Wicket JSPs...
So I'm not sure if it is a good idea to enable component configuration
from the markup.
Martijn
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
automagically add this to all components for users. Or, make it a
markup setting on the application.
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: MarkupUtil.isMarkupHtml5Compliant() bug ?!
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 mgrigo...@apache.orgwrote: 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 wicketstuff's SVN repo (link below). On Wed, Dec 8, 2010 at 5:41 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: 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? Juergen On Wed, Dec 8, 2010 at 5:27 PM, Martin Grigorov martin.grigo...@gmail.com wrote: 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 org.apache.wicket.markup.html.MarkupUtil$1.component(MarkupUtil.java:1) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:142) at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:118) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:919) at org.apache.wicket.markup.html.MarkupUtil.isMarkupHtml5Compliant(MarkupUtil.java:52) at org.wicketstuff.html5.markup.html.form.NumberField.onInitialize(NumberField.java:38) at org.apache.wicket.Component.fireInitialize(Component.java:989) at org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992) at org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:972) at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:162) at org.wicketstuff.html5.markup.html.form.NumberFieldDemo.init(NumberFieldDemo.java:19) So I changed MarkupUtil line 56: MarkupResourceStream rs = comp.getAssociatedMarkup().getMarkupResourceStream(); with MarkupResourceStream rs = comp.getMarkup().getMarkupResourceStream(); and now there is no NPE but it returns null for doctype. The page HTML looks like: http://pastie.org/1359239 The code is at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jdk-1.6-parent/wicket-html5-parent see NumberFieldDemo in examples and NumberField in impl project. martin-g
Re: HTML 5 and Wicket: configuration from markup?
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
automagically add this to all components for users. Or, make it a
markup setting on the application.
instanctiationlistener will not work because the markup is not available
yet at construction time of FormComponent
I like the idea with markupsettings
I didn't say do the configuration in the instantiation listener. I
said automagically add this [AutoConfigureBehavior mentioned in
previous sentence] to all components.
Example:
class AutoConfigureBehavior extends AbstractBehavior {
@Override
public void onComponentTag(Component component, ComponentTag tag) {
super.onComponentTag(component, tag);
if (component instanceof FormComponent?
!Strings.isEmpty(tag.getAttribute(required))) {
((FormComponent) component).setRequired(true);
}
}
}
class AddAutoConfigureBehaviorToAllComponents implements
IComponentInstantiationListener {
@Override
public void onInstantiation(Component component) {
component.add(new AutoConfigureBehavior());
}
}
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: wicket 1.5
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 change (much)? Much appreciated. On Wed, Dec 8, 2010 at 11:39 AM, Jeremy Thomerson jer...@wickettraining.com wrote: 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 few of those first. Nobody here is going to give you dates, because they can't. Even if I commercially through weight behind 1.5, I couldn't force a release unless it was voted in, so it's impossible to give dates. But, that said, we're getting close to the first RC, which is a very promising sign. When the first RC is available, please migrate your applications to it. The more apps we get running on it, the better it is tested, and the quicker we can get 1.5.0. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: wicket 1.5
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: 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 change (much)? Much appreciated. On Wed, Dec 8, 2010 at 11:39 AM, Jeremy Thomerson jer...@wickettraining.com wrote: 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 few of those first. Nobody here is going to give you dates, because they can't. Even if I commercially through weight behind 1.5, I couldn't force a release unless it was voted in, so it's impossible to give dates. But, that said, we're getting close to the first RC, which is a very promising sign. When the first RC is available, please migrate your applications to it. The more apps we get running on it, the better it is tested, and the quicker we can get 1.5.0. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: wicket 1.5
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 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: 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 change (much)? Much appreciated. On Wed, Dec 8, 2010 at 11:39 AM, Jeremy Thomerson jer...@wickettraining.com wrote: 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 few of those first. Nobody here is going to give you dates, because they can't. Even if I commercially through weight behind 1.5, I couldn't force a release unless it was voted in, so it's impossible to give dates. But, that said, we're getting close to the first RC, which is a very promising sign. When the first RC is available, please migrate your applications to it. The more apps we get running on it, the better it is tested, and the quicker we can get 1.5.0. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: wicket 1.5
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 course, we may discover something that requires it, but we try hard not to. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: wicket 1.5
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 going to change (much)? Once we get to a release candidate, we make every effort to not change APIs. Of course, we may discover something that requires it, but we try hard not to. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
