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*
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
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 prob
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
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.
Every
+1 on 1.3-beta1-incubating.
On 3/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
this vote is to release 1.3beta
-igor
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 attribut
a year too late? :)
-igor
On 3/7/07, aozster <[EMAIL PROTECTED]> wrote:
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 remo
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 con
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 o
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
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
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?
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. Mode
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
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
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
+1
On 3/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
this vote is to release 1.3beta
-igor
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 Mo
Igor Vaynberg wrote:
this vote is to release 1.3beta
+1, but only after I've made the Maven 2 stuff nicer, so we can make
this repeatable (WICKET-228).
Al
+1
Please note that this is merely a 'legal' release to ratify our
release procedure and to identify any remaining legal issues.
Martijn
On 3/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
+1
Eelco
On 3/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> this vote is to release 1.3beta
>
> -i
+1
Eelco
On 3/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
this vote is to release 1.3beta
-igor
+1
-igor
On 3/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
this vote is to release 1.3beta
-igor
this vote is to release 1.3beta
-igor
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
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
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
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
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
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 t
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:
compon
nope. I've just checked out entire 1.x brach today and built it
according to this
http://svn.apache.org/repos/asf/incubator/wicket/branches/wicket-1.x/wicket-parent/README.TXT
and everything worked fine.
(i had to run eclipse:eclipse twice, first with -Pjdk1.4 and for java 5
projects with -Pjd
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
t
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
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
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(XXX
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
> comp
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() meth
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 applicat
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
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 befor
ah. good point. so we should remove generics from subclasses that don't
benefit. how's that sound?
Johan Compagner wrote:
>
> 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
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 th
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?
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
fea
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 i
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
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
f
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
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
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:
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
i have the same feeling, and i also don't think we can drop one and still
have the other like we want.
So i guess we are stuck with what we have because i don't want completely
gone.
johan
On 3/7/07, Stefan Lindner <[EMAIL PROTECTED]> wrote:
Maybe I am too accustomed to generics now but I ca
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 ListView would
return T
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 pu
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
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 a
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:placeh
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
Yes. Back then I hoped we could make a first release by the end of
december as well. And as Johan ported converters as well yesterday,
this could go as well
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
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(componen
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 Component ... {
public Component(final MarkupContainer parent, final String id,
final IModel
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 pare
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
parameterize
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
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 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 ge
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 requ
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 ?" but without its innnerHtml, only the
componentTag. I think it should
you guys arent talking about putting it into 1.3 are you? can we please
finish with 1.3 already!
-igor
On 3/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
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
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
71 matches
Mail list logo
