[X] Yes, let's go Apache
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.
so whats the deal with the resolvers? you guys come up with something concrete?i was thinking about the repeaters - currently if you look at ICellPopulator the populateItem method looks like this:void populateItem(final Item cellItem, final String componentId, final IModel rowModel);
that component
so whats the deal with this, i would like to upgrade the repeaters package. johan, you have the usecases in your app - how are they working now? do you have an idea of how the api would look?-Igor
On 8/8/06, Igor Vaynberg <[EMAIL PROTECTED]
> wrote:i just dont think its a very common usecase to do
[X] Yes, let's go Apache[ ] No, let's not do that and look for other alternatives
-- Ingram ChenJava [EMAIL PROTECTED]Institue of BioMedical Sciences Academia Sinica Taiwanblog: http://www.javaworld.com.tw/roller/page/ingramchen
Did you file an issue Juergen?
Eelco
On 8/20/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> The rememberMe functionality in login screens does not longer work;
> check the examples. I checked the CookieValuePersister which seems to
> work fine. The issue seems to be that onSubmit is not auto
yeah, i agree. this is once place i got carried away with making things
convenient. those particular convenience methods should go away. i'm a
little less sure about getting rid of setResponsePage(), but from certain
perspectives that would be better too.
getRequestCycle().setResponsePage(...
[X] Yes, let's go Apache
I think it will add to Wicket's visibility and credibility. Good move.
--
View this message in context:
http://www.nabble.com/VOTE%3A-incubation-at-Apache-tf2141169.html#a5916272
Sent from the Wicket - Dev forum at Nabble.com.
---
Hi,
The bit about committers and binding doesn't mean we only want
comitters votes, rather just that if the comitter's were against it,
it wouldn't happen (without a rethink/discussion, at least).
We're interested in the views/votes of anyone with an interest in
Wicket, so please let us know/v
Not being a committer may I still add my voice?[X] Yes, let's go Apache[ ] No, let's not do that and look for other alternativesIt's a unanimous vote so lets go guys!!F
On 8/21/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi all,Some time ago we announced that we started negotiations with Apache
This is my non-binding vote:
[ x ] Yes, let's go Apache
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download I
Yeah. +1
I've been using file upload and I'm not sure if I've closed it all the
time. Hmm.. some nasty leaks could have been there... I should go and
check it.
-Matej
SourceForge.net wrote:
> Bugs item #1543832, was opened at 2006-08-21 11:53
> Message generated for change (Tracker Item Submit
[X] Yes, let's go Apache
Eelco Hillenius wrote:
>
> Hi all,
>
> Some time ago we announced that we started negotiations with Apache to
> start an incubation process. That basically means we would be entering
> a 'test period' where we proof ourselves to fit in as an Apache
> process, adhering
[X] Yes, let's go Apache
Jan
Eelco Hillenius wrote:
>Hi all,
>
>Some time ago we announced that we started negotiations with Apache to
>start an incubation process. That basically means we would be entering
>a 'test period' where we proof ourselves to fit in as an Apache
>process, adhering Apac
And don't get me wrong. I'm not surgesting anything like rewriting all test to use some sort of TagTester. I'm just saying that perhaps it can be used as a supplement or in some cases a replacement for the diff-test.
But I think it can be a good way to test more different cases with less effort. Wh
[X] Yes, let's go Apache[ ] No, let's not do that and look for other alternatives
- Frank
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to mak
> [ X] Yes, let´s go party^H^H^H^H^HApache
> [ ] No, let's not do that and look for other alternatives
/Gwyn
--
Download Wicket 1.2.1 now! - http://wicketframework.org
-
Using Tomcat but need to do more? Need to support web
[X] Yes, let's go Apache
[ ] No, let's not do that and look for other alternatives
Let's see where this takes us.
Martijn
--
Download Wicket 1.2.1 now! Embed Wicket components in your portals!
-- http://wicketframework.org
--
[X] Yes, let's go Apache
[ ] No, let's not do that and look for other alternatives
Ate
Eelco Hillenius wrote:
> Hi all,
>
> Some time ago we announced that we started negotiations with Apache to
> start an incubation process. That basically means we would be entering
> a 'test period' where we
[X] Yes, let's go Apachelets join the old boys club.On 8/21/06, Eelco Hillenius <[EMAIL PROTECTED]
> wrote:Hi all,Some time ago we announced that we started negotiations with Apache to
start an incubation process. That basically means we would be enteringa 'test period' where we proof ourselves to
[X] Yes, let's go Apache
[ ] No, let's not do that and look for other alternatives
Juergen
On 8/21/06, Dirk Markert <[EMAIL PROTECTED]> wrote:
> [X] Yes, let's go Apache
>
> Dirk
>
> 2006/8/21, Eelco Hillenius <[EMAIL PROTECTED]>:
> > Hi all,
> >
> > Some time ago we announced that we started ne
[X] Yes, let's go ApacheDirk2006/8/21, Eelco Hillenius <[EMAIL PROTECTED]>:
Hi all,Some time ago we announced that we started negotiations with Apache tostart an incubation process. That basically means we would be enteringa 'test period' where we proof ourselves to fit in as an Apache
process, adh
[ x ] Yes, let's go Apache
[ ] No, let's not do that and look for other alternatives
Eelco
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology t
[X] Yes, let's go Apache
[ ] No, let's not do that and look for other alternatives
-Matej
// Although I still think Wicket Foundation sounds cool :-))
Eelco Hillenius wrote:
> Hi all,
>
> Some time ago we announced that we started negotiations with Apache to
> start an incubation process. That
dont get me wrong, im not saying the tagtester is better, in fact i havent looked at it yet, im just telling you what i dont like about our current system. ive ran into it a lot - i change how a url for an ajax call is generated - and all of a sudden a bunch of things break. im always worried about
On 21.8.2006, at 19.06, Eelco Hillenius wrote:[ x] Yes, let's go Apache[ ] No, let's not do that and look for other alternativesJanne-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done qu
[X] Yes, let's go Apache[ ] No, let's not do that and look for other alternatives-IgorOn 8/21/06, Jean-Baptiste Quenot <
[EMAIL PROTECTED]> wrote:Here's my non-binding vote:> [XX] Yes, let's go Apache
> [ ] No, let's not do that and look for other alternatives-- Jean-Baptiste Quenotaka John
But it is very easy to fix. Just add
-Dwicket.replace.expected.results=true while executing the tests. How
often to change all the headers? I looked at TagTester and it is very
similar to what we used to have. Because it tests only very little, it
will hardly ever detect any side effects. And it is
Here's my non-binding vote:
> [XX] Yes, let's go Apache
> [ ] No, let's not do that and look for other alternatives
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
-
Using Tomcat but need to do
Yeah. I don't see why we should back port it at this time. It's an API
improvement, but not a life saver.
Eelco
On 8/21/06, Frank Bille <[EMAIL PROTECTED]> wrote:
> I haven't done that. I could try that tonight and then backport it. But I
> have the same thought. I'm not sure it should be backpor
Hi all,
Some time ago we announced that we started negotiations with Apache to
start an incubation process. That basically means we would be entering
a 'test period' where we proof ourselves to fit in as an Apache
process, adhering Apache's rules for creating distributions, voting,
etc. The propos
i think its fragile because for example, if we do something to head of all pages - cookie/window.name change, then all the tests sunddenly break. thats the part that sucks.-Igor
On 8/21/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
We tried it some time back, actually we started with somethings
What Upayavira proposes sounds good because it's simple and obvious.
We can have very lenghty discussions on this but I don't think it is
anything important compared to actually writing some code. What *is*
important is to get rid of the confusion of having a wicket_1_2_x
branch. Whatever way we ge
On 21/08/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> On 8/20/06, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> > (b) I *really* don't like the idea of tags for a particular version
> > being something other than tagging the particular revision used to
> > create the release.
>
> I haven't proposed
But that second thing is what Upayavira proposes so trunk is always just the latest code (head) now 2.0and we just have branches 1.2 and 1.3 and what ever we get.johan
On 8/21/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
but when we will have 3 main development streams: 1.2, 1.3 and 2.0What I'm
bah. this is going to be driven the other way around. when someone needs
to nest something in the html they are going to go "oh shoot, is this a
container?" and then they'll look and see it is. i don't see a reason for
some other name here.
igor.vaynberg wrote:
>
>>
>> Only by having such a
I haven't done that = I haven't tried it.On 8/21/06, Frank Bille <[EMAIL PROTECTED]> wrote:
I haven't done that. I could try that tonight and then backport it. But I have the same thought. I'm not sure it should be backported to
1.2. Right now it's only in 2.x- Frank
On 8/21/06, Martijn Dashorst <
I haven't done that. I could try that tonight and then backport it. But I have the same thought. I'm not sure it should be backported to 1.2. Right now it's only in 2.x- Frank
On 8/21/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Have you tested it as a drop-in replacement for wicket-1.2.1 (or 1.
Have you tested it as a drop-in replacement for wicket-1.2.1 (or 1.2)
? Binary compatibility is still something we should strive for. Is it
possible that with this change the binary compatibility has been
altered?
Perhaps someone *expecting* that component instanceof Button returns
false for AjaxS
Patches item #1543852, was opened at 2006-08-21 12:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684977&aid=1543852&group_id=119783
Please note that this message will contain a full co
+1, that method always looked out of place on IModel
Jan
>
> And i know that getNestedModel() method of IModel is used ofter in a
> project
> for getting the real internal model. But i think i am +1 to just move
> the getNestedModel()
> to the IWrapModel and keep the IWrapModel.
>
>
--
Bugs item #1543832, was opened at 2006-08-21 11:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684975&aid=1543832&group_id=119783
Please note that this message will contain a full copy
but when we will have 3 main development streams: 1.2, 1.3 and 2.0
What I'm proposing is not to branch a development stream, but to tick
off releases from a main development stream, requiring us not to
switch to other directories:
With the literal names:
trunk/wicket-1.x
trunk/wicket-2.x
yes 1.3 will be another branch wicket_1_3_xthis has to be done because 1.2 should stay a branch by itsself. (because it could be that there has to be 1 few importand bugs fixed there)johan
On 8/21/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Like I said in the message:trunk/wicket-1.x/ will be t
Like I said in the message:
trunk/wicket-1.x/ will be the main development stream for 1.x
versions. It will be the HEAD for 1.3, 1.4, 1.5, 1.6
trunk/wicket-2.x/ will be the main development stream for 2.x
versions. It will be the HEAD for 2.0, 2.1, 2.2, 2.3, etc.
For 3.x we'll have to see when t
On 8/20/06, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> Hmm, I'm not really sure about much of this, to be honest...
>
> (a) I'm not sure that we should be equating 1.x development with 2.0
> development, i.e. I think the /trunk/wicket-[12].x is a bad move.
1.x development is *just* as important at th
We tried it some time back, actually we started with something
similar, but IMO it was horrible to maintain. But more importantly
because it focusses on a small part of the markup output only, it
failed to detect at all the tiny side effects some changes created.
That is probably why it is perceive
HeyI have played a little around with how to test rendered markup without having to do the somewhat fragile cached-markup-diff-thingy. I have committed a draft version of a TagTester which, based on the rendered markup, allows testing of specific tags without having to rely on the
attributes being
Committed yesterday. On 8/19/06, Frank Bille <[EMAIL PROTECTED]> wrote:
On 8/19/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
So? What's the progress with this? Looking at current AjaxSubmitLink itstill extends WebMarkupContainer...Yeah I know.. thanx bad conscience :)(I'm almost done, just need a li
we have still a little discussion about them. But i don't think they will change much.The discussion is purely about IWrapModel and the getNestedModel() method of IModel.What to do with both.I think getting rid of IWrapModel will be a bit hard. Because we need to know on some places
that it is a wr
49 matches
Mail list logo
