Hmm,
Is this change discussed enough? This will break the API for a lot of
applications that use IDataProvider.
Martijn
On 12/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jcompagner
Date: Sat Dec 9 01:57:53 2006
New Revision: 484958
URL:
as i said it syncs the 2 api's 2.0 and 1.3 so thats a plus for me.
And the api break is not that big, just one method that must be added If
that was not already done
because you could already implemented IDetachable.
johan
On 12/9/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Hmm,
Is this
Hi,
i posted this underlying text ago, and missed to write in it that i dont use
the default but a BookmarkablePages (with index-strategy) PagingNavigator. I
assuemed that sth. was wrong with this but could now track it down to a
strange wicket behaviour.
If you have a page that has following
Though not as popular as IModel, I think this will cause some
headache's with our users.
I suspect the most common use of IDataProvider is to do new
IDataProvider(){...} on the spot, though I am not sure.
I think this change is controversial enough to warrant a vote before
it is committed: we
but that repeater move is currently being done by igor. (as far as i know)
So then it will change anyway.
And if we move that i am +1 to do it in both places 1.3 and 2.0 to keep it
in sync as much as possible,
johan
On 12/9/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Though not as popular
I have just returned from holiday, and hope to get the last license header
crap done tomorrow. (I don't know if anyone have done anything, while I was
away. I'm trying to get through ~300 mails ;)
I might want some help with some rewriting so we can try to get the first
release right. I'll get
All
I was going to move the datepicker from trunk to wicket-stuff, but
there is already a wicket-contrib-datepicker there. What do we do with
that project?
As I already moved the 1.3 datepicker to wicket-stuff under
wicket-contrib-datepicker in 1.2 branch, I propose to either move the
current
All,
We have several fixes in for 1.2.4, and one still open. When can we
release 1.2.4?
Bug
[WICKET-29] - javascript error in wicket-ajax.js: Wicket.Log.Error is
not a function
[WICKET-31] - Wrong source paths in build.xml
[WICKET-35] - WicketTester doesn't pass PageParameters to bookmarkable
Hi all,
Dojo-wicket-contrib is now full of new features. So I have now 2 questions :
How can I update wicket-dojo web site to make an annoucement of the future
jar release?
Are there relased date for Wicket 1.3 and wicket 2.0
Thanks
--
Vincent
Hmm, the last two guys working on wicket-contrib-dojo were students
(now employees) at our company. I'll ask them.
I think it is:
maven site
or
mvn site
if you upgraded to maven 2.
To deploy automatically you need to follow the maven instructions, and
sf.net instructions to ssh the files
Hi,
i volunteered for wicket-stuff maintainer (whatever i thought about this :O
) and just browsed through the wicket stuff svn repo and i think we really
need a better organisation of this. Currently we have
/branches - helds 1.1, 1.3, and 1.2, branch as well as /vendor (whatever
this is for)
On 12/9/06, Vincent Demay [EMAIL PROTECTED] wrote:
How can I update wicket-dojo web site to make an annoucement of
the future jar release?
Typically we don't announce future releases, but actual releases ;-)
I think for this kind of stuff you could 'spam' the mailinglist, as
that gives you
I'm curious - why are 3 different versions of Wicket (1.2.x, 1.3.x, 2.x)
being worked on? Isn't that a burden compared to focusing on two? When will
the 1.2.x line be let go?
Thanks,
Jon
On 12/9/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We have several fixes in for 1.2.4, and one
It is a burden. However we did close down 1.2 and put it into maintenance mode:
Wicket 1.2.4 only contains fixes for serious bugs. As Wicket 1.2 is
used in production systems, this is only natural. Each fix needs to be
voted on before applied to 1.2.4. This is to ensure that we don't keep
on
I found this in the Form component of 2.0 (didn't look at 1.x):
/**
* Method made final because we want to ensure users call setVersioned.
*
* @see wicket.Component#isVersioned()
*/
@Override
public boolean isVersioned()
{
+1 to release 1.2.4
Also we really start thinking of making binary build/releases of 1.3 and or
2.0
johan
On 12/9/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We have several fixes in for 1.2.4, and one still open. When can we
release 1.2.4?
Bug
[WICKET-29] - javascript error in
wasn't that the one that should replace the current one?
So then it is more like a swap?
On 12/9/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All
I was going to move the datepicker from trunk to wicket-stuff, but
there is already a wicket-contrib-datepicker there. What do we do with
that
It's not on the top of my head when/ how, but final was removed a long
time ago because it just worked better. Like e.g. isVisible, even
though the fact that the method is not final results in a weaker
contract, in practice this rarely (or never) leads to problems, while
the ability to override
Are there relased date for Wicket 1.3 and wicket 2.0
I would actually be confident enough calling 1.3 final right away
(1.3.0) or maybe do one release candidate first.
Eelco
sure, go ahead and swap them. the one in wicket-stuff is nowhere near usable
though - it still needs a lot of work.
-igor
On 12/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah, I think the idea was to swap them. But Igor and the others who
worked on that project may be able to say more
/branches - helds 1.1, 1.3, and 1.2, branch as well as /vendor (whatever
this is for) and a (!) wicket-stuff directory...
Any branch goes if it makes sense to the people creating it. Every now
and then, it would be good if people delete obsolete branches again
(if they are *very careful* about
21 matches
Mail list logo
