Re: generics in Wicket
What happened to the otherwise we break the API too much? I remember putting up a vote for a model backport, but that time you did a -1 :-P Martijn On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: But if we backport the model changes then that is done inside the model and that is much much cleaner (i am +1 for backporting that to 1.3) +1 too. Especially considering the case you just described: ugly! :) Eelco -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
WICKET-365 - Go from setVisible(false) to setVisible(true) on a component in ajax does not work
I think it will be easier to speek about this in the mailing list ;) . I agree with the last comment : then why not simply adding the style=display:none attribute to the component tag, instead of creating an additional span ? but without its innnerHtml, only the componentTag. I think it should work in all case. -- Vincent Demay http://.demay-fr.net/blog/
RE: generics in Wicket
I am completely against degenerifying components. We have build a high abstraction framework with typed components that are reused in several other components and the generics help us to ensure to use the the use of the right component at the right place. Besides some minor problems with suns generic implementation I think that generic are the most usefull thing for us in Java 5. Type checking at development time hels to speed up development a lot. things like Integer i = (Integer)integerTextField.getModelObject(); always leads to problems at runtime whent the customer suddenly needs a Dobule field insteda of an Integer field. And over and above this would be another API break. Stefan Lindner
Re: WICKET-365 - Go from setVisible(false) to setVisible(true) on a component in ajax does not work
Martijn Dashorst a écrit : I don't agree. style=display:none is not the same as not rendering it at all The text and markup is still available, it could have stuff that is sensitive in it. setVisible (false) should always remove the whole markup for the component from the stream. No, I think I wasn't very clear in what I said ;) . Generating an empty span is not very good because it could invalidate the xhtml, so just replacing the empty span tag with an *empty* component tag (div if it was a div, td if it was a td etc...) and display:none on it in order to not invalidate Xhtml could be fine imo. Ajax should work the same as normal requests. Otherwise what is the fricking point of having a AjaxFallbackLink? Yes it is a drag to add containers around your stuff that you want to hide. but it makes it explicit and predictable. Martijn On 3/7/07, Vincent Demay [EMAIL PROTECTED] wrote: I think it will be easier to speek about this in the mailing list ;) . I agree with the last comment : then why not simply adding the style=display:none attribute to the component tag, instead of creating an additional span ? but without its innnerHtml, only the componentTag. I think it should work in all case. -- Vincent Demay http://.demay-fr.net/blog/
Re: WICKET-365 - Go from setVisible(false) to setVisible(true) on a component in ajax does not work
well, from a user point of view, the fact that you can't make a component visible using Ajax by simply doing: component.setVisible(true) target.addComponent(component) is perceived as a bug. And I can't believe you guys won't find something smarter for Wicket than using a surrounding container ;) For example, instead of using an HTML tag, what about using a Wicket specific one, like wicket:component id=myInvisibleComponent/ ? Fred Martijn Dashorst wrote: I don't agree. style=display:none is not the same as not rendering it at all The text and markup is still available, it could have stuff that is sensitive in it. setVisible (false) should always remove the whole markup for the component from the stream. Ajax should work the same as normal requests. Otherwise what is the fricking point of having a AjaxFallbackLink? Yes it is a drag to add containers around your stuff that you want to hide. but it makes it explicit and predictable. Martijn On 3/7/07, Vincent Demay [EMAIL PROTECTED] wrote: I think it will be easier to speek about this in the mailing list ;) . I agree with the last comment : then why not simply adding the style=display:none attribute to the component tag, instead of creating an additional span ? but without its innnerHtml, only the componentTag. I think it should work in all case. -- Vincent Demay http://.demay-fr.net/blog/
RE: generics in Wicket
don't worry. i believe that reason will prevail. i too am against a /complete/ degenerification, as are all the core developers. we just want to lighten it up some without losing much. in the case of typed textfields, there might be a workaround that doesn't force Component to be parameterized. for example, maybe just TextFieldT is enough. or maybe a typesafe accessor can provide what you want in an IntegerTextField subclass. in any case, i think exactly how and where to degenerify things for whatever comes after 1.3 needs to be discussed at length and there should be plenty of time to talk reasonably. can you provide more details of generics benefits you don't want to lose? Stefan Lindner wrote: I am completely against degenerifying components. We have build a high abstraction framework with typed components that are reused in several other components and the generics help us to ensure to use the the use of the right component at the right place. Besides some minor problems with suns generic implementation I think that generic are the most usefull thing for us in Java 5. Type checking at development time hels to speed up development a lot. things like Integer i = (Integer)integerTextField.getModelObject(); always leads to problems at runtime whent the customer suddenly needs a Dobule field insteda of an Integer field. And over and above this would be another API break. Stefan Lindner -- View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9354095 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Performance problems due to Component:initModel()
We are having serious performance problems (delays of various seconds) due to
the lookup process in Component:initModel() that tries to find a wrapModel
looking for an parent with an IInheritableModel.
The problem is the following: if a component has no model defined,
initModel() looks for a parent that has an IInheritableModel. Since it has
to consult the model of that parent, it calls getModel(). If the parent
itself has no model (it's just a container that has a layout function),
within getModel() there is a new call to initModel(), this time to look for
a model for that parent.
This is a simple simulation of what happens in Component: If I have a
component graph, in which a component is contained in 4 containers of which
3 have no model, I end up calling 8 times the initModel() method of the
topmost container without model.
public class Component {
private String id;
private Component parent = null;
private Object model = null;
private int initCount = 0;
public Component(Component parent,String id,Object model) {
this.parent = parent;
this.id = id;
this.model = model;
if (model == null)
initModel();
}
public Object getModel() {
if (model == null)
initModel();
return(model);
}
public void initModel() {
initCount++;
for (Component parent = this.parent; parent != null; parent =
parent.parent) {
parent.getModel();
}
}
@Override
public String toString() {
return(id: +id+ initCount: +initCount);
}
public static void main(String[] args) {
Component a = new Component(null,a,a);
Component b = new Component(a,b,null);
Component c = new Component(b,c,null);
Component d = new Component(c,d,null);
Component e = new Component(d,e,null);
System.out.println(b);
System.out.println(c);
System.out.println(d);
System.out.println(e);
}
}
In a real usecase, the component graph ends up being a lot larger than this
simple example, and the effect of calling initModel() can end up causing a
response delay of 10's of seconds.
We can solve the problem by overwriting the initModel() method in containers
that shouldn't have a model, or give them a mock model.
But I think there is a conceptual error in the component implementation: I
think initModel() should not be called from the method getModel(). Once
decided that there is no model for a component, it should not try and get
one each time we want to get it. I.e., initModel should be called only once
for each component. Am I right ?
Jan.
--
View this message in context:
http://www.nabble.com/Performance-problems-due-to-Component%3AinitModel%28%29-tf3362476.html#a9354170
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: WICKET-365 - Go from setVisible(false) to setVisible(true) on a component in ajax does not work
now here is an idea we can try. something like wicket:placeholder. -igor On 3/7/07, Frédéric Bertin [EMAIL PROTECTED] wrote: well, from a user point of view, the fact that you can't make a component visible using Ajax by simply doing: component.setVisible(true) target.addComponent(component) is perceived as a bug. And I can't believe you guys won't find something smarter for Wicket than using a surrounding container ;) For example, instead of using an HTML tag, what about using a Wicket specific one, like wicket:component id=myInvisibleComponent/ ? Fred Martijn Dashorst wrote: I don't agree. style=display:none is not the same as not rendering it at all The text and markup is still available, it could have stuff that is sensitive in it. setVisible (false) should always remove the whole markup for the component from the stream. Ajax should work the same as normal requests. Otherwise what is the fricking point of having a AjaxFallbackLink? Yes it is a drag to add containers around your stuff that you want to hide. but it makes it explicit and predictable. Martijn On 3/7/07, Vincent Demay [EMAIL PROTECTED] wrote: I think it will be easier to speek about this in the mailing list ;) . I agree with the last comment : then why not simply adding the style=display:none attribute to the component tag, instead of creating an additional span ? but without its innnerHtml, only the componentTag. I think it should work in all case. -- Vincent Demay http://.demay-fr.net/blog/
Re: generics in Wicket
It's good to see someone being happy with it and using it for
something real. I'm afraid my initial message was FUD anyway, as
looking into it a little bit closer, it doesn't seem like we have a
lot of choice. Seems to be either all or nothing. And as we can always
tell the compiler to ignore this stuff, I guess 'all' is the best
here.
Eelco
On 3/7/07, Stefan Lindner [EMAIL PROTECTED] wrote:
Maybe I am too accustomed to generics now but I can't imagine how a non-generic
Component class definition with a generic Model parameter can look like.
Now Compinent is defined as
class ComponentT ... {
public Component(final MarkupContainer? parent, final String id, final
IModelT model) {
...
}
public final T getModelObject() {
...
}
How should a non generic class definition look like? And pepole that don't like
or need generics can still use the raw types.
My preference for a strong gneric API comes from the experience I made when I
moved from Wicket 1.2 to 2.0. The simple syntactic modifications for generic
Components showed up several programming errors that we otherwise had to debug
during runtime of the application. It also showed up some design problems of
our applicatioin. So a strong generic API may took a little bit more time in
developing an application but it saves much more time in debugging.
Stefan Lindner
Re: generics in Wicket
you guys arent talking about putting it into 1.3 are you? can we please finish with 1.3 already! We agreed that as long as 1.3 is in beta we could implement changes that break the API. So we can make a release and still do that change. Or do it in 1.4 if you like, but I don't want to even start on 1.4 if we decide to keep 2.0 alive. Eelco
Re: WICKET-365 - Go from setVisible(false) to setVisible(true) on a component in ajax does not work
well i guess someone will have to write up a patch and make sure it works in all the browsers :) -igor On 3/7/07, Martijn Dashorst [EMAIL PROTECTED] wrote: I seriously doubt it will work in browsers. Not choking on wicket: tags and attributes is one thing, having them available in the dom and working is a completely other beast. Martijn On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: now here is an idea we can try. something like wicket:placeholder. -igor On 3/7/07, Frédéric Bertin [EMAIL PROTECTED] wrote: well, from a user point of view, the fact that you can't make a component visible using Ajax by simply doing: component.setVisible(true) target.addComponent(component) is perceived as a bug. And I can't believe you guys won't find something smarter for Wicket than using a surrounding container ;) For example, instead of using an HTML tag, what about using a Wicket specific one, like wicket:component id=myInvisibleComponent/ ? Fred Martijn Dashorst wrote: I don't agree. style=display:none is not the same as not rendering it at all The text and markup is still available, it could have stuff that is sensitive in it. setVisible (false) should always remove the whole markup for the component from the stream. Ajax should work the same as normal requests. Otherwise what is the fricking point of having a AjaxFallbackLink? Yes it is a drag to add containers around your stuff that you want to hide. but it makes it explicit and predictable. Martijn On 3/7/07, Vincent Demay [EMAIL PROTECTED] wrote: I think it will be easier to speek about this in the mailing list ;) . I agree with the last comment : then why not simply adding the style=display:none attribute to the component tag, instead of creating an additional span ? but without its innnerHtml, only the componentTag. I think it should work in all case. -- Vincent Demay http://.demay-fr.net/blog/ -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: generics in Wicket
thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. finish 1.3, then add this refactor to 1.4 lets release the damn thing already! -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: you guys arent talking about putting it into 1.3 are you? can we please finish with 1.3 already! We agreed that as long as 1.3 is in beta we could implement changes that break the API. So we can make a release and still do that change. Or do it in 1.4 if you like, but I don't want to even start on 1.4 if we decide to keep 2.0 alive. Eelco
RE: generics in Wicket
the imodel wouldn't be generic in component. only in subclasses. i
actually mildly prefer total generification too, but a lot of people have
expressed annoyance at generic code bulk so i've been listening to that.
basically, getModelObject would return Object below, but ListViewT would
return T. or that was the idea... i'm not sure if it's good. i just wanted
us to discuss it to see what's there.
Stefan Lindner wrote:
Maybe I am too accustomed to generics now but I can't imagine how a
non-generic Component class definition with a generic Model parameter can
look like.
Now Compinent is defined as
class ComponentT ... {
public Component(final MarkupContainer? parent, final String
id, final IModelT model) {
...
}
public final T getModelObject() {
...
}
How should a non generic class definition look like? And pepole that don't
like or need generics can still use the raw types.
My preference for a strong gneric API comes from the experience I made
when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications
for generic Components showed up several programming errors that we
otherwise had to debug during runtime of the application. It also showed
up some design problems of our applicatioin. So a strong generic API may
took a little bit more time in developing an application but it saves much
more time in debugging.
Stefan Lindner
--
View this message in context:
http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9356570
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: generics in Wicket
no that is not the case We don't wait for features or wait because we add stuff! We wait for the apache things that we have to do. So dropping in new features until that is resolved is not really a problem and those features are already tested by everybody that uses 2.0 So also backporting those is not a problem for me. I can patch it the coming days. if ofcourse others also want it. johan On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. finish 1.3, then add this refactor to 1.4 lets release the damn thing already! -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: you guys arent talking about putting it into 1.3 are you? can we please finish with 1.3 already! We agreed that as long as 1.3 is in beta we could implement changes that break the API. So we can make a release and still do that change. Or do it in 1.4 if you like, but I don't want to even start on 1.4 if we decide to keep 2.0 alive. Eelco
Re: generics in Wicket
But what is the problem then?
You do want the textfield?
But the component isn't really in your way and does give you
getModelObject()
i don't see the point of deleting it from Component but keeping it for
pretty much everything else
johan
On 3/7/07, Jonathan Locke [EMAIL PROTECTED] wrote:
the imodel wouldn't be generic in component. only in subclasses. i
actually mildly prefer total generification too, but a lot of people have
expressed annoyance at generic code bulk so i've been listening to that.
basically, getModelObject would return Object below, but ListViewT would
return T. or that was the idea... i'm not sure if it's good. i just
wanted
us to discuss it to see what's there.
Stefan Lindner wrote:
Maybe I am too accustomed to generics now but I can't imagine how a
non-generic Component class definition with a generic Model parameter
can
look like.
Now Compinent is defined as
class ComponentT ... {
public Component(final MarkupContainer? parent, final String
id, final IModelT model) {
...
}
public final T getModelObject() {
...
}
How should a non generic class definition look like? And pepole that
don't
like or need generics can still use the raw types.
My preference for a strong gneric API comes from the experience I made
when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications
for generic Components showed up several programming errors that we
otherwise had to debug during runtime of the application. It also showed
up some design problems of our applicatioin. So a strong generic API may
took a little bit more time in developing an application but it saves
much
more time in debugging.
Stefan Lindner
--
View this message in context:
http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9356570
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: generics in Wicket
thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. What are you talking about? 1.3's release wasn't/ isn't postponed a single day because of us adding new features. The opposite is true: new features (like the converter change) are added because the release isn't out yet and it's still ok to add (or backport) features. No, there is no 1.3 release yet for two (and only two) reasons: 1) legal issues due to incubating 2) setting up the new release process and being short in time for some members who are working on that Eelco
Re: generics in Wicket
no that is not the case We don't wait for features or wait because we add stuff! We wait for the apache things that we have to do. So dropping in new features until that is resolved is not really a problem and those features are already tested by everybody that uses 2.0 So also backporting those is not a problem for me. I can patch it the coming days. if ofcourse others also want it. Johan++ :) Eelco
Re: Performance problems due to Component:initModel()
But I think there is a conceptual error in the component implementation: I think initModel() should not be called from the method getModel(). Once decided that there is no model for a component, it should not try and get one each time we want to get it. I.e., initModel should be called only once for each component. Am I right ? Theoretically, people can manually set model to null after the component had it's own model first. But that would be quite weird. Eelco
Re: generics in Wicket
oh please. the more stuff you add the more we have to test, the longer it takes. johan is talking about backporting the models and thats great, but he still hasnt fixed the serialization issues in the pagestore. we needed a feature freeze a long time ago, so that we _would_ concentrate on getting the legal issues resolved, but instead weve been happily hacking away. we should at least try to work on some bugs before adding new stuff in. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. What are you talking about? 1.3's release wasn't/ isn't postponed a single day because of us adding new features. The opposite is true: new features (like the converter change) are added because the release isn't out yet and it's still ok to add (or backport) features. No, there is no 1.3 release yet for two (and only two) reasons: 1) legal issues due to incubating 2) setting up the new release process and being short in time for some members who are working on that Eelco
Re: generics in Wicket
We have a team of over ten people, so I don't see why backporting features can't be done, especially as some are without a doubt worth it. Take the converter backport. We made at least two users happy already! And it makes no difference AT ALL to the speed at which the release comes. The release isn't bound to testing anyway, as the first goal of the upcoming release is to have a dry run for an Apache ok-ed release. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: oh please. the more stuff you add the more we have to test, the longer it takes. johan is talking about backporting the models and thats great, but he still hasnt fixed the serialization issues in the pagestore. we needed a feature freeze a long time ago, so that we _would_ concentrate on getting the legal issues resolved, but instead weve been happily hacking away. we should at least try to work on some bugs before adding new stuff in. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. What are you talking about? 1.3's release wasn't/ isn't postponed a single day because of us adding new features. The opposite is true: new features (like the converter change) are added because the release isn't out yet and it's still ok to add (or backport) features. No, there is no 1.3 release yet for two (and only two) reasons: 1) legal issues due to incubating 2) setting up the new release process and being short in time for some members who are working on that Eelco
Re: generics in Wicket
yes, but i figured johan was going to keep working on it instead of backporting new features :) -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: and how many users did you make unhappy with the half working pagestore? maybe that shouldve been fixed before more energy was spent on backporting the converters. Didn't you +1 on setting that as the default, something I proposed /not/ doing? Eelco
Re: generics in Wicket
It was my rather limited energy that did the converter backport. Thus Johan can't use this effort as an excuse, that the pagestore isn't working already ;). Sven Igor Vaynberg wrote: and how many users did you make unhappy with the half working pagestore? maybe that shouldve been fixed before more energy was spent on backporting the converters. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: We have a team of over ten people, so I don't see why backporting features can't be done, especially as some are without a doubt worth it. Take the converter backport. We made at least two users happy already! And it makes no difference AT ALL to the speed at which the release comes. The release isn't bound to testing anyway, as the first goal of the upcoming release is to have a dry run for an Apache ok-ed release. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: oh please. the more stuff you add the more we have to test, the longer it takes. johan is talking about backporting the models and thats great, but he still hasnt fixed the serialization issues in the pagestore. we needed a feature freeze a long time ago, so that we _would_ concentrate on getting the legal issues resolved, but instead weve been happily hacking away. we should at least try to work on some bugs before adding new stuff in. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. What are you talking about? 1.3's release wasn't/ isn't postponed a single day because of us adding new features. The opposite is true: new features (like the converter change) are added because the release isn't out yet and it's still ok to add (or backport) features. No, there is no 1.3 release yet for two (and only two) reasons: 1) legal issues due to incubating 2) setting up the new release process and being short in time for some members who are working on that Eelco
Re: generics in Wicket
On 3/7/07, Sven Meier [EMAIL PROTECTED] wrote: It was my rather limited energy that did the converter backport. Ah. Thanks though! Thus Johan can't use this effort as an excuse, that the pagestore isn't working already ;). Nope he can't. Get on it Johan! :) Eelco
RE: generics in Wicket
Stefan Lindner wrote: My preference for a strong gneric API comes from the experience I made when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications for generic Components showed up several programming errors that we otherwise had to debug during runtime of the application. It also showed up some design problems of our applicatioin. So a strong generic API may took a little bit more time in developing an application but it saves much more time in debugging. I agree with this. We had the same experience, moving from 1.x to 2.0. Applying generics to complex component/model interactions can be hard (f.i. models working with collections, wrapmodels that define a different object than the nested model,...), but it clearly identifies where the design is not correct. We are in favor of maintaining generics. Jan. -- View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9360723 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] Performance problems due to Component:initModel()
Yes, you might want to cover up for that. But the price to pay is really high. I don't know if any other wicket 2.0 users have experience with no-nonsense applications, but in our case, the response times are really unacceptable (sometimes more than 10 seconds). By overwriting the initModel() method on just a few of the containers that have no own model, we reduce that time to less than a second. But I think a framework like Wicket can not leave that up to the user of the framework. Jan. Eelco Hillenius wrote: But I think there is a conceptual error in the component implementation: I think initModel() should not be called from the method getModel(). Once decided that there is no model for a component, it should not try and get one each time we want to get it. I.e., initModel should be called only once for each component. Am I right ? Theoretically, people can manually set model to null after the component had it's own model first. But that would be quite weird. Eelco -- View this message in context: http://www.nabble.com/Performance-problems-due-to-Component%3AinitModel%28%29-tf3362476.html#a9360881 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] Performance problems due to Component:initModel()
Even if you want to control that, it could be done within the setModel() method. After all, that's exactly what is done for wrapOnAssignment. Why not apply the same logic to wrapOnInheritance ? Jan Eelco Hillenius wrote: Theoretically, people can manually set model to null after the component had it's own model first. But that would be quite weird. Eelco -- View this message in context: http://www.nabble.com/Performance-problems-due-to-Component%3AinitModel%28%29-tf3362476.html#a9360990 Sent from the Wicket - Dev mailing list archive at Nabble.com.
VOTE: backporting wicket 2.0 model change to 1.3
In 2.0 we have a model change: IModel.getObject(Component) - IModel.getObject() IModel.setObject(Component,Object) - IModel.setObject(Object) So if you want to object from a component in 2.0 you only have to do: component.getModel().getObject() instead of component.getModel().getObject() That XXX is depending on what kind of model you use. If the component did inherit a CompoundModel then you have to specify the component.this If you where owner of the compoundmodel then you shouldn't specify anything (null) This is all fixed in 2.0 and now we can backport it to 1.3: 1 port it to 1.3 2 don't port it to 1.3
Re: VOTE: backporting wicket 2.0 model change to 1.3
This is all fixed in 2.0 and now we can backport it to 1.3: 1 port it to 1.3 2 don't port it to 1.3 Can we make a release (beta) of 1.3 this weekend? If we can, I am +1 for porting it to 1.3 right after that. That'll give users some room for breath, while we can keep on moving fast to try to get to the Wicket 2.0 feature set fast (only the converters would have to be backported if I understand correctly). Eelco
Re: VOTE: backporting wicket 2.0 model change to 1.3
1 port it to 1.3 -Matej Johan Compagner wrote: In 2.0 we have a model change: IModel.getObject(Component) - IModel.getObject() IModel.setObject(Component,Object) - IModel.setObject(Object) So if you want to object from a component in 2.0 you only have to do: component.getModel().getObject() instead of component.getModel().getObject() That XXX is depending on what kind of model you use. If the component did inherit a CompoundModel then you have to specify the component.this If you where owner of the compoundmodel then you shouldn't specify anything (null) This is all fixed in 2.0 and now we can backport it to 1.3: 1 port it to 1.3 2 don't port it to 1.3
Re: [Vote] Performance problems due to Component:initModel()
i dont get it, how many method invocations happen that they take 10 seconds? -igor On 3/7/07, Jan Vermeulen [EMAIL PROTECTED] wrote: Even if you want to control that, it could be done within the setModel() method. After all, that's exactly what is done for wrapOnAssignment. Why not apply the same logic to wrapOnInheritance ? Jan Eelco Hillenius wrote: Theoretically, people can manually set model to null after the component had it's own model first. But that would be quite weird. Eelco -- View this message in context: http://www.nabble.com/Performance-problems-due-to-Component%3AinitModel%28%29-tf3362476.html#a9360990 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: VOTE: backporting wicket 2.0 model change to 1.3
1 port it to 1.3 On 3/7/07, Johan Compagner [EMAIL PROTECTED] wrote: In 2.0 we have a model change: IModel.getObject(Component) - IModel.getObject() IModel.setObject(Component,Object) - IModel.setObject(Object) So if you want to object from a component in 2.0 you only have to do: component.getModel().getObject() instead of component.getModel().getObject() That XXX is depending on what kind of model you use. If the component did inherit a CompoundModel then you have to specify the component.this If you where owner of the compoundmodel then you shouldn't specify anything (null) This is all fixed in 2.0 and now we can backport it to 1.3: 1 port it to 1.3 2 don't port it to 1.3
Re: VOTE: backporting wicket 2.0 model change to 1.3
But then it will still land in 1.3? And also when are we going to release 1.3? Will we release that under the incubating tag? johan On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: This is all fixed in 2.0 and now we can backport it to 1.3: 1 port it to 1.3 2 don't port it to 1.3 Can we make a release (beta) of 1.3 this weekend? If we can, I am +1 for porting it to 1.3 right after that. That'll give users some room for breath, while we can keep on moving fast to try to get to the Wicket 2.0 feature set fast (only the converters would have to be backported if I understand correctly). Eelco
Re: VOTE: backporting wicket 2.0 model change to 1.3
THIS VOTE NEEDS TO GO ON USER LIST -igor On 3/7/07, Johan Compagner [EMAIL PROTECTED] wrote: In 2.0 we have a model change: IModel.getObject(Component) - IModel.getObject() IModel.setObject(Component,Object) - IModel.setObject(Object) So if you want to object from a component in 2.0 you only have to do: component.getModel().getObject() instead of component.getModel().getObject() That XXX is depending on what kind of model you use. If the component did inherit a CompoundModel then you have to specify the component.this If you where owner of the compoundmodel then you shouldn't specify anything (null) This is all fixed in 2.0 and now we can backport it to 1.3: 1 port it to 1.3 2 don't port it to 1.3
Re: generics in Wicket
why? that one can be simple disabled. PageStore works perfectly without it. I think our in/output will always jump into cases that are not completely supported If that is the case. Then use the default one. Converters didn't cost me time (it was a patch) johan On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: and how many users did you make unhappy with the half working pagestore? maybe that shouldve been fixed before more energy was spent on backporting the converters. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: We have a team of over ten people, so I don't see why backporting features can't be done, especially as some are without a doubt worth it. Take the converter backport. We made at least two users happy already! And it makes no difference AT ALL to the speed at which the release comes. The release isn't bound to testing anyway, as the first goal of the upcoming release is to have a dry run for an Apache ok-ed release. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: oh please. the more stuff you add the more we have to test, the longer it takes. johan is talking about backporting the models and thats great, but he still hasnt fixed the serialization issues in the pagestore. we needed a feature freeze a long time ago, so that we _would_ concentrate on getting the legal issues resolved, but instead weve been happily hacking away. we should at least try to work on some bugs before adding new stuff in. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. What are you talking about? 1.3's release wasn't/ isn't postponed a single day because of us adding new features. The opposite is true: new features (like the converter change) are added because the release isn't out yet and it's still ok to add (or backport) features. No, there is no 1.3 release yet for two (and only two) reasons: 1) legal issues due to incubating 2) setting up the new release process and being short in time for some members who are working on that Eelco
Re: generics in Wicket
i always did say +1 (but i also said that i would do it when i fixed it) But again. This is purely for testing and pagestore is not halfbaked. That one is currently pretty perfect and heavily tested (thx matej!). The wicket serialization is just an extra that will be on going work. johan On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: and how many users did you make unhappy with the half working pagestore? maybe that shouldve been fixed before more energy was spent on backporting the converters. Didn't you +1 on setting that as the default, something I proposed /not/ doing? Eelco
Re: generics in Wicket
Sven+++! and no i will not use it as an excuse! On 3/7/07, Sven Meier [EMAIL PROTECTED] wrote: It was my rather limited energy that did the converter backport. Thus Johan can't use this effort as an excuse, that the pagestore isn't working already ;). Sven Igor Vaynberg wrote: and how many users did you make unhappy with the half working pagestore? maybe that shouldve been fixed before more energy was spent on backporting the converters. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: We have a team of over ten people, so I don't see why backporting features can't be done, especially as some are without a doubt worth it. Take the converter backport. We made at least two users happy already! And it makes no difference AT ALL to the speed at which the release comes. The release isn't bound to testing anyway, as the first goal of the upcoming release is to have a dry run for an Apache ok-ed release. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: oh please. the more stuff you add the more we have to test, the longer it takes. johan is talking about backporting the models and thats great, but he still hasnt fixed the serialization issues in the pagestore. we needed a feature freeze a long time ago, so that we _would_ concentrate on getting the legal issues resolved, but instead weve been happily hacking away. we should at least try to work on some bugs before adding new stuff in. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: thats not the point! its not about api breaks. this is why 1.3 is taking forever, you keep adding and adding and adding. What are you talking about? 1.3's release wasn't/ isn't postponed a single day because of us adding new features. The opposite is true: new features (like the converter change) are added because the release isn't out yet and it's still ok to add (or backport) features. No, there is no 1.3 release yet for two (and only two) reasons: 1) legal issues due to incubating 2) setting up the new release process and being short in time for some members who are working on that Eelco
Re: [Vote] Performance problems due to Component:initModel()
yes i have the same question. initmodel doesn't really do anything very special it just walks quickly over the parents. Can you profile it? Where does the real time go to? johan On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont get it, how many method invocations happen that they take 10 seconds? -igor On 3/7/07, Jan Vermeulen [EMAIL PROTECTED] wrote: Even if you want to control that, it could be done within the setModel() method. After all, that's exactly what is done for wrapOnAssignment. Why not apply the same logic to wrapOnInheritance ? Jan Eelco Hillenius wrote: Theoretically, people can manually set model to null after the component had it's own model first. But that would be quite weird. Eelco -- View this message in context: http://www.nabble.com/Performance-problems-due-to-Component%3AinitModel%28%29-tf3362476.html#a9360990 Sent from the Wicket - Dev mailing list archive at Nabble.com.
VOTE release 1.3beta
this vote is to release 1.3beta -igor
Re: VOTE release 1.3beta
+1 -igor On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: this vote is to release 1.3beta -igor
Re: VOTE release 1.3beta
+1 Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: this vote is to release 1.3beta -igor
Re: AjaxSubmitButton in Panel inside ModalWindow in a Form
Since I just backported nested forms from trunk, this works in 1.x :) All you need to do is to place a form inside modal window if you want to submit it. Wicket should take care of the rest. -Matej Al Maw wrote: AjaxSubmitButton in a ModalWindow using a Panel as content doesn't work if the ModalWindow component is itself embedded in a Form. The issue is that ModalWindow tacks its content on as a div on the body element, which places it outside the original form element. If we fix ModalWindow to inject its Panel content into the middle of the page where the component actually lies, then all the CSS is messed up - it uses position: absolute, which will work fine until you put the ModalWindow component inside something that is position: relative; If you add a form to the ModalWindow's Panel, then the nested Form resolution stuff removes the form element because it thinks it has a parent form, even though when it's rendered it's actually outside it. I'm not sure how to fix this, or even if it's possible to. Maybe we can make the nested form hierarchy check stop traversing its parents at ModalWindow boundaries, and require than things inside a ModalWindow have their own Form? Al
Re: VOTE release 1.3beta
+1 On 3/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote: this vote is to release 1.3beta -igor
roadmap
pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
Re: roadmap
This sounds good to me. The main point of critique I can think of is that so far we haven't be able to do releases very fast. So in that sense, the time schedule is probably very unrealistic. However, there is nothing I would like more then us to be able to actually *do* releases fast, so if this is another carrot on a stick to make *that* happen, I'm all for it. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
Re: roadmap
A very big problem for Martijn and me is actually that we can't go on with writing until 1.4 is created. Models are everywhere in the book, including a separate chapter, and they are based on the 2.0 models currently. Martijn and me would have to decide on whether to target 1.4 or 1.5 but it would be either of them. Freezing the writing for a few weeks is really unacceptable for us. I understand your problems of accepting the model change for 1.3, but if it doesn't get in there - which is fine - Martijn and me need that 1.4 branch fast. Eelco On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: This sounds good to me. The main point of critique I can think of is that so far we haven't be able to do releases very fast. So in that sense, the time schedule is probably very unrealistic. However, there is nothing I would like more then us to be able to actually *do* releases fast, so if this is another carrot on a stick to make *that* happen, I'm all for it. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
Re: roadmap
Right, how are we gonna compile that? Doesn't work like that. We have a source tree in sync with the examples. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: so write the models against 2.0. they will be exactly the same in 1.4branch. code examples i guess you can leave for later? -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: A very big problem for Martijn and me is actually that we can't go on with writing until 1.4 is created. Models are everywhere in the book, including a separate chapter, and they are based on the 2.0 models currently. Martijn and me would have to decide on whether to target 1.4 or 1.5 but it would be either of them. Freezing the writing for a few weeks is really unacceptable for us. I understand your problems of accepting the model change for 1.3, but if it doesn't get in there - which is fine - Martijn and me need that 1.4 branch fast. Eelco On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: This sounds good to me. The main point of critique I can think of is that so far we haven't be able to do releases very fast. So in that sense, the time schedule is probably very unrealistic. However, there is nothing I would like more then us to be able to actually *do* releases fast, so if this is another carrot on a stick to make *that* happen, I'm all for it. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
Re: roadmap
well yeah. write the text now, and the code examples later. or is that too unmanageable? but according to the roadmap we are releasing 1.4 fairly soon. can you put off the chapters that are affected by this? we do need to work around you to some degree because the book is an important asset, so you need to tell us what will absolutely not work for you and what you can live with. -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Right, how are we gonna compile that? Doesn't work like that. We have a source tree in sync with the examples. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: so write the models against 2.0. they will be exactly the same in 1.4branch. code examples i guess you can leave for later? -igor On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: A very big problem for Martijn and me is actually that we can't go on with writing until 1.4 is created. Models are everywhere in the book, including a separate chapter, and they are based on the 2.0 models currently. Martijn and me would have to decide on whether to target 1.4 or 1.5 but it would be either of them. Freezing the writing for a few weeks is really unacceptable for us. I understand your problems of accepting the model change for 1.3, but if it doesn't get in there - which is fine - Martijn and me need that 1.4 branch fast. Eelco On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: This sounds good to me. The main point of critique I can think of is that so far we haven't be able to do releases very fast. So in that sense, the time schedule is probably very unrealistic. However, there is nothing I would like more then us to be able to actually *do* releases fast, so if this is another carrot on a stick to make *that* happen, I'm all for it. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
Re: roadmap
well yeah. write the text now, and the code examples later. or is that too unmanageable? That's funny, really. :) but according to the roadmap we are releasing 1.4 fairly soon. can you put off the chapters that are affected by this? To some degree, for a couple of weeks at most. we do need to work around you to some degree because the book is an important asset, so you need to tell us what will absolutely not work for you and what you can live with. I/ we can live with a week or 3/ 4, but that would be absolutely the max before we get in serious trouble. But I'll let Martijn chip in when he wakes up. Eelco
Re: [VOTE] All examples in one project, Java 5 required
Martijn Dashorst wrote: I propose to make the examples projects Java 1.5 dependent. Everyone said yes, so I assume this is going ahead. Has there been any progress on this? I'm wanting to fiddle with Maven 2 build procedures and things prior to getting the 1.3 beta out, and if you have tons of outstanding commits with this, it may be tricky. :-) Al
Re: [Vote] remove add() and pass parent in constructor?
igor.vaynberg wrote: hello all, we, the core devel group, have been discussing and evaluating a possible change we would like to make for the next release and we would like your input. the idea is to remove the Component.add(Component child) method and link components via a constructor instead: Component(Component parent, String id) this has a couple of advantages: * have access to markup the component is attached to in the constructor. that means you can read attributes and initialize your component appropriately. it also means we can eliminate the use of attribute modifiers for non-dynamic attribute replacement. -- attribute modifier is more flexible and reusable * we can fail super-early if there is a mismatch between component and markup hierachies. currently we dont fail until render time, with this change we can fail in the Component constructor - so before the component is actually created. this will give you a line precise error in markup AND java code. -- The trade off is too high, It can be archive with more explicit mechanism, not by forcing static structure and let compiler checking help detect this. * getPage() and getPath() will work in the component's constructor. this is really nice for ajax stuff. --- It should be available in other component lifcycle method, or use publish subscribe mechanism , shouldn't rely on constructor ( which means vm object creation ). the big disadvantage of course is that we will break ALL existing code. it is a simple change to fix though. a hybrid of this and add() will not work because all links in the chain need to use the new constructor for it to work. we would also provide Component.remove() and Component.readd() which remove/readd component to its parent. so the link between parent and child is now managed on the child's side instead of the parent's side. this, of course, makes it impossible to move components between parents - is there a usecase for this? --- component can not switch parent. Usecases: CMS - layout designer provide template and look and feel and let's content author to place component in placeholder and may be switch between placeholder, component may appear across pages (state is ratained across page) Rich Internet Application UI - multitab pane , doggable pane which user can move pane around. Portal - wicket component can be views as portlet and viewlet which use can customized to suit their needs. - 2.0 It means I have to recreate it, specifying new parent in constructor , copy all state from the old panel to the new one and place in new placeholder. please provide us with feedback/concerns so we have a better feel for requirements out there. thanks, -Igor -- View this message in context: http://www.nabble.com/remove-add%28%29-and-pass-parent-in-constructor--tf929620.html#a9369154 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] remove add() and pass parent in constructor?
On 3/7/07, aozster [EMAIL PROTECTED] wrote: * have access to markup the component is attached to in the constructor. that means you can read attributes and initialize your component appropriately. it also means we can eliminate the use of attribute modifiers for non-dynamic attribute replacement. -- attribute modifier is more flexible and reusable for simple usecases where you just want to set a class from java code it is not. it has an overhead of an entire class instance where a simple string would do just as well. the overhead is with respect to storage in session. * we can fail super-early if there is a mismatch between component and markup hierachies. currently we dont fail until render time, with this change we can fail in the Component constructor - so before the component is actually created. this will give you a line precise error in markup AND java code. -- The trade off is too high, It can be archive with more explicit mechanism, not by forcing static structure and let compiler checking help detect this. yes but it took practical experience to figure it out. nothing more explicit then what we have in 1.3 is possible really. the advantage of this is that you get a stactrace that points to the offending instantiation in java rather then a pointer to the markup. * getPage() and getPath() will work in the component's constructor. this is really nice for ajax stuff. --- It should be available in other component lifcycle method, or use publish subscribe mechanism , shouldn't rely on constructor ( which means vm object creation ). there is nothing vm object creation about this. constructors in java have the same properties as constructors in c++ or any other language afaik. they are atomic, if they do not succeed the instance is not created. wicket components rely on these to properly initialize themselves. wicket components are not beans, they are full blown objects. the big disadvantage of course is that we will break ALL existing code. it is a simple change to fix though. a hybrid of this and add() will not work because all links in the chain need to use the new constructor for it to work. we would also provide Component.remove() and Component.readd() which remove/readd component to its parent. so the link between parent and child is now managed on the child's side instead of the parent's side. this, of course, makes it impossible to move components between parents - is there a usecase for this? --- component can not switch parent. Usecases: CMS - layout designer provide template and look and feel and let's content author to place component in placeholder and may be switch between placeholder, component may appear across pages (state is ratained across page) Rich Internet Application UI - multitab pane , doggable pane which user can move pane around. Portal - wicket component can be views as portlet and viewlet which use can customized to suit their needs. we actually have a rough reparenting support in trunk, but it isnt very nice. im sure it could be made better with more work, but probably not worth it. -igor
Re: VOTE release 1.3beta
+1 on 1.3-beta1-incubating. On 3/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote: this vote is to release 1.3beta -igor
Re: [VOTE] All examples in one project, Java 5 required
This is one for after the current release... Putting them into one project and making it beautiful just takes longer. Will be ready for final I hope. Martijn On 3/8/07, Al Maw [EMAIL PROTECTED] wrote: Martijn Dashorst wrote: I propose to make the examples projects Java 1.5 dependent. Everyone said yes, so I assume this is going ahead. Has there been any progress on this? I'm wanting to fiddle with Maven 2 build procedures and things prior to getting the 1.3 beta out, and if you have tons of outstanding commits with this, it may be tricky. :-) Al -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: roadmap
oeps sorry didn't see this thread yet so here is it again: i really hate that roadmap, really i do. So you really want quickly 1.4 after 1.3 and i guess 1.3 is completely in maintenance mode pretty much directly because if we start working on 1.5 you really don't want 1.3 anymore That means that people that all do 1.3 stuff now are going to 1.4 anyway (especially because it is also not java5 yet again) Releasing so quickly is in my eyes a bad thing. And i really don't want to release as much under the incubating flag (i sort of already don't want to do that for 1.3!! but i can live with that if we really really have to) so i am -1 on this release cycle. what you call 1.3 and 1.4 should be in my eyes 1.3 and why you call 1.5 is in my eyes 1.4. Give people a big chunk and let that sink in for quite a while. Dont go releasing like a mad man. johan- Show quoted text -
Re: roadmap
thats another good reason to combine the 1.3 and 1.4 I still don't get it why release that fast and why let people completely walk over there code twice. If i as a user i am horrified. Do it once and be over with it. johan On 3/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote: A very big problem for Martijn and me is actually that we can't go on with writing until 1.4 is created. Models are everywhere in the book, including a separate chapter, and they are based on the 2.0 models currently. Martijn and me would have to decide on whether to target 1.4 or 1.5 but it would be either of them. Freezing the writing for a few weeks is really unacceptable for us. I understand your problems of accepting the model change for 1.3, but if it doesn't get in there - which is fine - Martijn and me need that 1.4 branch fast. Eelco On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: This sounds good to me. The main point of critique I can think of is that so far we haven't be able to do releases very fast. So in that sense, the time schedule is probably very unrealistic. However, there is nothing I would like more then us to be able to actually *do* releases fast, so if this is another carrot on a stick to make *that* happen, I'm all for it. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
Re: roadmap
What should by the way all the users of 2.0 now do? They shouldn't backport to 1.3 that would be completely stupid so the have to keep using 2.0 until we make 1.4 available? Because if they do backport first to 1.3 to at least be on a stable branch or active develop branch then we screw them twice. first backport from 2.0 to 1.3 then they have to use the old model style then 1.4 comes along and they have to redo there model 2.0 style. johan On 3/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote: pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
Re: roadmap
Up to now we didn't release a thing from 1.3 nor 2.0. I'm totally for releasing something 1.3-ish this weekend, if only for the selfish reason that I want to stabilize on a release for one of the branches of the system I'm working on. So I would like - and I'm sure others as well - to have *some* official version, whatever the version name. Now, personally, I'm in favor of doing anything in 1.3, but I can see Al's point and if he feels that strongly about it, I'm flexible (even though it gives Martijn and me more pain in the writing). The big thing that I'm afraid of, just looking at how we have functioned as a project so far, is that these couple of weeks are going to be a couple of months. Eelco On 3/7/07, Johan Compagner [EMAIL PROTECTED] wrote: thats another good reason to combine the 1.3 and 1.4 I still don't get it why release that fast and why let people completely walk over there code twice. If i as a user i am horrified. Do it once and be over with it. johan On 3/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote: A very big problem for Martijn and me is actually that we can't go on with writing until 1.4 is created. Models are everywhere in the book, including a separate chapter, and they are based on the 2.0 models currently. Martijn and me would have to decide on whether to target 1.4 or 1.5 but it would be either of them. Freezing the writing for a few weeks is really unacceptable for us. I understand your problems of accepting the model change for 1.3, but if it doesn't get in there - which is fine - Martijn and me need that 1.4 branch fast. Eelco On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: This sounds good to me. The main point of critique I can think of is that so far we haven't be able to do releases very fast. So in that sense, the time schedule is probably very unrealistic. However, there is nothing I would like more then us to be able to actually *do* releases fast, so if this is another carrot on a stick to make *that* happen, I'm all for it. Eelco On 3/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote: pasted from almaw's email on @user -igor -- 8 In my opinion we could, within the next: - 1 week - Push 1.3-betas as-is. 2/3 weeks - Bug fix as people test it and push out rc's when we feel it's solid and stable. 4 weeks - Rename 1.x branch to 1.3.x. - Release 1.3.0 final and put 1.3.x immediately into maintenance mode. - Create 1.4.x branch from 1.3.0 tag. - Merge the model changes from trunk to 1.4.x. - Backport anything else from trunk to 1.4.x that's not JDK5-specific. 6 weeks - Push out 1.4-betas 7/8 weeks - Push out 1.4-rc's 9 weeks - Push out 1.4.0 final - Create 1.5.x branch from 1.4.0 tag. - Backport/add generics, covariance and other JDK 5 trunk features to the 1.5.x branch. - Move trunk to 2.0_deprecated_-_use_1.5.x_instead 14+ weeks - Release 1.5.0 Suggestions to make this work: -- We won't backport from 1.4.x - 1.3.x. We won't actively develop trunk. We will push 1.4 out very soon after 1.3, and encourage migration. We will have this in a public roadmap so people can see it coming. Notes on what you think is insanity, but actually isn't: We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x, 1.5.x and what's currently trunk). This may seem like madness to you, but I reckon it isn't: During 1.3 development, 2.x is low activity, 1.2.x negligible. During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible. During 1.5 development, only 1.4.x will also be quite active. Once 1.5.0 is out, we can properly deprecate 2.0. People currently using it may not like being told to migrate to 1.5.x, but that shouldn't be too hard (much less hard than going from 1.3-2.0) and there shouldn't be too many of them. I guess that's the price you sometimes pay for using unreleased software. :-/ I'd envisage 1.4.x will require some backports from 1.5.x. We'd obviously encourage core developers and patchers to upgrade their sites to use 1.5.x, do active development on that, and therefore try to only ever backport from 1.5.x to 1.4.x, not forward-port the other way around. If you think I'm smoking crack, the above is utterly unreasonable, you want to kick me out of the gang, or you have any better ideas or suggestions as to how to keep everyone happy, please shout now. :-) Best regards, Alastair
