If someone (Frank?) is up to helping me a bit this weekend, how about
putting our beta 5 this weekend. The reason is selfish: we
(Teachscape) are gonna do a big release this weekend, I just fixed an
issue I need, and I also would like to use the memory improvements,
but I don't want to fix on
i think there are no really major showstoppers at the moment. (as far as i
know)
And whats the difference for you if you just take beta5 now and use that in
your production
or if we already called that final? It will be the same kind of code.
There isn't anything different then the label we give
On 10/22/07, Johan Compagner [EMAIL PROTECTED] wrote:
i think there are no really major showstoppers at the moment. (as far as i
know)
And whats the difference for you if you just take beta5 now and use that in
your production
or if we already called that final? It will be the same kind of
We already have such thing. It's called SimpleSynchronousPageStore and
it uses one file per page all in request thread. So it's not optimized
at all, but it can be good for development.
-Matej
On 10/22/07, Johan Compagner [EMAIL PROTECTED] wrote:
remove the current implementation
the thing
But api breaking or not that still doesn't mean anything because if they
use the label beta5 now and they use that now in production and it works
perfect for them
then that label doesnt say anything.
But i agree if they need a fix then the drop in beta6 or RC or final could
maybe not work.
but i
ok didn't know that, then it can be removed.
On 10/22/07, Matej Knopp [EMAIL PROTECTED] wrote:
We already have such thing. It's called SimpleSynchronousPageStore and
it uses one file per page all in request thread. So it's not optimized
at all, but it can be good for development.
-Matej
All,
Since talk has started on the final release of 1.3, we should start
writing an announcement document that provides more insight into the
new features of 1.3. The primary goal of this document is to post it
on TSS, infoq, etc. The full list of jira issues would be overkill :-)
Where shall we
Sorry for joining in so late. I don't have any time this weekend to do a
release. I have time next weekend (3-4. nov.)
Frank
On 10/20/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hey,
If someone (Frank?) is up to helping me a bit this weekend, how about
putting our beta 5 this weekend. The
On Mon, 2007-10-22 at 11:13 +0200, Johan Compagner wrote:
but i am already in a none api break mode at this time
I still hope that all the refactoring we have done in 1.3 will result in a
much stabler api from now on
For example i don't see the major interfaces like all the model
You are asking the same question as I do for myself. How and when can we wicket
2.0 users can continue to use current wicket versions.
-Ursprüngliche Nachricht-
Von: Philip A. Chapman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 22. Oktober 2007 17:32
An: dev@wicket.apache.org
Betreff:
I suspect that he meant to say: the API is stable for 1.3. We still
stick to supplying JDK 1.5 model implementations that sport generics.
I haven't heard anything to the contrary.
Generics support should become available on trunk after 1.3.1/1.3.2.
Usually we create a separate branch for a stable
for me generics is not an api change.
do you think that there was an api change in the jdk collection classes when
they applied generices?
the old code will still compile fine with the new generified api
johan
On 10/22/07, Philip A. Chapman [EMAIL PROTECTED] wrote:
On Mon, 2007-10-22 at
no i meant what i did say, i think the api change for 1.4 will not be that
much changed
as 1.2 - 1.3 (converters,validators,models all those are changed, i don't
think that will happen any time soon again)
and as i said generifying api is not an api change.
johan
On 10/22/07, Martijn Dashorst
correct me if im wrong, but the plan was (and still is?) for 1.4 to
ONLY have the generics applied...
-igor
On 10/22/07, Johan Compagner [EMAIL PROTECTED] wrote:
no i meant what i did say, i think the api change for 1.4 will not be that
much changed
as 1.2 - 1.3 (converters,validators,models
Wiki +1
On 10/22/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Since talk has started on the final release of 1.3, we should start
writing an announcement document that provides more insight into the
new features of 1.3. The primary goal of this document is to post it
on TSS, infoq, etc. The
igor.vaynberg wrote:
i am not aware of any show-stopping bugs, so i am ok if the next
release is an RC1.
I'll pipe in as a user here. We have struggled with the markup ID issues
discussed here:
On 10/22/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
correct me if im wrong, but the plan was (and still is?) for 1.4 to
ONLY have the generics applied...
Yes. 1.4 is for the last missing JDK 5 related features of 2.0.
Eelco
well, the idea is that we dont release it until after 1.3.2 by which
time there shouldnt be very many bugs left in 1.3
-igor
On 10/22/07, Johan Compagner [EMAIL PROTECTED] wrote:
yeah right.
so if i do that in 1 weekend then we release 1.4?
i don't think so. i am not going to maintain then
i think matej explained it very well in the link you gave in your mail.
The markup id of a component is only know when the component is rendered
in wicket we have 2 phases:
1 request phase (listener phase/component construction phase)
2 response phase (the render phase)
so if you want a markupid
i only see 1 problem arise if we quickly release the 1.4 version
then we have this:
people still on 1.2.x (there are still bug reports coming in)
people on 1.3
people on 1.4
and we have then branch for 2.0?
and i have to see if we can finalize 1.3 with one (or 2) release(s)
Of course just
+1 for Wiki too. i think it's the most visible media compared to
google-docs and svn.
On 10/22/07, Sean Sullivan [EMAIL PROTECTED] wrote:
Wiki +1
On 10/22/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Since talk has started on the final release of 1.3, we should start
writing an
can't it be appended to the wike site that we already have for explaining
the api breaks?
Thats already pretty explained there.
johan
On 10/22/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
Since talk has started on the final release of 1.3, we should start
writing an announcement
look at the TextTemplateHeaderContributor.forJavaScript()
you can then substitute javascript id's with the generated onces.
johan
On 10/22/07, Watter [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
The only problem is custom javascript. But can't you also parse that
javascript also
On Mon, 2007-10-22 at 18:27 +0200, Johan Compagner wrote:
for me generics is not an api change.
do you think that there was an api change in the jdk collection classes when
they applied generices?
I've always thought of adding generics as an api change. Sure, it's one
that doesn't break
On 22 Oct 2007, at 15:16, Philip A. Chapman wrote
I've always thought of adding generics as an api change. Sure,
it's one
that doesn't break backward compatibility, but it's a change non the
MetaDataKey(Class) - MetaDataKeyT
would count as an API change? Because the keys are always
yes thats the exception. But still T is not really a substitute for the
Class object
Because if you just ignore generics then you can do what ever you want
and currently you will get an exception..
But i guess it cleans up the api so that will be a break if nobody objects.,
johan
On 10/22/07,
On 22 Oct 2007, at 15:55, Johan Compagner wrote:
yes thats the exception. But still T is not really a substitute
for the
Class object
Because if you just ignore generics then you can do what ever you want
and currently you will get an exception..
But i guess it cleans up the api so that
but then you choose for it (you really have to make a choice what kind of
object you put in it)
thats not the case if it wasn't there.
Also we could make it so that it was really 1 way of doing so
object.getClass() == getClass()
then even that wouldn't work. But that just annoys i guess.
johan
On 22 Oct 2007, at 16:18, Johan Compagner wrote:
but then you choose for it (you really have to make a choice what
kind of
object you put in it)
thats not the case if it wasn't there.
Also we could make it so that it was really 1 way of doing so
object.getClass() == getClass()
then even
anybody with more insight into transparentResolvers (matej, igor?):
what is the desired behavior for invisible transparentResolvers?
it's really undefined right now, as the resolver is not rendered, but the
children _are_ (though without markup).
if children of an invisible transparentResolver
30 matches
Mail list logo
