Re: OT: Code quality (was Re: o.a.w.util.license package in production source folder?)
Did you guys consider working with pull requests on github? Works very well in my experience. Eelco On Mon, Aug 15, 2011 at 9:08 AM, Brian Topping wrote: > Yes, that will create a patch of the whole branch, which is already there. > > On Aug 15, 2011, at 11:58 AM, Martin Grigorov wrote: > >> git diff myBranch..master > some.patch >>> >>> On Aug 15, 2011, at 11:46 AM, Igor Vaynberg wrote: >>> can we have a patch that changes those places to use Args.*? :) -igor On Mon, Aug 15, 2011 at 7:50 AM, Brian Topping wrote: > Hi guys, > > Just to provide some personal perspective and it's somewhat off-topic... > there's always a lot of things we can work around here (code can always > be compensated for with more code), but I think there is a responsibility > with all code to "leave it cleaner than you found it". To say it > differently, to me, any amount of effort today to keep things clean is > worth it, because tomorrow (with additional code thrown on), it may take > twice as long to undo it and we may not have options to work around the > problem any longer (thus forcing that we cannot avoid cleaning it up with > twice the investment). > > When I looked at the actual usages of JUnit, it was primarily on > junit.framework.Assert in about three or four random files, when in fact > the standing pattern is to use o.a.w.util.lang.Args or throw an > IllegalStateException if there is a problem with incomplete > initialization. > > In this case, removing JUnit as a dependency from util in fact improves > the code, and in the process does not bury a dependency even deeper. In > fact, there was a comment in one of the POMs alluding to the question of > why JUnit was a runtime dependency. I don't think I am alone in > believing that it should have been removed. This doesn't answer to > o.a.w.util.tester.WicketTester, but that's better answered in Martin's > email. > > Cheers and thanks, > > Brian > > On Aug 15, 2011, at 2:44 AM, Andreas Pieber wrote: > >> Hey guys, >> >> I just want to jump in here. While I think it a good idea to check >> license >> headers via a plugin instead of a junit tests this is not a "no-go" for >> the >> osgification. There are various libs out there importing org.junit... in >> the >> compile phase instead of the test-phase (although not required). At >> Servicemix such libs are typically wrapped using the ;optional:=true >> attribute. Since junit is not required at runtime I think we can go the >> same >> way for wicket here. >> >> WDYT? >> >> Kind regards, >> Andreas >> >> On Sun, Aug 14, 2011 at 22:24, Brian Topping >> wrote: >> >>> Hi guys, thanks for the responses. The repository issue (as well as an >>> unknown about outside plugins) was a concern, part of why I started a >>> custom >>> plugin. But if folks are comfortable with it, I think it's the right >>> way to >>> go. It's used in Brix and it's been very robust and convenient. >>> >>> I created a branch at >>> https://github.com/topping/wicket/tree/myclila-plugin containing the >>> changes. There are a lot of them and it took most of the day to get it >>> right. The plugin expects the license header to be formatted slightly >>> differently (for instance using "/**" instead of "/*" to start a Java >>> header). Their site suggests using , but that results in >>> all >>> the configuration being in the parent POM, something that isn't very >>> good >>> encapsulation of configuration. So I broke it out between projects so >>> it's >>> easier to maintain. >>> >>> As for the specific excludes, I may not have precisely the same excludes >>> that the old test cases had. I started by copying them to the best of >>> my >>> perception, then tuned them for the tests (which seems to be the most >>> sensitive aspect). Can anyone review the patch to see if there are any >>> obvious mistakes? >>> >>> If not, it would be very helpful for the OSGi effort if we could get >>> this >>> patch applied. Removing the dependency on JUnit from wicket-util is >>> pretty >>> important to the effort, and I think this provides benefits to the >>> project >>> moving forward as well. >>> >>> Please let me know what I can do to facilitate. >>> >>> Kind regards, Brian >>> >>> On Aug 14, 2011, at 9:05 AM, jcgarciam wrote: >>> The problem with com.mycila.maven-license-plugin:maven-license-plugin as far as i remember is that is not yet published in central maven repository, so it cannot be used without adding their repo. in the >>> pom.xml which is a problem if you are trying to g
Re: Apache Wicket Cookbook Published!
Another baby, congrats! Eelco On Fri, Mar 25, 2011 at 10:44 AM, Igor Vaynberg wrote: > For the past nine months I have been quietly working on a book about > Wicket. Unlike other books on the market this one does not attempt to > teach you Wicket from the ground up. Instead, it is for developers who > already know the basics and want to learn how to implement some of the > more advanced use cases. Essentially, it contains recipes that show > the reader how to implement solutions to some of, what I think are, > the most commonly asked questions and stumbling blocks. This morning I > was informed that the book has been published! You can read more about > it and pick up a copy on PACKT's Site[1]. I hope you enjoy it, more > details below... > > [1] https://www.packtpub.com/apache-wicket-cookbook/book > > ## Description ## > > Apache Wicket is one of the most famous Java web application > frameworks. Wicket simplifies web development and makes it fun. Are > you bored of going through countless pages of theory to find out how > to get your web development done? With this book in hand, you don't > need to go through hundreds of pages to figure out how you will > actually build a web application. You will get practical solutions to > your common everyday development tasks to pace up your development > activities. > > Apache Wicket Cookbook provides you with information that gets your > problems solved quickly without beating around the bush. This book is > perfect for you if you are ready to take the next step from tutorials > and step into the practical world. It will take you beyond the basics > of using Apache Wicket and show you how to leverage Wicket's advanced > features to create simpler and more maintainable solutions to what at > first may seem complex problems. > > You will learn how to integrate with client-side technologies such as > JavaScript libraries or Flash components, which will help you to build > your application faster. You will discover how to use Wicket paradigms > to factor out commonly used code into custom Components, which will > reduce the maintenance cost of your application, and how to leverage > the existing Wicket Components to make your own code simpler. > > A straightforward Cookbook with highly focused practical recipes to > make your web application development easier with the Wicket web > framework > > ## What you will learn from this book ## > > * Leverage Wicket to implement a wide variety of both simple and > advanced use cases in a narrative that gets straight to the point > * Make forms work in the crazy world of the Web by learning the ways > of Wicket's form processing > * Simplify localizing your Wicket applications > * Take the boring out of your forms by discovering how to improve the > user experience while simplifying your code at the same time > * Leverage the built-in Table component to make displaying tabular data a snap > * Think Wicket's Borders are not very useful? Learn to use them in > unexpected places to simplify things > * See how to integrate with Flash components and create interactive > charts at the same time > * Web 1.0 too boring? Learn how to tame Wicket's AJAX support and > bring your application into Web 2.0 > * Simplify your security code by learning various security techniques > * An application cannot be built with Wicket alone; see how to make it > play nice with other frameworks > > ## Approach ## > > This is a hands-on practical guide to a large variety of topics and > use cases. This book tries to use real-world examples when possible, > but is not afraid to come up with a contrived pretext if it makes > explaining the problem simpler. Unlike a lot of other books, this one > does not try to maintain a continuous theme from chapter to chapter, > such as demonstrating solutions on the same fictional application; > doing so would be almost impossible given the wide variety of recipes > presented here. Instead, this book concentrates on focused problems > users are likely to encounter and shows clear solutions in a > step-by-step manner. This book tries to teach by example and is not > afraid to show a lot of code because, after all, it is for coders. > > ## Who this book is written for ## > > This book is for current users of the Apache Wicket framework; it is > not an introduction to Wicket that will bore you with tons of theory. > You are expected to have built or maintained a simple Wicket > application in the past and to be looking to learn new and better ways > of using Wicket. If you are ready to take your Wicket skills to the > next level this book is for you. > > Cheers, and I hope you enjoy the book! > -Igor > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Renaming IInitializer?
> We've always opted for specific, descriptive names, even when grossly > verbose :) I, too, think we should rename it. I like the approach of > moving it to an interface that extends IInitializer, deprecate and remove in > 1.6. Although, I feel like a 1.5 name change would be absolutely fine - > even with an RC out. It's a simple find/replace - not a complicated change. Simple maybe, but it does break the public API and some documentation (I think Wicket In Action mentions it), and that for no benefit other than that some people like the name better (you amongst others) and other people don't (me, Jonathan I'm guessing). I don't think it is worth it. Eelco
Re: Renaming IInitializer?
Doesn't solve anything in particular, right? Personally, I think the current names are fine. Eelco On Mon, Jan 24, 2011 at 1:19 AM, Martin Grigorov wrote: > On Tue, Jan 18, 2011 at 3:02 PM, James Carman > wrote: > >> ApplicationLifecycleListener? >> On Jan 18, 2011 8:14 AM, "Major Péter" wrote: >> > Hi, >> > >> > since IInitializer now also works as an IDestroyer, wouldn't be >> > ApplicationContextListener a better name for it? (based on >> > ServletContextListener) >> > > Renaming classes will make the migration harder. > Unless it is really needed I prefer to keep it as it is. > > Or maybe we can introduce new interface - ApplicationLifetimeListener that > just extends IInitializer and make IInitializer deprecated, and remove it in > 1.6.0. > >> > >> > Regards, >> > Peter >> >
Re: Do Lucene developers use FindBugs?
I don't know whether it is used structurally atm, but I have used Findbugs at least once or twice a few years ago with Wicket. Eelco 2011/1/24 César Couto : > Dear developers, > > I am a PhD student at UFMG, Brazil and as part of my research I am > making a study about the relevance of the warnings reported by the > FindBugs bug finding tool. > > Since I am planning to use Wicket as a subject system in my research, > I would like to know if Wicket's developers usually run FindBugs as > > part of the system development process. > > Thanks in advance, > > Cesar Couto > > -- > http://www.decom.cefetmg.br/cesar >
Re: [vote] retry: release wicket 1.5-rc1
duh :-) On Fri, Jan 21, 2011 at 2:58 PM, Igor Vaynberg wrote: > ault is the cut off DefaultMarkupSourcingStrategy > > -igor > > On Fri, Jan 21, 2011 at 2:52 PM, Eelco Hillenius > wrote: >> As far as I am concerned, that depends on this issue I just found: >> https://issues.apache.org/jira/browse/WICKET-3363. If that's just a >> problem with the example (probably the case, as the other localization >> examples work fine), I am +1 for releasing. If internationalization is >> broken, then I am -1. >> >> As a side note, I saw this in the logs when looking at the nested example: >> >> WARN - aultMarkupSourcingStrategy - 1.4 to 1.5 migration issue: your >> item component should be derived from AbstractItem. Item=[TreeItem >> [Component id = 10]] >> >> (and 'ault' probably needs to get rid of the 'u'?). >> >> Eelco >> >> >> On Fri, Jan 21, 2011 at 2:10 PM, Igor Vaynberg >> wrote: >>> +1 to release >>> >>> -igor >>> >>> >>> On Tue, Jan 18, 2011 at 10:16 AM, Igor Vaynberg >>> wrote: >>>> this is the second vote to release wicket 1.5-rc1. >>>> >>>> all vote-blocking issues previously reported have been fixed >>>> >>>> branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC1 >>>> artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC1/ >>>> maven repo: >>>> https://repository.apache.org/content/repositories/orgapachewicket-044/ >>>> changelog: >>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310561&fixfor=12315483&sorter/field=issuekey&sorter/order=DESC >>>> >>>> this vote ends Friday, January 21 at 10:00am GMT-8 >>>> >>>> please test the release and offer your vote >>>> >>>> cheers, >>>> -igor >>>> >>> >> >
Re: [vote] retry: release wicket 1.5-rc1
As far as I am concerned, that depends on this issue I just found: https://issues.apache.org/jira/browse/WICKET-3363. If that's just a problem with the example (probably the case, as the other localization examples work fine), I am +1 for releasing. If internationalization is broken, then I am -1. As a side note, I saw this in the logs when looking at the nested example: WARN - aultMarkupSourcingStrategy - 1.4 to 1.5 migration issue: your item component should be derived from AbstractItem. Item=[TreeItem [Component id = 10]] (and 'ault' probably needs to get rid of the 'u'?). Eelco On Fri, Jan 21, 2011 at 2:10 PM, Igor Vaynberg wrote: > +1 to release > > -igor > > > On Tue, Jan 18, 2011 at 10:16 AM, Igor Vaynberg > wrote: >> this is the second vote to release wicket 1.5-rc1. >> >> all vote-blocking issues previously reported have been fixed >> >> branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC1 >> artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC1/ >> maven repo: >> https://repository.apache.org/content/repositories/orgapachewicket-044/ >> changelog: >> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310561&fixfor=12315483&sorter/field=issuekey&sorter/order=DESC >> >> this vote ends Friday, January 21 at 10:00am GMT-8 >> >> please test the release and offer your vote >> >> cheers, >> -igor >> >
Re: Support for IDestroyableWebApplicationFactory is gone in 1.5
We shouldn't just remove things that were part of the public API without either providing an alternative or at least a good reason why it should be removed (and have that documented clearly as part of the migration documentation). Eelco On Thu, Jan 6, 2011 at 7:57 AM, Martin Grigorov wrote: > On Thu, Jan 6, 2011 at 4:42 PM, Matej Knopp wrote: > >> I don't think I've removed it, I just didn't carry it through :) >> > Yep, this is more correct way to explain :-) > >> >> There are probably more bells and whistles missing. >> > There are two problems here: > 1) we find them slowly, one after another > 2) we (and particularly the new guys in the team like me) are not sure > whether "the removal" is on purpose or not > > Thanks for helping! > >> >> -Matej >> >> On Thu, Jan 6, 2011 at 10:31 AM, Igor Vaynberg >> wrote: >> > +1 to reenable >> > >> > -igor >> > >> > On Thu, Jan 6, 2011 at 5:34 AM, Martin Grigorov >> > wrote: >> >> Hi, >> >> >> >> I just noticed that Matej removed the support >> >> for org.apache.wicket.protocol.http.IDestroyableWebApplicationFactory in >> >> WicketFilter in 1.5 with a change from 4 Jan 2010. >> >> With the new code we don't notify these factories on Filter#destroy(). >> >> If there is no strong reason to not support this feature then I'll >> re-enable >> >> it again. >> >> >> > >> >
Re: WebSession dirty()
Used to be used to determine whether the underlying session should be updated, which is/ was relevant for session replication. Eelco On Wed, Dec 29, 2010 at 2:03 AM, Juergen Donnerstag wrote: > In 1.5 trunk WebSession has a transient variable dirty which is set to > true when dirty() is called. But I don't see that the dirty variable > is used anywhere. Is that by purpose? How does it work? > > -Juergen >
Re: overriding isVisible bad?
> huh? that doesnt make any sense. the callbacks like onconfigure simply > give you checkpoints for calculating and caching visibility rather > then calculating every time. I wasn't arguing against onConfigure (which is a fine trade-off) but saw an example of where relying on just setVisible would be problematic. Now the problem is that we have three ways of achieving the same thing. And yet another overridable method. It's probably too late in the game, but I would be more in favor of a delegation mechanism (e.g. interfaces for the functions of isVisible, isEnabled and whatever else makes sense) and a way to set those functions. So you'd do things more through composition. Might even consider making working with such functions a generic capability that also supports detaching (which then can also be used to let the component manage detachment of multiple models if there's more than one), etc. Would be a significant break though, so I'm not expecting a lot of cheering :-) Eelco
Re: overriding isVisible bad?
gt; >> component
>>> >>> >> >> >> being
>>> >>> >> >> >> > rendered at 09:59:59
>>> >>> >> >> >> > isVisible(return dao.list().size() > 0);// performance
>>> issues
>>> >>> >> >> >> >
>>> >>> >> >> >> > But maybe we can have the best from both approaches. This is
>>> an
>>> >>> >> >> >> copy/paste
>>> >>> >> >> >> > from java.awt.Component:
>>> >>> >> >> >> >
>>> >>> >> >> >> > public boolean isVisible() {
>>> >>> >> >> >> > return isVisible_NoClientCode();
>>> >>> >> >> >> > }
>>> >>> >> >> >> > final boolean isVisible_NoClientCode() {
>>> >>> >> >> >> > return visible;
>>> >>> >> >> >> > }
>>> >>> >> >> >> >
>>> >>> >> >> >> > There are some points in the awt framework were the
>>> isVisible
>>> >>> >> method
>>> >>> >> >> is
>>> >>> >> >> >> not
>>> >>> >> >> >> > used in benefit of isVisible_NoClientCode
>>> >>> >> >> >> > I'm in favor of create an final isVisible/Enabled version
>>> and
>>> >>> >> change
>>> >>> >> >> the
>>> >>> >> >> >> > Wicket core to use it. Also maintain the hotspot to users
>>> >>> provide
>>> >>> >> >> their
>>> >>> >> >> >> > isVisible/Enable implementations that will serve to feed the
>>> >>> core
>>> >>> >> >> >> component
>>> >>> >> >> >> > state.
>>> >>> >> >> >> >
>>> >>> >> >> >> > On Mon, Nov 29, 2010 at 4:56 PM, Igor Vaynberg <
>>> >>> >> >> igor.vaynb...@gmail.com
>>> >>> >> >> >> >wrote:
>>> >>> >> >> >> >
>>> >>> >> >> >> >> ive run into plenty of weird problems with overrides, but
>>> maybe
>>> >>> >> >> >> >> because this was in a high concurrency app where data
>>> changed
>>> >>> >> >> >> >> frequently. the problems arise from the fact that the value
>>> >>> >> returned
>>> >>> >> >> >> >> from isvisible() can change while we are doing traversals,
>>> etc.
>>> >>> >> >> >> >>
>>> >>> >> >> >> >> eg we run a traversal for all visible components and put
>>> them
>>> >>> in a
>>> >>> >> >> >> >> list. later we iterate over the list and try to render
>>> these
>>> >>> >> >> >> >> components. the render function also checks their
>>> visibility
>>> >>> and
>>> >>> >> if
>>> >>> >> >> >> >> they are no longer visible it throws an exception.
>>> >>> >> >> >> >>
>>> >>> >> >> >> >> if isvisible() override depends on some external factor
>>> like
>>> >>> the
>>> >>> >> >> >> >> database there is a small window where the value can change
>>> and
>>> >>> >> now
>>> >>> >> >> >> >> you can have a weird exception: such as "tried to invoke a
>>> >>> >> listener
>>> >>> >> >> on
>>> >>> >> >> >> >> a component that is not visible or not enabled". these are
>>> very
>>> >>> >> >> >> >> intermittent and damn near impossible to reproduce.
>>> >>> >> >> >> >>
>>> >>> >> >> >> >> another problem is per
Re: overriding isVisible bad?
On Tue, Nov 30, 2010 at 12:55 AM, Eelco Hillenius wrote: > On Mon, Nov 29, 2010 at 11:51 PM, Juergen Donnerstag > wrote: >> I'm curious. Which ideas would you steal from SiteBricks and JaxRS? There are also many interesting ideas in Apache Sling. How it uses OSGi for modularization, comes with a 'launchpad' and has a pretty flexible bootstrapping mechanism and looks like a good power-to-weight ratio.
Re: overriding isVisible bad?
On Mon, Nov 29, 2010 at 11:51 PM, Juergen Donnerstag wrote: > I'm curious. Which ideas would you steal from SiteBricks and JaxRS? I think SiteBricks strikes a nice balance between Wicket's and Tapestry's (or JSF's/ ASP.NET's) programming models. I like that it allows *some* logic in the templates - but which is checked early - and code-behind constructs (which can save you lots of lines of code), that it supports DI natively, and some things like how URLs are mapped and e.g. how custom component names are defined are neat. I do have doubts how well this would scale for complexity, which imho is the problem with frameworks like Tapestry also. Relatively simple code is easy enough to do and often looks more elegant (shorter at least) than Wicket, but things can get messy quickly, especially when dealing with deeper widget trees and projects using multiple component libraries. I like the consistency that Wicket gives you, but I would try to make a few common things a little bit less verbose. Wrt JaxRs, I just like that framework. I like how easy it is (with Jersey at least) to pass around objects that under the covers are converted from/ to JSON, I like how easy it is to map method arguments to request or POST parameters, etc. In short, I'd try to make better use of annotations but keep it clean, straightforward and optional, and I'd try to have a more DI centric approach (for instance, I really like how you can let Jersey just pass in context objects in a method if you need it). Eelco
Re: overriding isVisible bad?
On Mon, Nov 29, 2010 at 7:45 PM, richard emberson wrote: > If wicket was going to be coded over again, would you make > isEnabled and/or isVisible final methods? If *I* would do it, I'd probably write it for Scala and lean more heavily on functions rather than mutable state. I'd also steal a few ideas from other frameworks like SiteBricks and JaxRS, have better 'native' JavaScript support (but definitively not going the GWT route), make choosing between stateful and stateless more explicit and up-front, support client-side state (but not like JSF or ASP.NET do it), etc. I gathered plenty of ideas of how I'd do a new framework, but I'm not even going to attempt that anyway :-) After having done a few projects with alternatives (GWT, pure JS/ JaxRS), I'm totally sold on Wicket again. It's not a perfect framework, but sure beats the hell out of most other frameworks when it comes to productivity and maintainability. :-) Eelco
Re: overriding isVisible bad?
> it has nothing to do with requiring a function to be set. the problem > is that the function is free to change its mind at any moment, but we > rely on it returning the same value during some fixed periods of time. > if we truly want to support isvisible() we would need to cache/memoize > the value for the period we assume it to be constant. Yes, that's what I'm saying. > but, defining > these caching regions is very difficult, and maintaining them as we > work on core we be even more difficult still. I don't think it would be that difficult, but certainly not something worth doing at this stage. Eelco
Re: overriding isVisible bad?
> ive run into plenty of weird problems with overrides, but maybe > because this was in a high concurrency app where data changed > frequently. the problems arise from the fact that the value returned > from isvisible() can change while we are doing traversals, etc. Hmmm, yeah, I can see how that could be a problem. Still, in general I find overrides to be easier to backtrack because it is a simple function. Wicket's mutable programming model is both a boon and a bane :-) Maybe a good solution would be to require a function to be set (would obviously work better in say Scala than Java at this point) that is called during the rendering preparation and which result is put in a temporary storage as the sole way of doing this. I'd personally like that better than supporting setVisible. Eelco
Re: overriding isVisible bad?
> Well, in the past, the "canned" answer was "override > isEnabled/isVisible." Changing that paradigm and doing a complete 180 > is troubling. I don't think that's the case though. We've had many discussions on this list (and in private even), and we've always felt uneasy about supporting two rather than one way of achieving the same thing. Ultimately we decided to support both, but there have been several times where we were near making isVisible final. Eelco
Re: overriding isVisible bad?
To expand, unless I'm missing something (new?), things are really only problematic when both the mutable value and the override are mixed. In a way, I think that using the override is 'more pure', as it's a simple function that is executed when needed, whereas mutable state can be harder to deal with when trying to figure out how it got to be in that state. So, sorry Igor, but we disagree on this one. Eelco On Mon, Nov 29, 2010 at 10:13 AM, Eelco Hillenius wrote: > Niether is evil. It has potential pitfalls, which you should just be > aware of. We use such overrides all over the place and never have > problems with them either. :-) Avoiding it is safer, but also more > verbose (in 1.3.x at least). > > Eelco > > On Mon, Nov 29, 2010 at 9:49 AM, Igor Vaynberg > wrote: >> On Mon, Nov 29, 2010 at 9:35 AM, Sven Meier wrote: >>> Hi Douglas, >>> >>> WICKET-3171 describes a problematic case, where visibility of a >>> component changes while its form is being processed. >>> In our projects we're overriding isVisible() where appropriate and never >>> encountered a similar problem. >>> >>> I'd say WICKET-3171 is the rare 5% usecase. What's next, is overriding >>> isEnabled() going to be declared evil too? ;) >> >> yes >> >> -igor >> >>> >>> Sven >>> >>> On Mon, 2010-11-29 at 11:22 -0600, Douglas Ferguson wrote: >>> >>>> Can you explain why? We have done this all over the place. >>>> >>>> D/ >>>> >>>> On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: >>>> >>>> > The recommended way since a few 1.4 releases is to override onConfigure() >>>> > and call setVisible(true|false) depending on your conditions. >>>> > >>>> > On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson < >>>> > doug...@douglasferguson.us> wrote: >>>> > >>>> >> Igor posted a comment to this bug saying that overriding isVisible() is >>>> >> "evil" >>>> >> >>>> >> https://issues.apache.org/jira/browse/WICKET-3171 >>>> >> >>>> >> I was surprised by this and am curious to hear more. >>>> >> >>>> >> D/ >>>> >>> >>> >>> >> >
Re: overriding isVisible bad?
Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Eelco On Mon, Nov 29, 2010 at 9:49 AM, Igor Vaynberg wrote: > On Mon, Nov 29, 2010 at 9:35 AM, Sven Meier wrote: >> Hi Douglas, >> >> WICKET-3171 describes a problematic case, where visibility of a >> component changes while its form is being processed. >> In our projects we're overriding isVisible() where appropriate and never >> encountered a similar problem. >> >> I'd say WICKET-3171 is the rare 5% usecase. What's next, is overriding >> isEnabled() going to be declared evil too? ;) > > yes > > -igor > >> >> Sven >> >> On Mon, 2010-11-29 at 11:22 -0600, Douglas Ferguson wrote: >> >>> Can you explain why? We have done this all over the place. >>> >>> D/ >>> >>> On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: >>> >>> > The recommended way since a few 1.4 releases is to override onConfigure() >>> > and call setVisible(true|false) depending on your conditions. >>> > >>> > On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson < >>> > doug...@douglasferguson.us> wrote: >>> > >>> >> Igor posted a comment to this bug saying that overriding isVisible() is >>> >> "evil" >>> >> >>> >> https://issues.apache.org/jira/browse/WICKET-3171 >>> >> >>> >> I was surprised by this and am curious to hear more. >>> >> >>> >> D/ >>> >> >> >> >
Re: Git migration for stuff
On Thu, Mar 4, 2010 at 1:38 PM, Johan Compagner wrote: > no integration needed? > How do you compare (with the repository version or another version, branch)? > > how do you check what is all incoming? (synchronize with working sets) > History view: getting a revision, comparing 2 revisions, getting the > contents? > Annotations? > > I use above points daily. I cant do without it. >From my experience, you can do this stuff with the Git plugin for Eclipse. Eelco
Re: Wicket Component Overview
> hmm.. no image attached.. You can't send attachments to the mailing list (true for most public mailing lists); Apache drops 'em. Eelco
Re: True?
Hey Matt, if you're reading with us, maybe you can explain the scalability issues you ran into? How many concurrent sessions did you need to be able to handle? What did you try when optimizing? Cheers, Eelco On Wed, Oct 14, 2009 at 2:26 PM, Eelco Hillenius wrote: >> Don't know anything about it. >> >> Anyone else? > > Not me. I don't think anyone of the core team was hired for an > optimization job or we'd surely have had a discussion about it. > > Eelco >
Re: True?
> Don't know anything about it. > > Anyone else? Not me. I don't think anyone of the core team was hired for an optimization job or we'd surely have had a discussion about it. Eelco
Re: OT: Is IModel an empty interface?
> I must admit that I don't get the whole detachable stuff in Wicket. I'm used > to think in horizontal tiers > where one tier does all the caching "automagically" (e.g. 2nd level cache in > JPA/Hibernate) and the > other tiers don't know about that fact. What models in Wicket can achieve is that data is compressed between requests. This is important because Wicket stores component trees in memory/ on your disk between requests. Obviously the smaller the better there. Detaching is also important when you work with objects as your models that might hold on to resources (e.g. session in Hibernate); detaching lets those objects frees up those resources after a request. Eelco
Re: [wicket 1.5] url handling refactor preview
Why not use toRequestHandler/ toHandler and toUrl in RequestMapper? Eelco On Tue, Oct 6, 2009 at 9:53 AM, Eelco Hillenius wrote: > Looks like an overall improvement. Definitively reduces the spaghetti > a bit. Not crazy about getCompatibilityScore though. I understand it's > purpose and maybe it's the best solution, but it looks like a crutch. > > Eelco > > On Tue, Oct 6, 2009 at 8:13 AM, Igor Vaynberg wrote: >> ahha, here is something we need to change. we should have a >> mountedmapper that allows one to mount a requesthandler rather then a >> page. the user should not go as far as having to implement >> requestablepage, there are a lot of extraneous methods there if all >> you want to do is handle the request yourself. >> >> -igor >> >> On Tue, Oct 6, 2009 at 3:08 AM, Daniel Stoch wrote: >>> The great thing for me is that I'll be able to mounting something that >>> just implements RequestablePage interface, not only a Page class >>> descendants (if I've read this code correctly :)). It allows to handle >>> navigation more flexible and it allows to avoid creating hard to >>> maintain page class hierarchies. >>> >>> -- >>> Daniel >>> >> >
Re: [wicket 1.5] url handling refactor preview
Looks like an overall improvement. Definitively reduces the spaghetti a bit. Not crazy about getCompatibilityScore though. I understand it's purpose and maybe it's the best solution, but it looks like a crutch. Eelco On Tue, Oct 6, 2009 at 8:13 AM, Igor Vaynberg wrote: > ahha, here is something we need to change. we should have a > mountedmapper that allows one to mount a requesthandler rather then a > page. the user should not go as far as having to implement > requestablepage, there are a lot of extraneous methods there if all > you want to do is handle the request yourself. > > -igor > > On Tue, Oct 6, 2009 at 3:08 AM, Daniel Stoch wrote: >> The great thing for me is that I'll be able to mounting something that >> just implements RequestablePage interface, not only a Page class >> descendants (if I've read this code correctly :)). It allows to handle >> navigation more flexible and it allows to avoid creating hard to >> maintain page class hierarchies. >> >> -- >> Daniel >> >
Re: OT: Is IModel an empty interface?
> yes. too bad you cant proxy final classes or final methods... :) And only interfaces unless you do byte code engineering. Eelco
Re: taking the I out of Interface
> AGAINST (3 binding / approximately 9 non-binding): > Martijn Dashorst > Jeremy Thomerson > Eelco Hillenius Like I said, you don't have to count my vote as a binding one. So it's a draw then. Eelco
Re: taking the I out of Interface
> And good, consistent naming of classes and > other identifiers is a non-trivial aspect of good design and coding, > especially in publicly used parts of frameworks True, but imho that has more to do with choosing names that communicate what things do well, not so much whether there are certain prefixes or postfxes. > understanding from the original posts on this thread is that the technique > described to incrementally get rid of I* interfaces by deprecating and > eventually removing "offending" I* interfaces is exactly the right way to > make such an improvement with minimal disruption. There's one thing I hate more than making unnecessary API breaks, and that is accompanying them with annoying deprecation warnings :-) Eelco
Re: taking the I out of Interface
> On Mon, Oct 5, 2009 at 12:14 AM, Eelco Hillenius > wrote: >> I never liked the code format we're using (curly braces on the >> next line), but heck even though Wicket is the only project I've ever >> worked on (as far as I can remember) where I used that > > It's in the Topicus code conventions, so you've been programming (and > AFAIR advocating) the curly brace on the next line ;-) Ah yes, it slowly comes back to me... another case of where I let the team's preferences override my own. I've *never* preferred the curly brace on the next line. Eelco
Re: taking the I out of Interface
I just want to get off my chest that it is amazing to me we all make such a big deal out of that "I" being there. It's been there forever, and with previous discussions we always concluded to leave it in there. I never liked the code format we're using (curly braces on the next line), but heck even though Wicket is the only project I've ever worked on (as far as I can remember) where I used that, it's not something to lose sleep over. Same with the I, I like it, but I'd be fine with any alternative. More problematic to me is that we're going to break a lot of code - including code printed on dead trees - over it while there is absolutely no benefit other than a superficial one, and as you can see from the replies in the thread, it's not even universally thought of as better. And I think that some are a bit too quick to trivialize that. Breaks, even little ones are annoying and imho only justifyable when there's a clear benefit to doing that. But this is plain nitpicking to me. I wouldn't give this a blocking vote, even if I had been more active in the last year, but I'd like to ask everyone to not take even little API breaks too lightly. Eelco
Re: taking the I out of Interface
-1 Breaks compatibility for nothing other than a superficial 'improvement'. Also, I do see the I used in other projects, and actually like the convention (a whole lot better than using AbstractFoo and Fooimpl fwiw). Eelco On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg wrote: > is it perhaps time to take the I out of our interface names? wicket > has been the only project i have ever worked on/used that follows this > convention, is it time for a change? > > this is not meant as a flamewar about which convention is teh > aw3s0m3st, simply a discussion of whether or not we should switch. > > -igor >
Re: Ideas? SerializableChecker - to flag warning on debug bar
You'd have to rewrite the guts of SerializableChecker a bit, e.g. to
send a message to observers rather than just throwing a
WicketNotSerializableException. A default observer can throw that for
instance, but you could couple other observers, for instance one that
calls addError. One problem I expect is that I think these exceptions
are not necessarily thrown in the same thread , in which case this
wouldn't be very helpful. Unless you add flash messages (through the
session, will be displayed next request regardless of the page), but I
think that would be confusing rather than helpful.
I guess if you rewrite enough you can always do this check in the same
request, in which case displaying in a bar would be neat. Probably
best to write that from scratch then (well reusing the checker, but do
the serializing check e.g. at the end of a request cycle.
Eelco
On Sat, Apr 4, 2009 at 10:42 AM, Jeremy Thomerson
wrote:
> The debug bar that I am working on now can have someone call
> addError("MESSAGE") on it, and it will change to a red background color.
> When I'm finished, it will also display the errors in an overlay.
>
> I would like the SerializableChecker to be able to signify that there is an
> error on the debug bar. But I'm not familiar enough with the serialization
> guts to start digging around in there just before a (possibly) final release
> candidate. So, what suggestions do you have as to how I can accomplish
> this? Basically, I see the following two options thus far:
>
> 1. when the SerializableChecker runs, if it encounters an error, it
> sticks the error somewhere that is available to the debug bar contributor
> 1. problem I see: this is probably run way too late
> 2. another problem: possibly introduces tight coupling
> 2. the debug bar contributor somehow triggers serialization early or
> mimics serialization to see if it is indeed serializable
> 1. problem: is serializing this early (during render) even valid?
> probably not
> 2. problem: serialization check would be done an extra time.
>
> Any ideas?
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
Re: [VOTE] Release Apache Wicket 1.4 Release Candidate 1
+1 Eelco
Re: Wicket-stuff teamcity
If someone would pick up the initiative, it might be an option to move to google code or some other hosting party. Eelco On Thu, Sep 18, 2008 at 2:28 AM, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: > I did it here: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2117575&group_id=1&atid=21 > > Johan Compagner wrote: >> >> i think that is already done before but sending more emails to them cant >> hurt at all >> >> >> On Thu, Sep 18, 2008 at 10:51 AM, Nino Saturnino Martinez Vazquez Wael < >> [EMAIL PROTECTED]> wrote: >> >> >>> >>> Has anyone written them... Otherwise i'll do it.. >>> >>> >>> Johan Compagner wrote: >>> >>> i think it is sourceforge that thinks we are bombarding them or something like that if only we could make it clear that it is a build server and that that ip is fine johan On Thu, Sep 18, 2008 at 10:32 AM, Nino Saturnino Martinez Vazquez Wael < [EMAIL PROTECTED]> wrote: > > Yeah it's a problem, Im having trouble with it too.. Im not sure what > can > be done or if anyone are on it? > > > Pointbreak wrote: > > > > >> >> As always, it doesn't work. I think every time I look at it (which is >> quit often) it gives errors because of the vcs connection. I would >> like >> it to build a new version of contrib-tinymce, but it doesn't even see >> that that has new sources, because it has build against the old >> sources >> becuase of the vcs version, and now thinks that there are no changes >> since the last build. >> >> Is anybody out there that can fix the teamcity issues? (BTW I read >> before that it has to do with firewall of sourceforge that blocks >> teamcity because it thinks it gets attacked. Maybe it is poaaiblwe to >> let teamcity poll less often for changes?). >> >> >> >> >> > > -- > -Wicket for love > > Nino Martinez Wael > Java Specialist @ Jayway DK > http://www.jayway.dk > +45 2936 7684 > > > > > >>> >>> -- >>> -Wicket for love >>> >>> Nino Martinez Wael >>> Java Specialist @ Jayway DK >>> http://www.jayway.dk >>> +45 2936 7684 >>> >>> >>> >> >> > > -- > -Wicket for love > > Nino Martinez Wael > Java Specialist @ Jayway DK > http://www.jayway.dk > +45 2936 7684 > >
Re: security article on TSS (partly covering wicket)
> its *not* my opinion - I just read the article and thought you might want to > know about it. I mean, beside that, it seems as wicket is very secure in > comparision to the other frameworks mentioned there - Honestly, I dont know > why this harsh reactions (other mails) came. Thanks for sharing. I didn't get the impression that people were harsh towards you, but if they were, I guess that's the danger of being the messenger ;-) Eelco
Re: security article on TSS (partly covering wicket)
On Wed, Jul 30, 2008 at 3:48 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Yeah, that's a quite annoying way from them to sell their product. > More than half of it isn't even really related to web frameworks, but > to how people use them. Injection flaws for instance... duh. I actually think that Wicket has facilities to avoid all of the potential issues listed there. Reply of you think any of them is actually something Wicket should do better on. Of course, users are also responsible for thinking about the consequences of their choices. Wicket is a framework to help you be more productive, not a magic wand. Eelco
Re: security article on TSS (partly covering wicket)
Yeah, that's a quite annoying way from them to sell their product. More than half of it isn't even really related to web frameworks, but to how people use them. Injection flaws for instance... duh. Eelco On Wed, Jul 30, 2008 at 2:53 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > That article is ridiculous. I really want to see what kind of hidden > field vulnerability wicket has. We don't put anything to hidden field > we wouldn't put in the URL. > > -Matej > > On Wed, Jul 30, 2008 at 11:49 PM, Martijn Dashorst > <[EMAIL PROTECTED]> wrote: >> How is HiddenField insecure in your opinion? >> >> Martijn >> >> On Wed, Jul 30, 2008 at 10:59 PM, Korbinian Bachl - privat >> <[EMAIL PROTECTED]> wrote: >>> HI, >>> >>> under >>> http://www.theserverside.com/tt/articles/article.tss?l=AreJavaWebApplicationsSecure >>> is an article covering java WebApps & security; On part 2 it also looks at >>> webframeworks for java including wicket 1.3.x - it mentions >>> >>> "Wicket has only one component (HiddenField) vulnerable to integrity >>> attacks." >>> >>> maybe this gap could be closed? Also the rest seems aso quite interesting. >>> >>> Best, >>> >>> Korbinian >>> >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.4 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> >
Re: Terracotta integration
On Wed, Jul 9, 2008 at 7:13 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i dont see a reason for this to go into wicket. it is a terracotta > specific optimization and there is already a terracotta-wicket module > right? And that would be easier for users too I would think: one less dependency to worry about. Eelco
Re: Terracotta integration
On Thu, Jul 3, 2008 at 11:37 AM, Ari Zilka <[EMAIL PROTECTED]> wrote: > This is the agreed upon approach mimicking the DiskPageStore. No? Well, the DiskPageStore takes care of storing pages, but by itself would never be transferred across a cluster. So making it IClusterable wouldn't make sense. Eelco
Re: Terracotta integration
> One extra note, I had to manually instrument > org.apache.wicket.protocol.http.pagestore.AbstractPageStore Why do page stores need to be serializable though? And did you attach your code to a JIRA issue (and which)? Eelco
Re: Terracotta integration
> TC because you can then share more than just Wicket state. You can do > Hibernate 2nd level cache, EHCache, and your own POJOs, all in the same > impl. That is definitively a big pro for me. A one stop shop solution for your clustering needs :-). And it comes with tools, source and professional support options. Eelco
Re: [vote] release wicket-1.3.4
[ x ] release wicket 1.3.4 [ ] don't release wicket 1.3.4, because... Eelco
Re: wicket generics
On Tue, Jun 17, 2008 at 6:01 PM, Bruno Borges <[EMAIL PROTECTED]> wrote: > Isn't a good idea to just remove Component.getModelObject() and others > HelpfulMethods ? > Wouldn't this reduce this generic problem thing? Well, we'd have to have something to replace it, particularly for detaching models - that should be done automatically and safely, as it can be dangerous to not detach models -, and for components such as form components that naturally do work with models. And I'd love to go through the code base for 1.5 to remove all the deprecations and redundancy. Eelco
Re: Wicket 1.4: getApplication final?
> This might not be Wicket's intended way to use getApplication But is > there a real serious reason to make getApplication final? It's one of these methods we actually wanted to get rid off in the long term. It would be best to have just one way to get the application: MyApplication.get(). Same goes for session and request cycle. > Which problem so I run into when I use this pattern? Well, not a problem per se, but it's just in general not good to have multiple ways to do the same thing in an API. Eelco
Re: Wicket training
> Beyond that, ask your local freelancer you trust. LOL, "your local freelancer". I'm gonna remember that line! Eelco
Re: Quit IBM NZ and work on OSS full time?
> If you don't mind my asking - where are you from? And btw, you should have > just come straight to the South Island of NZ, that's much nicer than Ozi ;) I'm Dutch, but live in the US (Seattle) now. My Australian adventures where a life time ago :-) And NZ is definitively high on my list, though it might be a few years before I actually make it there. > Hmm, yes I plan to put some more time into the blog and I'm going to be > giving my talk on Scala next week at the Auckland JUG which I'm quite > looking forward to - I'm on after Ben from Spring :) NIce. Maybe you can open up a nice combining Scala with Wicket. Some people have been experimenting in that direction already (see http://technically.us/code for instance). > That's the cool thing about OSS eh? You can telecommute from anywhere in the > world! Yep. But you might want to get paid for it as well, which can be a bit harder. Most people do open source in their spare time, or as part of the projects they work if they are consumers of the same project. Eelco
Re: Quit IBM NZ and work on OSS full time?
> Let's say, hypothetically, I to quit my job at IBM NZ and work on a couple of > open source projects full time, Wicket being one of them and Maven another, > while I travelled around the world... > We have a tradition in NZ called and OE - > http://en.wikipedia.org/wiki/Overseas_experience I tried that in Australia. Been there for about 5 months, 3 of which I lived in Melbourne trying to get a job. I didn't succeed in getting one because I was ill prepared. The market was bad at that time, I didn't have that much experience yet, and I didn't have much of a position for temp jobs. Oh, and I didn't have a laptop either at that time. I did however have a good time, and don't feel sorry for trying :-) I think the way to do it is to start out as an independent contractor and go from there. Build up your network, and when the chance is there, do gigs abroad. These times where open source is huge, everyone hooked up on the internet and stuff makes things easier as well. It would be a good idea to start a project that displays your skills (see e.g. Wicket RAD/ webbeans, databinder or any of the wicket-stuff projects), work on your blog, see if you can give talks, etc. FWIW, if I were an independent (and single!) contractor, I'd try to divide my time between awesome beaches and the coolest cities around the world. But that's up to you :-) Eelco
Re: [VOTE] Release Apache Wicket 1.4 M2 (second attempt)
[ x ] +1 Release Apache Wicket 1.4 Milestone 2 [ ] -1 Don't release, because... Eelco
when do we get rid of our deprecations?
Hey guys, I noticed that we still have a bunch of deprecations lying around. When do you think we should remove those? Eelco
Re: Quote replacement in document prologue?
Looks good to me. Maybe create a JIRA issue as well?
Eelco
On Wed, May 21, 2008 at 6:22 AM, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> Commit or not?
>
> Index: src/main/java/org/apache/wicket/Page.java
> ===
> --- src/main/java/org/apache/wicket/Page.java (revision 658674)
> +++ src/main/java/org/apache/wicket/Page.java (working copy)
> @@ -1372,9 +1372,13 @@
>if ((markupStream != null) &&
> (markupStream.getXmlDeclaration() != null) &&
>
> (application.getMarkupSettings().getStripXmlDeclarationFromOutput()
> == false))
>{
> - response.write(" + // Gwyn - Wed, 21 May 2008 12:23:41
> + // If the xml declaration in the markup used
> double-quotes, use
> them in the output too
> + // Whether it should be or not, sometimes it's
> significant...
> + char quoteChar =
> (markupStream.getXmlDeclaration().indexOf('\"')
> == -1) ? '\'' : '\"';
> + response.write(" quoteChar +
> " encoding=" + quoteChar);
>response.write(encoding);
> - response.write("'?>");
> + response.write(quoteChar + "?>");
>}
>
>// Set response locale from session locale
>
>
>
> -- Forwarded message --
> From: Gwyn Evans <[EMAIL PROTECTED]>
> Date: Wed, May 21, 2008 at 12:23 AM
> Subject: Re: Quote replacement in document prologue?
> To: [EMAIL PROTECTED]
>
>
> Ah - org.apache.wicket.Page#configureResponse doesn't take account of
> the specified template, just uses it's hard-coded one... Tomorrow...
>
> /Gwyn
>
> On Wed, May 21, 2008 at 12:10 AM, Gwyn Evans <[EMAIL PROTECTED]> wrote:
>> Just noticed that even though I specify a prologue as:
>>
>> it gets delivered as:
>>
>>
>> Anyone able to point me to where this is happening, as the particular
>> document spec variant I'm trying to work to here requires the
>> former...
>>
>> /Gwyn
>>
>
Re: Bookmarkable / Stateless form submit bug (eelco - need your advice)
> thats back from the day when eelco used to go around and claim all > files that did not have @author for himself so he could impress girls. Yeah. Too bad it didn't work. I found out that switching deodorants worked better. Eelco
Re: Bookmarkable / Stateless form submit bug (eelco - need your advice)
> Basically, it depends on what Eelco was thinking when he originally wrote > this. I have no idea, it's quite a while ago :-) Oh, and are you sure I wrote it to start with? There are plenty of files with my author tag that weren't written by me (or only the initial versions)... Eelco
Re: [vote] accept kitten-captcha into Apache Wicket
[ x ] yes, accept kitten-captcha into Wicket [ ] no, Eelco
Re: [wicket-threadtest] App1Test3 fails with expired pages with more than 3 iterations
> App1Test3 fails with expired pages with more than 3 iterations. > the # of iterations is set to 5. when manually setting it to 3, no errors. > but with anything more than 3 iterations, it fails. > > can somebody with more insight of wicket-threadtest take a look at this? I won't have time for it this week, but it should be an indication that there is a problem with threading in Wicket. Of course, there's always the possibility that the test is wrong :-) Eelco
Re: Kitten auth software grant
> I have no objections to putting it in extensions, but throwing it out > to wicket stuff seems like throwing away a lot of my, Jonathan's and > Ian's time. I'm fine with putting it in extensions, just as long as a few people are OK with fixing bugs if they come up. Eelco
Re: Kitten auth software grant
On Wed, May 14, 2008 at 12:01 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > no, igor doesnt want to do the rest. igor has enough going on at the > moment to keep him busy for several lifetimes. LOL
Re: Kitten auth software grant
On Tue, May 13, 2008 at 1:10 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > i will not promise to maintain this. > > Ok. So unless someone else of the committers wants to take > responsibility for at least the first few months, I think it should > start as a wicket-stuff project. And if it turns out it is relatively > bug (and feature request) free, we can consider to migrate it. Actually, the minis project sounds perfect for this to me. Eelco
Re: Kitten auth software grant
> i will not promise to maintain this. Ok. So unless someone else of the committers wants to take responsibility for at least the first few months, I think it should start as a wicket-stuff project. And if it turns out it is relatively bug (and feature request) free, we can consider to migrate it. Cheers, Eelco
Re: rules for projects at wicket extensions/stuff/etc
Well, first of all, there aren't really any fast and hard rules when it comes to wicket-stuff projects. I'd call them guidelines of even suggestions. :-) > Wicket stuff minis= small project / one behavior or something like that.. Yeah. I can't really speak for Igor (who set up the project if I'm correct), but I believe the idea behind it is meant for neat components and behaviors that are too small for a separate project. Kind of like wicket-extensions but for wicket-stuff. > Wicket stuff seperate project = non core commiter and/or? > Wicket stuff in general = non apache compatible license. * Projects for non committers * Projects that have external dependencies from what we already use for the core projects (whether the licenses are compatible or not... we obviously would prefer licenses to always be compatible). * Projects that need time to mature before we'd consider them for core projects. The Spring integration projects for instance started out like that. * Projects that we (or anyone else for that matter) like to share without too much pressure on maintaining them. Of course, everyone should try to at least make a basic effort to maintain whatever they committed, but the pressure for doing that is more urgent (at least imho) for core projects. Eelco
Re: Kitten auth software grant
[ x ] extensions if it doesn't have any external dependencies and Jonathan plans to maintain the project. [ x ] separate project next to wicket-extensions/spring/ioc/velocity/etc if it does have external dependencies and Jonathan plans to maintain the project. [ x ] wicket stuff project if Jonathan does not plan to maintain the project. :-) Eelco
Re: PropertyResolver redesign
On Thu, May 8, 2008 at 3:46 PM, Miguel Munoz <[EMAIL PROTECTED]> wrote: > > I'm not using PropertyResolver. I said so in a previous post. My point was > that you shouldn't assume I don't know what I'm doing. Contrary to your > previous post, there are valid reasons for sorting the data after retrieving > it from the database. Sure, I agree; there can be valid reasons for in memory sorting. And I must have missed that you are not using property resolver... it's been a long thread :-) Eelco
Re: PropertyResolver redesign
> While sorting is most often done by the database, I don't think Wicket's > design should assume this is where sorting will be done. Wicket should leave > that up to the application developers. Sure, we don't assume that. However, we do assume that you're not using models for massive sorting either. It's not their purpose to support that, and PropertyModels in particular are written as convenience over the cost of a slight performance penalty. That penalty gets big with sufficient large data sets, but it is unrealistic to have such large datasets in the first place (because that won't render in browsers, and will be seriously bad for you bandwidth usage). Eelco
Re: Patch for wickestuff-lightbox
On Thu, May 8, 2008 at 3:48 AM, Maurice Marrink <[EMAIL PROTECTED]> wrote: > You could send a mail to the user list or contact the developers for > wicketstuff-lightbox directly, if you can find there email somewhere > :) Or give us your sourceforge name so that we can add you and you can apply yourself. After you at least tried to contact the original developers of course :-) Eelco
Re: PropertyResolver redesign
> It's very easy to say this, but the way Wicket is designed, we use property > names all over the place, so this forces us to use reflection when we sort. There's nothing in Wicket's design that points to using property models though. (Compound)PropertyModels are very convenient to use, and that's why they show up at many examples, but we've been telling the community for years that you have to be aware of a) the fact that it breaks static typing and b) there is a slight performance impact. Now, I don't think the performance impact is a big deal for most people, as the bottlenecks are usually somewhere else (database access and stuff). I know for sure it hasn't been a problem for any of the projects I worked on with Wicket. But if it is for you, the best way is to not use models that use introspection. There's nothing wrong or anti-Wicket about using such models. It will mean that you'll get more LOC, but it's good for performance, and as your models won't break static typing, it'll be easier when it comes to refactoring and code navigation (like finding out where certain objects are accessed). Eelco
Re: PropertyResolver redesign
> Yes, I hoped I was making it clear that this wasn't a real-world test, it was > a stress test to exaggerate the inefficiencies. This makes them easier to > measure. Stress tests have their place. Yeah, I got that idea :-) However, > While my code clearly wouldn't ever > see a case like this, we would see something similar: When many users are on > line, many threads will be sorting many smaller datasets. In this case, I > still want the sort to run as efficiently as possible. This is why I was > measuring the efficiency of the PropertyResolver, and why I still feel > there's a faster way to do this. Fair enough. It's certainly something to keep in mind with any flexible/ introspection based thing you do that there might be a cost. If your scale is large enough, it might be a problem. That said, I (and as is clear from that thread, 'we') don't think the efficiency of PropertyResolver is a problem, and we have in fact optimized it as much as we can within what we feel are reasonable limits (so without losing flexibility). > That said, I have accepted the Wicket team's claim that we shouldn't use > PropertyResolver in our own code. I have developed my own resolver, which, > as I expected, runs much more efficiently. (We tried OGNL and MVEL, but > neither was really suitable.) Funny enough, we started out using OGNL in early Wicket versions, but decided to create our own resolver so that we could optimize it for just our cases. What you're doing is another optimization for your situation. :-) One thing I'm wondering though is whether your more efficient version still uses introspection? If that is the case, we would love to learn what you did to make it run more efficiently. And - if you use introspection - ... why use introspection when you need it to run very efficiently (just write it out directly will run much faster). Eelco
Re: [DISCUSS] wicket-aspects?
> Again, this would be an optional module of course. Anything optional is fine, especially if it can be developed independently (say as a wicket-stuff project). > And, adding > AspectJ to the build process in maven is simple. It's just another > build plugin. Yeah, but we would also need to setup our IDEs to support this. And learn how to use AspectJ. Fine if it is optional, but a big deal if it were to be part of the/ a core project (which I initially thought you suggested). Eelco
Re: [DISCUSS] wicket-aspects?
On Fri, May 2, 2008 at 8:45 AM, James Carman <[EMAIL PROTECTED]> wrote: > When I was reading the discussion about session.dirty > > (http://www.nabble.com/What-is-session.dirty%28%29-for--td17021032.html#a17021032) > on the users list, I came up with an idea. Perhaps we could come up > with a set of reusable AspectJ aspects for these sort of cases. For > this particular case, we'd introduce an annotation like @SessionData > or something and create an aspect that says "anytime a setter is > called on a class with the @SessionData annotation, we call > session.dirty()". Now, this would be a separate subproject of Wicket > so that it's not required or anything. Then, if folks wanted to, they > could weave that into their own classes to make sure that they're > taking care of their session data properly (in a cluster). I can > imagine that we might be able to do the on-before-first-render stuff > with aspects, too. Again, the aspects would be optional, kind of like > how the spring-aspects (for @Configurable and @Transactional) are > optional, but very useful. Anything AOP would complicate our building process and would mean additional dependencies. I wouldn't be crazy about that. Also, the ideal case would be that you could just extend the session and provide your properties without having to even know about the dirty call in setters. There should be simpler solutions than introducing AOP and/ or annotations. Can't we create create a proxy object for the session right after it is created that adds calling dirty() to the setters it finds? Maybe optional? Eelco
Re: PropertyResolver redesign
> The dataset I was sorting on was generated specifically to test the speed of > different comparators, and had a dataset of 100,000 elements, and I was > sorting using the standard sort method from the collections package, > accessed from Arrays.sort(). However, I now have data that times individual > calls of the Comparator's compare() method: You would never load a data set of 100,000 elements (or even a 1,000 for that matter) in Wicket models, simply because you wouldn't display that many components (your browser probably wouldn't be able to handle that for instance). Furthermore, even if you would find the need to do such sorting in-memory using Java, you would do that upfront, before arriving at the user interface layer. Eelco
Re: Build server - what do we do?
On Sat, May 3, 2008 at 7:59 AM, Jon Steelman <[EMAIL PROTECTED]> wrote: > You core commiter guys use TeamCity but I had the impression you guy use > Eclipse and not IDEA? We don't have a policy of any kind for what IDE to use :-) We have (had) at least two team members who use IDEA and quite a few active users who prefer it. And we have a bunch of very active users who use NetBeans as well. Like Igor said, we like to pick the best of breed, and are not fundamental about using open source. IntelliJ is a great company that keeps pushing innovation. And it's good there is competition of several IDEs so that they keep on top of their game. Eelco
Re: [vote] update servlet-api dependency to 2.5
[ ] servletapi 2.5 ftw! [ x ] servletapi 2.4 ftw! [ ] servletapi 2.3 ftw! Eelco
Re: [vote] Release Apache Wicket 1.3.3
[ x ] Release Apache Wicket 1.3.3 Eelco
Re: planning for Wicket 3.0
On Wed, Apr 2, 2008 at 10:02 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: > A joke?! I already made Component extends JComponent! Does it mean I > won't get to commit that? How about letting it extend from JCompagner instead? It'll be closer to the creative source. Eelco
Re: planning for Wicket 3.0
> I thought the move to Scala was a pretty intriguing idea. It > was the logic in markup and the integration with Swing that > had me worried. Yeah, I like Scala, or at least parts of it. And the joke had to be somewhat believable :-) Eelco
Re: planning for Wicket 3.0
In case you didn't get it: april fools'! :-) On Tue, Apr 1, 2008 at 11:15 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Hi, > > Now that half of the team is getting ready to work on Wicket 1.4, > which is all about supporting the Java 5 features, I think it is time > for the other half of the team to start talking about Wicket 3.0 (we > skip 2.0 as we've used that for prototyping before), which is > scheduled for 2009. > > We've had some offline talk about this with various team members, and > it seems that we have basic agreement on at least a couple of things: > > * Wicket 3.0 source will be all Scala (http://www.scala-lang.org/), > which means quite a transition for our team, but we will still > maintain compatibility with regular Java. > * Relax our policy towards scripting in pages. We're just getting > tired of people having a hard time to do simple things with Wicket, so > in the future we want to support loops, conditionals and property > expressions directly in the markup on top of the facilities we have > now. > * Introduce layout managers. While it is great to be able to directly > code markup with Wicket, we'd like to hide that a bit more and > introduce layout managers as the preferential mechanism for composing > pages and components. > * Swing compatibility. We want our future components to be able to run > directly in Swing, and Swing components to be run in Wicket apps. Just > like some of our competitors. > > WDYT? Comments/ suggestions? > > Cheers, > > Eelco >
Re: linkedin group
Yeah, thanks Nino, Eelco On Mon, Mar 31, 2008 at 11:04 AM, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: > Guy's I've taken the liberty to use the wicket logo at the linkedin > group is it okay? > > -- > -Wicket for love > > Nino Martinez Wael > Java Specialist @ Jayway DK > http://www.jayway.dk > +45 2936 7684 > >
planning for Wicket 3.0
Hi, Now that half of the team is getting ready to work on Wicket 1.4, which is all about supporting the Java 5 features, I think it is time for the other half of the team to start talking about Wicket 3.0 (we skip 2.0 as we've used that for prototyping before), which is scheduled for 2009. We've had some offline talk about this with various team members, and it seems that we have basic agreement on at least a couple of things: * Wicket 3.0 source will be all Scala (http://www.scala-lang.org/), which means quite a transition for our team, but we will still maintain compatibility with regular Java. * Relax our policy towards scripting in pages. We're just getting tired of people having a hard time to do simple things with Wicket, so in the future we want to support loops, conditionals and property expressions directly in the markup on top of the facilities we have now. * Introduce layout managers. While it is great to be able to directly code markup with Wicket, we'd like to hide that a bit more and introduce layout managers as the preferential mechanism for composing pages and components. * Swing compatibility. We want our future components to be able to run directly in Swing, and Swing components to be run in Wicket apps. Just like some of our competitors. WDYT? Comments/ suggestions? Cheers, Eelco
Re: VOTE: Issue 1371 wicket.properties cannot be found in OSGi
[ ] do it for 1.3 [ x ] do it for 1.4 Otherwise before you know we'll get on that slippery slope again of what is important enough to warrant a break on a current release and what is not. Eelco
Re: VOTE issue 1444, AbstractDecimalConverter has a numberFormats fields that holds NumberFormats, But those are not thread save...
[ ] remove the map and the method for 1.3 [ x ] remove the map and the method for 1.4 I don't think users benefit much from being able to set the formatter directly anyway. Eelco
Re: [vote] Release 1.4 with only generics and stop support for 1.3
[ x ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3 [ ] -1, I need a supported version running on Java 1.4 Eelco
Re: Request for comments on a patch
Did anyone try to contact the blogger directly? Eelco On Mon, Mar 17, 2008 at 6:43 AM, Toomas Römer <[EMAIL PROTECTED]> wrote: > Hello > > ZeroTurnaround team has stumbled upon a blog post > http://d.hatena.ne.jp/mdgw/20080314/1205513596 with a title > Wicket+Spring+JavaRebel. The translated version of the post is here: > > http://translate.google.com/translate?u=http%3A%2F%2Fd.hatena.ne.jp%2Fmdgw%2F20080314%2F1205513596&langpair=ja|en&hl=en&ie=UTF-8 > > The translated text is rather difficult to read and as we don't have > Wicket experience could someone comment on the patches attached to > that blog post: > http://www.madogiwa.org/wicket/wicket-ioc-1.3.1-zt-patch.txt > http://www.madogiwa.org/wicket/wicket-spring-1.3.1-zt-patch.txt > > JavaRebel is a ZeroTurnaround product and we are interested if the > provided patches are actually useful? > > Toomas Römer > ZeroTurnaround.com >
Re: cancel buttons
> true. otoh, a newbie may not know that. giving them a couple cancel button > subclasses would be very obvious. The problem with providing easy components like this is not only that it expands Wicket's surface area, but also that it doesn't encourage people to think about extending components for their own purposes. I'm not big on the idea of adding such components, though I won't officially object either. -0 Eelco
Re: Please welcome Maurice Marrink to the Wicket team
Welcome Maurice! Eelco On Sun, Mar 16, 2008 at 7:15 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > Maurice Marrink has been active in the Wicket community for a while > now. In the past he has guided students that created the initial > Wicket Dojo integration (Wicket 1.1 timeframe, before Wicket Ajax). He > has put a lot of effort into creating two security frameworks for > Wicket, with the latest and greatest open sourced: the Wicket Security > framework (aka Swarm/Wasp). Maurice is helping out on the mailing list > for a while now answering all sorts of questions even outside the > realm of Swarm/Wasp. > > To acknowledge his relentless and continuing commitment to the Wicket > project the Wicket PMC has invited Maurice to become a member of the > Wicket team. > > So please join me in welcoming Maurice as our newest addition to the > Wicket team! > > Welcome Maurice! > > Martijn Dashorst >
Re: [VOTE] Release Apache Wicket 1.3.2
+1 Eelco On Wed, Mar 12, 2008 at 12:19 AM, Frank Bille <[EMAIL PROTECTED]> wrote: > Any other votes? I do have 3 binding +1 if I count myself, but sure would > like some more :-) I'l end this vote tonight at some point > > Frank > > > > On Sun, Mar 9, 2008 at 9:22 PM, Frank Bille <[EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > > I have build our second bug-fix release for 1.3. It's uploaded to my > p.a.oaccount: > > > > Distribution: > > http://people.apache.org/~frankbille/releases/apache-wicket-1.3.2/dist/ > > > > M2 Repo: > > http://people.apache.org/~frankbille/releases/apache-wicket-1.3.2/m2-repo/ > > > > RAT log file: > > > > > http://people.apache.org/~frankbille/releases/apache-wicket-1.3.2/apache-wicket-1.3.2.rat > > > > The files has been signed by me and you can find the key here: > > http://www.apache.org/dist/wicket/1.3.1/KEYS > > > > As usual I have tested the release myself and haven't found anything: > > > >- "mvn clean install" in the distribution (mac os x) > >- "mvn jetty:run" in jdk-1.5/wicket-examples. Random testing of > >form, ajax, pub, guice + some more. (mac os x, safari) > >- Checked the RAT log > > > > > > [ ] Release Apache Wicket 1.3.2 > > [ ] Don't release, because... > > > > > > Thank you in advance, > > Frank Bille > > >
Re: Nabble double posts -> disable nabble?
On Tue, Mar 11, 2008 at 8:41 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > I didn't notice any problems. You get the exact same posts multiple > times? Do other people experience this as well? Oh, is 'Improvements to Wicketstuff Suckerfish Dropdowns' an example of that? Eelco
Re: Nabble double posts -> disable nabble?
I didn't notice any problems. You get the exact same posts multiple times? Do other people experience this as well? Eelco On Mon, Mar 10, 2008 at 3:01 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > All, > > I'm getting tired of the double/triple posts coming in from nabble. I > have contacted them and it didn't get resolved. I will contact them > once more in the hope that this time it will be fixed. If not, I am > proposing to remove nabble as an option for posting to our lists. > > Martijn >
Re: wicket-contrib-yui
> As i wasnt on it for a longer time I wanted to ask first if its ok to > submit this to CVS; Eelco, youre in code as mainperson listed - is it ok? Oh yeah, definitively. Thanks a lot! I'm not really active on that project, nor am I using it, so it is great that others (you) use and maintain it. Cheers, Eelco
Re: [jira] Commented: (WICKET-1327) CompoundModel backed by cglib proxies
Yeah, I saw it right after I posted the comment. I deleted it, but not quick enough to avoid you getting the email :-) Interesting idea. Eelco On Feb 6, 2008 2:38 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > This provides us with probably the holy grail for refactoring property > expressions. > > This model uses the type inference of generics together with a proxy > generator to bind to statically types property expressions. > > I think this is awesome: we don't have to wait for Java 7 for this. > > Martijn > > On 2/6/08, Eelco Hillenius (JIRA) <[EMAIL PROTECTED]> wrote: > > > > [ > > https://issues.apache.org/jira/browse/WICKET-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566370#action_12566370 > > ] > > > > Eelco Hillenius commented on WICKET-1327: > > - > > > > What is the advantage of doing this? A dramatic optimization? > > > > > CompoundModel backed by cglib proxies > > > - > > > > > > Key: WICKET-1327 > > > URL: https://issues.apache.org/jira/browse/WICKET-1327 > > > Project: Wicket > > > Issue Type: New Feature > > > Components: wicket > > >Reporter: Scott Swank > > >Priority: Minor > > > Fix For: 1.4-M1 > > > > > > Attachments: Model.zip > > > > > > > > > This is a simple model that lets cglib handle building the > > > propertyExpression. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.0 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 >
Re: [VOTE] meaning of setRequired(true) on a Checkbox
On Feb 1, 2008 9:02 AM, Jon Steelman <[EMAIL PROTECTED]> wrote: > Will the javadocs then indicate that Required is meaningless for a Checkbox > and does not correspond to the Checked value? Yeah, the Javadocs of the Checkbox should state that when this vote passes. Eelco
Re: [VOTE] Release Wicket 1.3.1
On Feb 1, 2008 9:08 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > there will always be "those two other things" though :) Exactly. We'll have 1.3.2 etc. Eelco
Re: [VOTE] Release Wicket 1.3.1
[ x ] Release Apache Wicket 1.3.1 [ ] Don't release, because... Eelco
Re: [VOTE] meaning of setRequired(true) on a Checkbox
> What is the meaning of setRequired(true) on a Checkbox? Some interpret > it as requiring that the Checkbox be checked. Some interpret that it > requires that the Checkbox have a value (which is always the case). See > http://www.nabble.com/%22required%22-for-Checkbox-ts14662131.html#a14680214 > and https://issues.apache.org/jira/browse/WICKET-1221 for some > previous discussion. > > So, please vote: [ ] setRequired(true) means the Checkbox is checked. [ x ] setRequired(true) means the Checkbox has a value (always the case). Eelco
Re: Resin and Wicket
Yeah! Thanks for sharing Mark, Eelco On Jan 29, 2008 11:37 AM, Mark Derricutt <[EMAIL PROTECTED]> wrote: > Nice: > > http://www.jroller.com/ferg/entry/wicket_with_resin_webbeans > > Not sure if Scott's ResinApplicationFactory also handles the > ComponentInjector side of the IoC as well but I thought this was cool to see > regardless... > > Mark > > -- > "The L in LAMP stands for Linux, not Looney" - Jonathan Schwartz, Sun > Microsystems, Inc. >
Re: [vote] establish a [EMAIL PROTECTED] mail list
On Jan 29, 2008 6:04 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > With our growing user base there is a need for organizing community f2f > meetings and other community related issues, as evidenced by the amount of > messages for organizing the Copenhagen meetup. > I propose to create a new focused mailing list to give these efforts a > breathing space and to lessen the traffic on the user list for organizing > these events. This list will also be archived by Apache, and we'll give it a > place on nabble as well. > > [ ] +1 establish community@ for community related traffic > [ ] -1 don't because -0. I don't really see the point in having yet another one as I don't think many people will sign up by default. The messages on the user list don't bother me too much tbh. It's easy enough to ignore a thread if you want. I think one a number of people has been established for a meetup, the organizers should take part of the fine tuning offline, using private mails rather than community mails. To me that is a better solution than creating another mailing list. Eelco
wicket-examples' base classes
Hi, Had a little discussion here: http://www.artima.com/forums/flat.jsp?forum=276&thread=223133 James mentions that he found the fact that the examples' pages extend base classes confusing. And I can actually imagine that. WDYT, should we change part of our examples, or give more explanation up-front, or do we keep what we have? Eelco
Re: Review Wicket Screen Cast: Navomatic
On Dec 20, 2007 12:44 AM, Gerolf Seitz <[EMAIL PROTECTED]> wrote: > hi all, > > Dan finished his second screen cast[0]. it would be great if you could take > a look at it. > please provide feedback (if necessary), so he can put together a final > version. Imho, it would look a lot better if he'd use more short cuts, such as creating a class with constructor (option in the wizard) and instead of typing getHomePage, just doing that using code completion. Also, it would look better if he'd use a plugin for XML/ HTML files (for instance, install eclipse-jee-europa). For the rest, it looks good to me. Eelco
Re: VOTE: return to 1.3 numbering because 1.3.0-snapshot and 1.3.1-snapshot is driving me crazy
[ x ] Yes, this numbering scheme seems reasonable Eelco
Re: [wicketstuff] hosting repositories on sourceforge
Another problem (I think) with sourceforge is that space is limited. Wicket-stuff is registered as one project, but there are quite a few projects under there. Eelco On Jan 18, 2008 11:47 AM, David Bernard <[EMAIL PROTECTED]> wrote: > The one on apache is not accessible/updatable by wicketstuff developpers, it > also mixe releases and snapshots. > the repo on sf.net could be slow > * if the releases are rsync on central repo. > * snapshots version are less used > * if it allows to release easier (and may be more often) > > Currently deploy a release (or a snapshots) is very unclear. > > As a wicketstuff developper, I vote for a simpler process to release on sf or > somewhere else. > > /davidB > > > Igor Vaynberg wrote: > > we did have a maven2 repo on sf.net for wicket before we moved to > > apache but it was appallingly slow... > > > > -igor > > > > > > On Jan 18, 2008 4:38 AM, David Bernard <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> May be part of the space problem on bamboo server, could be solve by > >> hosting maven-repository on sourceforge. > >> There is some advantages : > >> * every committer on wicketstuff, already, have ssh access > >> * every committer could deploy manually snapshots and releases > >> * release version could be deploy with maven-release-plugin > >> * if there is 2 repositories repo-releases and repo-snapshots, then we > >> could request a rsync from repo-releases to maven central repository > >> > >> I already setup this type of configuration of sf (cf: > >> http://alchim.sf.net/download) and similar for other server > >> http://maven-repo.gforge.inria.fr/releases , > >> http://scala-tools.org/repo-releases . > >> > >> WDYT ? > >> > >> I could do a try with wicketstuff-parent, wicketstuff-misc > >> > >> /davidB > >> > >
Re: Wicket Stuff commit access
On Jan 17, 2008 2:36 PM, saki <[EMAIL PROTECTED]> wrote: > > In that case it is sakiss (login name). > Petr You're in. Have fun! Eelco
Re: Wicket Stuff commit access
> Wow, that was quick ... > My user id is 1289197. May be I will have same questions regarding the > initial import - just to be sure I'll not do something wrong ... > Petr I think we need your logic id (mine is 'eelco12' for instance). Eelco
