Re: wicket:interface, etc. in generated URLs
On 7/25/07, Al Maw [EMAIL PROTECTED] wrote: Hi folks, Although some people don't really care what their URLs look like, lots of people do. If you use UrlCompressingWebCodingStrategy you can get the actual parameter values for interface/behaviour/etc. URLs looking pretty small and inoffensive. But the name is still something large, like wicket:interface. I'm wondering if for 1.3 we could replace that with just: wicket:interface-- w:i wicket:behaviourId -- w:b wicket:bookmarkablePage -- w:p wicket:pageMapName -- w:m It'd make the URLs shorter and not really any less comprehensible (this stuff only really means anything to people who understand the internals anyway). It'd make things very marginally quicker (less string matching). In short, I can't really see any disadvantage to it, other than that it will break any existing bookmarks to non-mounted pages. I'm pretty sure that the upgrade from 1.2 to 1.3 breaks these anyway. It's a trivial fix (just update the constants in WebRequestCodingStrategy and a bunch of expected unit test results). What do people think? +1 Eelco
Re: getWrappedModel and getChainedModel (Component.getInnerMostModel())
we also have IChainingModel shouldn't we also test for that? because çurrently the behavior is that we only test for WramModels to get to the innermost model but what is then the big difference with IChainingModel? Hey, didn't you code that stuff? :) Eelco
Re: Improve Wicket performance with ETags
On 7/17/07, Johan Compagner [EMAIL PROTECTED] wrote: wicket is a framework for dynamic webpages, so 99% of the time you don't want to cache and you want to make sure that the browser does query again for the page. Also the none bookmarkable pages are like wicket:interface= and that xxx can be anything and 2 the same values could point to completely different things over multiply runs of the browser. if you want caching you have to do it your self in Page.configureResponse() or in your Resources.configeResponse() In both default imp we do already some stuff for example Page is configured to not cache and a resource if it is cacheable will send 2 headers. Also we have special support for the head request: 'If-Modified-Since' I agree with Johan, though giving it a serious look sometime wouldn't hurt I guess. I think it wouldn't be very complex to look at. Bruno, how about you write a little proof-of-concept? Eelco
Re: Improve Wicket performance with ETags
On 7/17/07, Bruno Borges [EMAIL PROTECTED] wrote: Sure Eelco... :) As soon I get something showable... I'll show you... lol Cool :) Eelco
Re: ehcache based MarkupCache
On 7/15/07, Juergen Donnerstag [EMAIL PROTECTED] wrote: no big plus, just playing a bit and having the option if some realy realy needs it.It should not go into the core project for sure. I'm just looking for the right place to drop it. If extension is not the right place either, due to the dependency, where should go? If not useful at all, we don't need to put it anywhere. If you want to keep it, you should make it a separate project. People wanted me to create wicket-datetime because it had a dependency on joda-time, so it makes sense to create a seperate project for this as well. Eelco
Re: Escaping quotes in attributes
1. Automatically insert an attribute value that's the same as the name (which I think it always should be), for things like disabled. 2. Prevent people adding null values to the map in the first place. To do this, we'd need to wrap the IValueMap in XmlTag with some magic on the put method to check for null values. Or we could add a boolean flag to IValueMap to say whether it accepts them, or similar. Obviously #1 is nice and simple. What do people think? #1 sounds good to me. Eelco
Re: Clone problem? Difference in behavior between 1.2 and 1.3
this is not really solveable by wicket itself.
We don't know where such a reference is comming from, so this should be
documented i guess
that if you use session data from the session object itself. You should
always use an extra
indiretion to get it
new Model()
{
getObject() {Session.get().getList()}
}
I don't see a generic solution either, but in this case I though you
should use custom serialization of either your custom session or a
model you use for the extra indirection.
Eelco
Re: Thread synchronization problems in FilePageStore
I opened an issue here http://issues.apache.org/jira/browse/WICKET-746 Eelco
Remove PageView in ExceptionErrorPage
Hi, Our first part of the ExceptionErrorPage works fine. It's straightforward and displays useful information. I'm not happy with the PageView part though. Tbh, I don't think I ever read anything from tree that helped me. What's worse, the size bit in the PageView can be a serious hog sometimes. For example, a problematic page I'm looking at now takes more than 40 seconds to calculate the sizes of all the individual components, and the resulting output is 400KB! If I remove PageView from the ExceptionErrorPage, it displays immediately, and is just 20KB. I would like to remove PageView from ExceptionErrorPage. I don't think information such as # PathSizeTypeModel Object 1 -header org.apache.wicket.markup.html.internal.HtmlHeaderContainer 2 -header:_FeedbackPanelnullHeader2 org.apache.wicket.markup.html.HeaderPartContainer 3 -header:_FeedbackPanelnullHeader2:_link_13 org.apache.wicket.markup.html.WebMarkupContainer 4 -header:_FeedbackPanelnullHeader2:_link_13:_autolink_14 org.apache.wicket.markup.html.WebMarkupContainer 5 -header:_FilterableTableViewEmbeddednullHeader2 org.apache.wicket.markup.html.HeaderPartContainer 6 -header:_FilterableTableViewEmbeddednullHeader2:_link_9 org.apache.wicket.markup.html.WebMarkupContainer 7 -header:_FilterableTableViewEmbeddednullHeader2:_link_9:_autolink_10 org.apache.wicket.markup.html.WebMarkupContainer 8 -header:_PagingNavigatornullHeader0 ... etc is useful in that page at all, and having to wait for half a minute before you see the page is very anoying. We might consider adding e.g. an Ajax based tree that you can use to navigate the structure, but otoh, we would only have such a tree in there because it is fancy, not because it actually helps debugging (for that, just use your IDE). Objections? Eelco
Re: Border re-implemented
On 7/10/07, Juergen Donnerstag [EMAIL PROTECTED] wrote: Today I've committed the new Border to 1.3 trunk. I would appreciate if you could do a quick check of your applications using Borders to make sure everthing is working as expected. Thanks. Hi Juergen. We are experiencing some problems with it and we're looking into it right now. Eelco
Re: FileUploadField closing input streams behind my back
Not only should you not need to add a finalizer, but most importantly, review your codebase and *remove* all finalizers. It's the only one in there. Eelco
Re: FileUploadField closing input streams behind my back
Good. Makes the review easier ;-), and you've only the one to remove. I've opened an issue for it http://issues.apache.org/jira/browse/WICKET-730 Eelco
Re: FileUploadField closing input streams behind my back
On 7/6/07, Johan Compagner [EMAIL PROTECTED] wrote: and if i remember correctly, back then it looked if the FileUpload project was really in suspend stage. there wasn't much happening on it, so i am talking abou the time we added it to the core of wicket Yeah, that's one of the reasons why we felt we would be able to get rid of the dependency without troubles. Anyway, Al, what's your take on this? Eelco
Re: [VOTE] disable line-precise error reporting by default
[ x ] disable this feature by default, put instructions on how to enable it into component-not-found related exception messages [ ] leave it enabled by default I've argued before that if it were up to me, deployment would be our default. Lost that argument and that is fine, but I feel that debug options such as there can give people the wrong ideas. One thing we might consider is to add a third deployment mode - something like DEBUG - which would include this setting and e.g. the outputMarkupClass setting[1] (which is a very useful tool that is turned off by default). And/ or we could consider to have plugable profiles rather than the two hard-coded ones. Eelco [1] http://chillenious.wordpress.com/2007/06/20/locate-where-that-wicket-markup-comes-from/
Re: FileUploadField closing input streams behind my back
Anyway, Al, what's your take on this? Do I have to have one? ;-) I've fixed the bug I was having, haven't had time to compare the two divergent branches since, sorry. I meant Noel's remarks, specifically: So you do have an old version of the FileCleaner, albeit prior to enhancements that have been added to the current version in Commons, and you have added some support for it to org/apache/wicket/util/upload/DiskFileItem.java, but you also have a bogus finalizer in DiskFileItem Eelco
Re: FileUploadField closing input streams behind my back
For that matter, why aren't you using Commons? The very problem (file uploading) you are dickering with is precisely one that we addressed in Commons years ago. The core code is in Commons I/O: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/ap ache/commons/io/ We have been using commons-io from the start, but the code grew in a different direction due to various reasons. Eelco
Re: FileUploadField closing input streams behind my back
I understand we just took what little pieces we needed instead of adding a dependency on the entire thing, but what is meant by the code grew in a different direction due to various reasons? We started using commons-io as just a dependency, but after a while we needed some tweaks to better let it integrate with Wicket (at least that's what I remember) and later on, when we tried to cut down on dependencies we went from a 'patched' version to just taking the classes we needed. Eelco
Re: Problem with latest changes in FormComponent:validate()
Thanks for adding the 'INullAcceptingValidator'. This solves our problem in a clean way. Just a small suggestion: I've seen that the CompoundValidator does not implement this interface. Would it not be correct to assure that the CompoundValidator is called always, and that the same logic of checking the implementation of the interface is applied to all the validators in the chain ? Sounds reasonable, but I didn't implement it. Matej/ Igor? Eelco
Re: Is there any document about SecondLevelCacheXXX ?
I have found the following classes in Wicket 1.3.0-beta2: 1) SecondLevelCacheSessionStore 2) SecondLevelCachePageMap 3) SecondLevelCachePageVersionManager 4) FilePageStore Not really other than the Javadocs. But the short variant: SecondLevelCacheSessionStore and FilePageStore are the only entities you have to care about as an end-user, as SecondLevelCachePageMap and SecondLevelCachePageVersionManager are internal to SecondLevelCacheSessionStore. SecondLevelCacheSessionStore is a session store implementation - the default one for Wicket 1.3 - that keeps the current page (for each page map you have, mind you) in RAM, and stores older page (versions) to 'second level cache' for back button support. The default second level page store, FilePageStore, uses temporary directories (java.temp.dir) and serialization to store the instances. This gives users unlimited back button support for the price of temporary disk space and processor overhead (for serialization). The other session store shipped with Wicket is HttpSessionStore, that keeps a limited list of pages stored in the HttpSession object (which also means it is stored in RAM). This store uses a different version manager that stores change objects for page version that can be used to 'roll back' to earlier versions. This looks cheaper on first sight, but it uses a lot more RAM than the SLCSS and back button support is limited (and more flaky at times it seems). We have found that SLCSS's overhead for serializing and storing pages as temp files hardly is noticable, of course after Johan and later Matej agressively optimized it. On my note book, which should be *a lot* slower than most of production servers, it takes less than 2 miliseconds a request. In the end, the choice is yours. Matej built a SLCSS variant that is fully clustered. Hopefully we'll be able to contribute some of that back sometime. Or you can roll your own :) Eelco
Re: BoxBorderTest_7
On 6/30/07, Juergen Donnerstag [EMAIL PROTECTED] wrote: BoxBorderTest_7 currently fails with Bamboo but it is working fine with me. The Bamboo online information from the test doesn't give me a hint either. And idea? I guess Bamboo is running on Linux? Fails on my machine as well. It says the test expects span davor middle-1 danach /span span davor middle-2 danach /span but gets spandavor middle-1 danach /span spandavor middle-2 danach /span Eelco
Re: [vote] rebuild of wicket-1.3.0-beta 2
Changing the case of Java files tends to cause pain on Windows systems, because they're case-insensitive. We're almost guaranteed to have people with strange ClassNotFoundExceptions if we go and do this. It's yet another API change just before we release 1.3.0. If we fix the class names, we should also fix the method names. There's a lot of inconsistency at the moment, and this would cause an awful lot of API breakage. It would make sense to use Javascript everywhere, as JavaScript is one word, so when you CamelCase it, it should all go lower. Otherwise, if you have a JavaScriptHandler, is it a ScriptHandler for Java, or a Handler for JavaScript? Anyway, there's a bunch of stuff we'd need to fix, including HeaderContributor.forJavaScript(), etc. etc. I don't think we want to do that this close to a 1.3 release. I imagine it'd be a faff for the upcoming Wicket book, too. I agree. The book isn't much of a problem in this case, but I know from some previous renames (around 1.1 if I recall correctly) that it can be a pain especially for Windows users. Annoying as these little naming inconsistencies can be, I'm not sure if it's is worth the pain. Eelco
Re: BoxBorderTest_7
On 6/30/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
BoxBorderTest_7 currently fails with Bamboo but it is working fine
with me. The Bamboo online information from the test doesn't give me a
hint either. And idea? I guess Bamboo is running on Linux?
I found and fixed an issue in MarkupParser:
if
(CONDITIONAL_COMMENT.matcher(comment).matches() == false)
{
buf.append(rawMarkup.substring(0, pos1
- 1));
should be
if
(CONDITIONAL_COMMENT.matcher(comment).matches() == false)
{
buf.append(rawMarkup.substring(0,
pos1));
in this particular test, the newline was removed (and windows and
linux/ osx work with different characters).
Eelco
Re: [proposal] restructure projects a bit
I'm proposing to move things a bit around. Sounds good to me, +1 Eelco
Re: [vote] rebuild of wicket-1.3.0-beta 2
[ x ] I have checked the distribution and +1 its release [ ] I haven't checked the distribution and +0 its release [ ] I have checked the distribution and -1 its release because... Eelco
Re: [vote] release Apache Wicket 1.3.0-incubating-beta-2
[ ] I checked the distribution, and I +1 the release of them [ x ] I didn't check the distribution, but I want to release them regardless (+0) [ ] I don't want to release the distribution, because ... Eelco
Re: getMarkupId doesn't return the id from the markup
Unfortunately, the fix for http://issues.apache.org/jira/browse/WICKET-694 had some side effects I didn't come across when testing :( It's a bloody shame, but it seems that already too much code assumes it can call getMarkupId where it shouldn't. I'm leaving the bug open, but at this time I have no idea on how to fix it. Eelco On 6/24/07, Eelco Hillenius [EMAIL PROTECTED] wrote: I believe the current behavior is intentional. Igor seemed to feel quite strongly about not using markup id specified in template. The reason is that it's not unique and it behaves wrongly in repeaters or when you put the component to page twice. I remember having this discussion a very long time ago, but I though we decided that even though there is some danger in it, it is the responsibility of the user. Which is the right thing imo. I'd actually prefer wicket to preserve specified attribute because it can be handy in cauple of cases. But that's just my opinion. The thing is that we call this method getMarkupId, but it only returns the id you can find in the markup when you *don't* provide one explicitly (and tell the component to write it's id). Even if you set setOutputMarkupId(true), Wicket won't override the id in the markup, which of course has the effect that any Javascript refering to the id - like the datepicker does - does not work. So we currently have the situation that if you set the id explictly, stuff won't work anyway, and we have a method name that doesn't do what the name hints (for it's current behavior it should be called something like getGeneratedMarkupId). Eelco
Re: getMarkupId doesn't return the id from the markup
On 6/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote: What are the side effects? Jonathan had problems: http://www.nabble.com/Unable-to-find-the-markup-for-the-component-tf3976741.html and the project I'm working on got some exceptions from the test site this morning as well. For instance: org.apache.wicket.WicketRuntimeException: Unable to find the markup for the component. That may be due to transparent containers or components implementing IComponentResolver: [MarkupContainer [Component id = text, page = ts4.web.wicket.page.workspace.ComponentPage, path = 1:content:reply-form:form:text.KeepAliveTextArea, isVisible = true, isVersioned = false]] at org.apache.wicket.MarkupFragmentFinder.find(MarkupFragmentFinder.java:111) at org.apache.wicket.Component.getMarkupAttributes(Component.java:1176) at org.apache.wicket.Component.getMarkupId(Component.java:1211) at org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getPreconditionScript(AbstractAjaxTimerBehavior.java:96) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.generateCallbackScript(AbstractDefaultAjaxBehavior.java:161) at org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getCallbackScript(AbstractAjaxTimerBehavior.java:84) at org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getJsTimeoutCall(AbstractAjaxTimerBehavior.java:78) at org.apache.wicket.ajax.AbstractAjaxTimerBehavior.renderHead(AbstractAjaxTimerBehavior.java:66) at org.apache.wicket.Component.renderHead(Component.java:2182) at org.apache.wicket.markup.html.internal.HtmlHeaderContainer$1.component(HtmlHeaderContainer.java:209) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:820) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:835) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:835) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:835) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) at org.apache.wicket.markup.html.internal.HtmlHeaderContainer.renderHeaderSections(HtmlHeaderContainer.java:200) at org.apache.wicket.markup.html.internal.HtmlHeaderContainer.onComponentTagBody(HtmlHeaderContainer.java:134) at org.apache.wicket.Component.renderComponent(Component.java:2104) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1294) at org.apache.wicket.Component.render(Component.java:1931) at org.apache.wicket.Component.render(Component.java:1894) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:223) at org.apache.wicket.markup.resolver.HtmlHeaderResolver.resolve(HtmlHeaderResolver.java:81) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1206) Unfortunately, I'm a bit too busy at this time to figure out what exactly the problem is, but I left the issue open. It seems hard to fix without having a construct like our 2.0 adventure had. We have been down this road too many times and we keep forgetting them (or ignoring until we can't bare them) I'd hate to not fix this one once and for all. Me too. Maybe Juergen/ someone else has a good idea? Eelco
Re: getMarkupId doesn't return the id from the markup
i can think of one, getMarkupId() can't really be called in the constructor phase (as we could do in 2.0) (it now can but then you really have to make sure how you construct your objects you have to setup the hierachy up until the page as soon as possible) Yeah, even now the component has to be able reach the page it is attached to to work. I thought/ hoped that being attached to the page would be good enough for the markup loading as well. Eelco
Re: commit rights on wicket-stuff
may I ask for commit rights for sourceforgeuser svenmeier on wicket-stuff? He is massive help on gmap2, commit rights for him would help its develoment a lot. Done. Thanks for helping out! Eelco
Re: getMarkupId doesn't return the id from the markup
On 6/25/07, Matej Knopp [EMAIL PROTECTED] wrote: I think reasonable behavior would be to generate markup id when invoked from constructor (instead of failing getting one from markup). However, I'm affraid the complications you have are caused by the fact the the component hasn't been rendered already, so it doesn't know it's markup position. At least we had similiar problems with 1.2, iirc. Yeah, I'm afraid of that too. And I understand that for some components the markup position can only be known at runtime, right? Is there any way anyone can think of how we could bind in an efficient way before rendering? Eelco
should we get rid of IRequestCycleFactory and ISessionFactory?
IRequestCycleFactory and ISessionFactory annoy the hell out of me. We simplified how they are used a bit in 1.3, but imho, I think we should just ditch them all together in favor of simply two factory methods in application. Factory method newSession already exists in WebApplication (as that class implements ISessionFactory), but to create a new request cycle you still have to override getRequestCycleFactory(). Objections anyone? Eelco
Re: should we get rid of IRequestCycleFactory and ISessionFactory?
https://issues.apache.org/jira/browse/WICKET-689 is very related to this. Yep, that and working on Wicket In Action, triggered sending this email. I can't see if there will be any unwanted consequences by doing this Don't think so. If people for whatever reason want more indirection they can build that in the factory methods. Eelco
getMarkupId doesn't return the id from the markup
Yep, you read that right. I just found out that if you explicitly
define an id attribute on your component, getMarkupId still just
returns a generated one. This suprises me; I'm pretty sure we always
agreed that if an explicit id is provided in the markup, that should
be used. See the date picker in wicket-examples/forminput for example:
it doesn't work now because the id is set to dateProperty but
getMarkupId, which is used by the date picker, returns
dateProperty1.
The fix is easy[1], but results in a failing unit test. Imho, that
unit test is just too fragile, and I'm thinking about implementing a
quick fix for it and submit this change. But I wanted to check here
first in case I'm overlooking something.
Eelco
[1]
Index:
/Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
===
---
/Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
(revision
550266)
+++
/Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
(working
copy)
@@ -1181,10 +1181,13 @@
/**
* Retrieves id by which this component is represented within the
markup.
+* This is either the id attribute if it is set explicitly in the
markup, or
+* a generated id.
* p
* The point of this function is to generate a unique id to make it
easy to
* locate this component in the generated markup for post-wicket
processing
-* such as javascript or an xslt transform.
+* such as javascript or an xslt transform in case no explicit id was
set
+* yet.
* p
* Note: This method should only be called after the component or its
parent
* have been added to the page.
@@ -1204,7 +1207,13 @@
+ to find the page
it is supposed to operate in before you can call
+ this method
(Component#getMarkupId));
}
- markupId = getId() + page.getAutoIndex();
+ // try to read from markup
+ markupId = getMarkupAttributes().getString(id);
+ if (markupId == null)
+ {
+ // if not in the markup, generate one
+ markupId = getId() + page.getAutoIndex();
+ }
setMetaData(MARKUP_ID_KEY, markupId);
}
return markupId;
Re: getMarkupId doesn't return the id from the markup
On 6/24/07, Martijn Dashorst [EMAIL PROTECTED] wrote: I think everyone ran into it at one time... I know I did. Last time I think Igor threw some issues with repeaters into the mix, and then the discussion went dead. For all I know, it worked in 2.0. I remember testing it specifically. I'm just surprised it doesn't work the same in 1.3. Did we forget to backport it maybe? The name of the method is a pretty clear indication what we had in mind with it, right? FYI, I tested all of the examples of wicket-examples, including the ajax and repeater tests, and they worked fine. The unit test that fails is RadioGroupTest#testFormProcessing but that is because the page tested isn't backed up by the proper markup (it uses org.apache.wicket.protocol.http.MockPage which doesn't have any of the components that are added in that test). So the test is faulty here. Eelco
Re: getMarkupId doesn't return the id from the markup
I believe the current behavior is intentional. Igor seemed to feel quite strongly about not using markup id specified in template. The reason is that it's not unique and it behaves wrongly in repeaters or when you put the component to page twice. I remember having this discussion a very long time ago, but I though we decided that even though there is some danger in it, it is the responsibility of the user. Which is the right thing imo. I'd actually prefer wicket to preserve specified attribute because it can be handy in cauple of cases. But that's just my opinion. The thing is that we call this method getMarkupId, but it only returns the id you can find in the markup when you *don't* provide one explicitly (and tell the component to write it's id). Even if you set setOutputMarkupId(true), Wicket won't override the id in the markup, which of course has the effect that any Javascript refering to the id - like the datepicker does - does not work. So we currently have the situation that if you set the id explictly, stuff won't work anyway, and we have a method name that doesn't do what the name hints (for it's current behavior it should be called something like getGeneratedMarkupId). Eelco
Re: Drag and drop
And the best thing about these unix commands is that they are so obvious :) Eelco On 6/21/07, Martin Funk [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb: The benefits of unix: find jdk-1.4/wicket -name *.js | xargs grep -E rag|rop delivers jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js Martijn please don't hit me for this, or as a former college of mine always says: grep is one of the most underestimated unix commands grep -r --include='*.js' -E 'rag|rop' jdk-1.4/wicket mf
Re: Drag and drop
On 6/22/07, Martin Funk [EMAIL PROTECTED] wrote: That's were 'ctrl' + 'r' comes into play. Figure it out once and your history never forgets:-) And if it does beefing up 'export HISTSIZE=5000' might help. Indeed :) I also keep a document around with my favorite tricks. Though I'll never be unix wiz I'm afraid. Eelco
Re: VOTE: Rename AjaxSubmitButton to AjaxButton
See how confused we are? :) Seriously, if we can't agree on it, we should just pick the shortest names ;) Eelco On 6/21/07, Johan Compagner [EMAIL PROTECTED] wrote: AjaxSubmitButton is a right name because its only purpose is that it submits a form right? But i don't mind that it is renamed but Button is not only a SubmitButton. We could make a subclass that really makes a input type=submit? (or test fors it) Because i use buttons on many places to replace links (but the look and feel of a button) so for me its not what they do, its how the look. So now AjaxButton always submits and Button can submit but also used as a link click.. So maybe a bit better thing would be to hava a AjaxSubmitButton and a SubmitButton (extends Button) and let button be used also for the other types or maybe introduce LinkButton? johan On 6/21/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: +0 The Javadoc says: A button that submits the form via ajax. And the callback method is called onSubmit(). So even if you rename the class (which is a very costly operation in a framework), it won't be sufficient to eradicate the term submit. I understand that you want to streamline the name with Button, but actually I would vote to rename Button to SubmitButton. I was recently doing pair programming with a colleague, and we were stupidly looking for SubmitButton and wondered why it was not showing up. It was the obvious class name we thought... -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Drag and drop
How does an application developer use Wicket.Drag?Will there be a DraggableBehavior (IBehavior) object? It is used for the Ajax debug panel. Not sure if Wicket.Drag is used for anything besides that. But there are multiple Wicket-stuff projects that have support for drag and drop. See http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki (I think Dojo integration has it and http://wicketstuff.org/confluence/display/STUFFWIKI/Script.aculo.us+Draggables looks like it). Eelco
Re: Application#destroy()
On 6/20/07, Maurice Marrink [EMAIL PROTECTED] wrote: Whatever makes you happy :) I see Johan as has already made the change of putting callDestroyers in internalDestroy. However if you are going to rename that method (not sure if Martijn is going to like that this late in the game). Please let us know since those projects still on jdk 1.4 don't warn about missing override methods. That's why we should leave the method in there as final and a TODO: remove after compat release. Eelco
Re: Application#destroy()
bah, i'd rather have the rename. I have absolutly no problem with a rename as long as it is announced on the mailing list. That's fine. But I have :). And I have been bitten by it enough to know that without such a deprecation realease, people *will* forget/ not notice. Eelco
Re: VOTE: Rename AjaxSubmitButton to AjaxButton
[ x ] Yes, rename AjaxSubmitButton to AjaxButton, leaving behind a @deprecated subclass for backwards-compatibility. [ ] No, that's a crazy idea. We're frozen for 1.3.0 and this sort of stuff shouldn't change this late in the day. Eelco
Re: Fix inconsistent naming for submit components
I've given this thread a little bit thought, and besides the objections Martijn and me have regarding the book, I don't think I like SubmitButton better than Button. To me, a Button is more generic and SubmitButton makes me think about 'just' the input type=submit tag while it can be used for more than that (which is something I always liked). Just a personal preference, sure, but also an indication to me that we might like SubmitButton today, Button tomorrow, and they day after (maybe with other people in the team) SubmitButton again. At some point we'll just have to say, this is ok, even if not everyone completely agrees at any given time. Naming is important, but so is stability. My 2c, Eelco
Re: abbreviated stack traces
maybe the exception display page should just hide all the extra details using a javascript triggered fold-out instead of trying to programmatically remove it? That would be nice. Eelco
Wicket + GWT
Hi, I just came across this: http://cwiki.apache.org/WICKET/using-gwt-widgets-as-wicket-components-tutorial.html Did someone ever did that? Is it a good idea to have such integration rather than just running GWT as an applet? And if this is a good idea, how about putting this in a Wicket-stuff project? Cheers, Eelco
Re: Move wicket.injection and wicket.proxy packages to wicket core? Or create wicket-ioc?
Hi folks, The wicket-spring project currently has some generic injection and proxy classes with no Spring dependencies. If we want to provide support for Guice, these should go and live somewhere else, otherwise wicket-guice will need to depend on wicket-spring, which seems silly. ;-) There are three options I can think of: 1. Make people who want to do Guice injection depend on wicket-spring. 2. Create a wicket-ioc project, put these common components in there. Make wicket-spring (and eventually wicket-guice) depend on that. 3. Move the components into the core wicket project. This would entail adding the cglib-no-dep and asm dependencies to the core project, which isn't ideal. Which would people prefer? I'm thinking #2 might be best. +1, #2 is best. Is anyone working on Guice integration yet? Looks like it should be fairly simple to achieve. Eelco
Re: Problem with latest changes in FormComponent:validate()
Maybe a bit OT, but how exactly do you implement this Jan?
The project I'm working on has:
public final class ValidationListener implements
IComponentOnBeforeRenderListener {
public void onBeforeRender(Component component) {
if (component instanceof FormComponent !component.hasBeenRendered()) {
processComponent((FormComponent) component);
}
}
...
and then somewhere in processComponent:
...
Column column = field.getAnnotation(Column.class);
Class? type = field.getType();
..
if (column.nullable() == false type != Boolean.class type !=
Boolean.TYPE) {
component.setRequired(true);
}
Do you something similar, or do you follow an intirely different
aproach (probably, coming from 1.2)?
Eelco
On 6/19/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
Problem with all these solutions, is that we have to differentiate between
'RequiredValidators' and other validators, which means somehow we have to
know which ones to call when. Because now, there is just a list of
validators, added to the component, and they get called by Wicket. What I'm
trying to say is that checking if a field is empty or not can be just a
validator task. Now, we can no longer simply plug that in as just another
validator.
I understand that it is handy not to have to check if a value is null, but
we're paying a price for this that might be higher than the gain ?
Jan.
igor.vaynberg wrote:
or instead,
maybe make that hibernatevalidator also be a behavior, and simply toggle
component's setrequired in onattach
-igor
On 6/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i dont know about that. isvalid's contract is that it only returns false
if there are error messages reported against the component.
i think this would be simple enough
class hibernatetextfield extends textfield {
valid() {
if (hibernaterequired()) {
if (Strings.isEmpty(getInput()[0])) {
error(new ValidationError().addMessageKey(Required));
return;
}
}
super.validate();
}
-igor
--
View this message in context:
http://www.nabble.com/Problem-with-latest-changes-in-FormComponent%3Avalidate%28%29-tf3945885.html#a11200959
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Problem with latest changes in FormComponent:validate()
On 6/19/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Maybe a bit OT, but how exactly do you implement this Jan?
The project I'm working on has:
public final class ValidationListener implements
IComponentOnBeforeRenderListener {
public void onBeforeRender(Component component) {
if (component instanceof FormComponent !component.hasBeenRendered()) {
processComponent((FormComponent) component);
}
}
...
and then somewhere in processComponent:
...
Column column = field.getAnnotation(Column.class);
Class? type = field.getType();
..
if (column.nullable() == false type != Boolean.class type !=
Boolean.TYPE) {
component.setRequired(true);
}
processComponent starts like this:
public static void processComponent(FormComponent component) {
IModel model = component.getModel();
if (model instanceof IPropertyReflectionAwareModel) {
Field field = ((IPropertyReflectionAwareModel)
model).getPropertyField();
if (field != null) {
processComponentField(field, (FormComponent)
component);
Eelco
Re: RequestCycle, max steps
Ok. I set it to 100. Is that reasonable? Eelco On 6/19/07, Sean Sullivan [EMAIL PROTECTED] wrote: Short.MAX_VALUE is definitely too high. I'd love to see a lower value. Sean On 6/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: max int is actually a pretty rediculous default in itself. How about setting it to 1,000 or even 100 or such? Eelco On 6/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Why would you want to do that? Sure, we can put a setter in there, but it is really only meant to detect cycles. Eelco On 6/18/07, Sean Sullivan [EMAIL PROTECTED] wrote: In RequestCycle.java, the steps() method has this code: * final* *int* maxSteps = Short.MAX_VALUE; Is there any way for me to override the maxSteps value? Would it be reasonable to have getter/setter methods? protected void setMaxSteps(int value) protected int getMaxSteps() Cheers, Sean
AbstractBehavior#isEnabled(Component component)
AbstractBehavior#isEnabled(Component component) currently returns true
by default. Wouldn't it be better if it was implemented like this?
public boolean isEnabled(Component component)
{
return component.isEnabled();
}
Behaviors should be ignored when a component is not visible, but some
components like TextFields for instance, can be disabled but still
visible. A concrete case I have here is a disabled textfield with a
datapicker attached, and the datepicker is still visible and worse,
when you use it, you can change the value in the textfield.
Any objections for this change?
Eelco
Re: AbstractBehavior#isEnabled(Component component)
Done.
Eelco
On 6/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
go for it
-igor
On 6/19/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
AbstractBehavior#isEnabled(Component component) currently returns true
by default. Wouldn't it be better if it was implemented like this?
public boolean isEnabled(Component component)
{
return component.isEnabled();
}
Behaviors should be ignored when a component is not visible, but some
components like TextFields for instance, can be disabled but still
visible. A concrete case I have here is a disabled textfield with a
datapicker attached, and the datepicker is still visible and worse,
when you use it, you can change the value in the textfield.
Any objections for this change?
Eelco
Re: Fix inconsistent naming for submit components
-1 on the streamline. I'm not going to go through and rewrite my chapters of the book yet *again*. Can we just agree to keep the API stable? Yeah, +1 on that. You guys scare the hell out of me if I have to think about how long *any* book will be valueable on any version :-) It's time to settle down on our core components/ concepts for a while. It will never be perfect/ to everyone's taste, and there's enough other things that imho would have more priority. Eelco
Re: RequestCycle, max steps
Why would you want to do that? Sure, we can put a setter in there, but it is really only meant to detect cycles. Eelco On 6/18/07, Sean Sullivan [EMAIL PROTECTED] wrote: In RequestCycle.java, the steps() method has this code: * final* *int* maxSteps = Short.MAX_VALUE; Is there any way for me to override the maxSteps value? Would it be reasonable to have getter/setter methods? protected void setMaxSteps(int value) protected int getMaxSteps() Cheers, Sean
Re: A new proposal for Wicket Portlet support
Great news Ate! It would be interesting to read the experiences of those who have been playing with it in this thread. Is anyone considering using this for their projects yet? Cheers, Eelco On 6/14/07, Ate Douma [EMAIL PROTECTED] wrote: As promised a few weeks ago, I've created a separate branch, wicket-1.3-portlet-support, and checked in a first initial version of the new portlet support. I also created a bunch of JIRA issues as subtasks under one main portlet-support issue: https://issues.apache.org/jira/browse/WICKET-647. To showcase what the portlet support is capable of (and not), I also created a Jetspeed-2.1.1-beta1 based demo portal installer which can be downloaded from my apache home. See: https://issues.apache.org/jira/browse/WICKET-658 I'd like to invite all developers and users interested to review this intial version and the changes on Wicket core required for it. Note: I've tried to isolate the changes in small commits and recorded them to specific JIRA issues for easier reviewing. I'm looking forward to feedback and will start discussing possible further changes, enhancements and fixes soon on this dev list. I *do* need your input for that as going anything further than this requires more expertise than I currently have :) Regards, Ate Ate Douma wrote: As already mentioned by Eelco a few days ago, I'd like to propose a new plan for Wicket Portlet support. Preliminary warning: this mail ended up to be quite long :) For those of you familiar with the Portlet API some of the following is probably a bit verbose, but please bear with me. Good portlet support for Wicket isn't going to be easy and will need quite a few changes/enhancements to the core of the framework and I think it is utmost important that everyone involved is aware of the reasons behind them to be able to properly evaluate the choices available. I also want to make clear that I don't consider this proposal to be final, complete or 100% perfect. It will need further refinement and probably major changes further down the road. Although I have already started with implementing part of this proposal, it is certainly not finished yet and I expect to hit a few technical road blocks as well. Any critics, good or bad, I'd very much appreciate and I will try to respond to them as good as I can. Note though I'm *not* a hard-core Wicket expert yet so I'll be especially depending on the review and evaluation from those who are :) I definitely will welcome simpler/easier/better solutions and I'll be happy to incorporate them! One more remark upfront: as the current trunk is now in API freeze mode for the 1.3 release, none of the following will be applied to the current trunk. Although I am working against the current trunk momentarily, as soon as I get a minimum working version ready I'll create a separate branch off the trunk to commit my changes. And only after a reasonable working version is established there and is reviewed positively, that branch might be merged back into a future trunk ( 1.3) for bringing portlet support back into the Wicket core. Now let me start out by describing the features I personally need for using Wicket in a portlet environment. I want to be able to run a Wicket application both as plain web application and as a portlet at the same time (needing only one WAR file). This means a solution which doesn't require using a portlet specific api but one transparent and independent of the runtime context. Furthermore, I want to be able to use as much as possible of all the Wicket features for Ajax, header contributions and (optionally, possibly) cookies. But especially those features are going to be difficult to support in a portal independent way as the current Portlet API 1.0 doesn't support any of those, actually doesn't even allow using them... The next Portlet Specification 2.0 (JSR-286) will provide much better support for these, but as it isn't available yet we'll be required to use some hacks and/or portal specific extensions to be able to implement and use them *now*. Finally, I need to be able to run multiple Wicket portlets on one (web) page, meaning properly isolating their execution/session environments and things like unique markup id generation/usage across Wicket applications. Besides these functional requirements, I think we should anticipate as much as possible on JSR-286 portlet API 2.0. I'm one of the Expert Group members for JSR-286 and we've doing our best to make life much easier for web framework developers. And while there still will be limitations difficult to overcome, many of the issues I'll address further down will be solved natively by JSR-286. We currently expect to complete the Portlet Specification 2.0 near the end of this summer, but after that it will still take (quite) some time before most/all portals will be able to fully support it. But as I don't want to wait until then I've tried to come
Re: private inner class of compoundpropertymodel
Can't you just create your own version of
AttachedCompoundPropertyModel (you are after all thinking about
extending it, and there isn't so much going on in that class) and
overriding wrapOnInheritance and return an instance of your class?
Eelco
On 6/17/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Hi, I am in the process of extending CompoundPropertyModel and its
inner class AttachedCompoundPropertyModel. However since the last is a
private inner class i am forced to copy the class definition in to my
own creating some code duplication. In order to prevent this
duplication it would be helpful if this inner class was made protected
instead of private and provided a method to access the owning
component. These proposed changes are already applied to the attached
patch. So if everybody agrees the change can be made very quickly.
Index: .
===
--- . (revision 548032)
+++ . (working copy)
@@ -149,7 +149,7 @@
*
* @author ivaynberg
*/
- private class AttachedCompoundPropertyModel extends
AbstractPropertyModel
+ protected class AttachedCompoundPropertyModel extends
AbstractPropertyModel
implements IWrapModel
{
private static final long serialVersionUID = 1L;
@@ -167,7 +167,14 @@
super(CompoundPropertyModel.this);
this.owner = owner;
}
-
+ /**
+* The owning component of this model.
+* @return the component owning this model.
+*/
+ protected final Component getOwner()
+ {
+ return owner;
+ }
/**
* @see
org.apache.wicket.model.AbstractPropertyModel#propertyExpression()
*/
What do you think?
Maurice
Re: please help with finding and fixing stale documentation
Thanks, Eelco On 6/11/07, Remco Bos [EMAIL PROTECTED] wrote: Things like this? In Component.java, under Hierarchy: The [EMAIL PROTECTED] Component#isAncestorOf(Component)} method returns true if this Component is an ancestor of the given Component. isAncestorOf is deprecated now (oh no, my chance to patch THE Component) ;) Eelco Hillenius wrote: People, We could use everyone's help. I just came across some stale documentation, particularly RequestCycle, which stated in large caption that it is not meant for being subclassed (which is nonsense of course). I'm a bit afraid that the API docs may be stale in more places. If you (including users) have some spare time at hands, checking a couple of your favorite classes for stale API docs, and delivering a good patch[1] when you find (big) improvements would be much appriciated! Thanks, Eelco [1] http://issues.apache.org/jira/browse/WICKET -- View this message in context: http://www.nabble.com/please-help-with-finding-and-fixing-stale-documentation-tf3899742.html#a11056297 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: private inner class of compoundpropertymodel
That is exactly what i am doing right now. And i have no problem if it has to stay that way. However I thought i might be helpful for everyone extending CompoundPropertyModel, and given the fact that none of the methods in AttachedCompoundPropertyModel are final or otherwise protected against overriding i though it was an oversight. And like you said there is not much going on in that class so why not make it extendable. Well, exactly because there isn't much going on in that class: why make expose it? It will only increase the API surface and limits our future options for refactoring the things internally. Eelco
Re: Example for Border use wrong in wiki...
On 6/8/07, Mark Derricutt [EMAIL PROTECTED] wrote: Hey all, Hey Mark, Just catching up on my wicket-foo and noticed that the wiki page on using borders is invalid for 1.3 as the add/removeAll/replace/autoAdd methods are all final. http://cwiki.apache.org/WICKET/consistent-page-layout-using-borders.html Not so sure what to do with this. I think we should regard such use of borders as outdated, and that for such templating markup inheritance should be used. I updated the 'org.apache.wicket.examples.template' example in Wicket examples to show how you can achieve roughly the same things using markup inheritance and borders. However, having a base page with a border like the example states doesn't strike me as a good way to do things. I know we've been promoting that in the past, but ever since we had markup inheritence, we've been saying that that is a better technique to use. My 2c. I would appreciate it if someone else could update the WIKI, maybe taking a look at the templates example. Cheers, Eelco
Re: Example for Border use wrong in wiki...
In the case I was wanting to work with markup inheritance didn't really work right as I wanted to change the used border on the fly, in the end I just used object inheritance having the subclassed pages to call border.add() rather than add() directory (with the border defined/added by the base class as required). It works, and its good that its explicit that you're adding objects into the border, but it would also be nice to override add() and disallow the subclasses from adding to the page itself. Tbh, I haven't followed the border changes much. Maybe Juergen or someone else can comment on this? Is such use still possible? Eelco
Re: IMarkupLoader backport
Hi Juergen, The changes sound good to me. As it's mostly internal, I'd be +1 for you committing them. The threadtest project is made to facilitate tests like this. Cheers! Eelco On 6/16/07, Juergen Donnerstag [EMAIL PROTECTED] wrote: I've backported the IMarkupLoader change which removes business logic e.g. merging markup for inheritance out of MarkupCache into markup loaders. The interface is designed in a way that markup loaders can be chained, the most simple one just using MarkupParser. Another one merging the markup in case of inheritance. In addition I moved getMarkupCache from Application to IMarkupSettings but kept the method (it now delegates) in Application and deprecated it. Beside some increased flexibility in MarkupCache (see jira) I removed the sync lock which protected the hash map from parallel access. Since we are using ConcurrentHashMap for some time already, it should no longer be a reason for the sync block. Removing the sync may improve performance in situations where many markup files must be loaded (not just taken from the cache) (how much is that an issue in real life situations) but it also means that the very same markup might be loaded twice if while the first version is loaded (but not yet in the cache) a 2nd request will load the very same markup again. The code (on my laptop) will throw the 2nd version away and always use the first one. In my opinon that is acceptable, but I didn't want to commit it before I've discussed it. What would be the best test method (e.g. threadtest? a ready made web application and hhtpunit is most likely not the most suitable approach) to stress test these scenarios to make sure that we don't run into any race conditions. I guess this is especially usefull if we agree on putting it into 1.3. Juergen
Re: Releasing wicket-contrib-gmap v 1 for wicket 1.2.6
I've updated confluencene: http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-gmap So what more should I do to make the world know that we have a stable build of the wicket-contrib-gmap? Should I write to the user list and should anything else be done ? Cool Nino. Thanks. I think it's a good idea to write to the user list that you have a new release. Typically, you should make a file release, so that people can download it at http://sourceforge.net/project/showfiles.php?group_id=134391. Also, you should pin the pom.xml to a version, and see if you can do the same thing that the dojo and scriptaculous wicket-stuff projects did so that you'll be running on bamboo and have deployments on our wicket-stuff server: http://wicketstuff.org/maven/repository/wicket-stuff/. Cheers, Eelco
Re: automatically marking pages as stateless: is this really a good idea?
On 6/14/07, Johan Compagner [EMAIL PROTECTED] wrote: he just has to call dirty() when he alters a session and wants to store it That currently (in 1.3) doesn't trigger binding. Eelco
Re: automatically marking pages as stateless: is this really a good idea?
On 6/14/07, Maurice Marrink [EMAIL PROTECTED] wrote: Then i must be missing something here :s. The api doc clearly states: Yeah, you're talking about bind(), I'm talking about dirty() :) Eelco
Re: [vote] Release Apache Wicket 1.3.0-incubating-beta-2
Nope. We found some licensing issues and will soon propose a new release. Eelco On 6/14/07, Sean Sullivan [EMAIL PROTECTED] wrote: Did the vote pass? On 6/12/07, Sean Sullivan [EMAIL PROTECTED] wrote: Have the votes been counted? Is beta2 coming soon?
Re: [vote] Release Apache Wicket 1.3.0-incubating-beta-2
On 6/14/07, Francisco Diaz Trepat - gmail [EMAIL PROTECTED] wrote: Come on guys We're working, we're working. God I can't wait to get my hands on the new generics for wicket. And I can't wait to ship Wicket In Action ;) Eelco
Re: automatically marking pages as stateless: is this really a good idea?
But maybe we should remove the This method should not typically be called by clients line from bind() javadoc then? Yeah. Just did. Eelco
Re: [vote] Release Apache Wicket 1.3.0-incubating-beta-2
On 6/14/07, Francisco Diaz Trepat - gmail [EMAIL PROTECTED] wrote: Man, you know I'm gona preach it. So bring it. And I'll deliver the message... That's good to hear. We're gonna need all the publicity we can get when we start MEAP[1] in a few weeks. :) Eelco [1] http://www.manning.com/about/meap.html
Re: automatically marking pages as stateless: is this really a good idea?
On 6/14/07, Johan Compagner [EMAIL PROTECTED] wrote: ahh i see, shouldn't bind() call just dirty() then? Currently dirty doesn't result in bind being called. If we would fix (?) it so that it does, dirty would work fine, tough it would be done at the end of the request rather than immediately (don't know whether that is an issue). instead of already storing itself and all the temp objects in the session (are all those detached?) Maybe that works. We'd have to test it extremely well though. and if we want to say to the developers call bind() yourself instead of dirty() then bind should be callable twice and not: Yeah. That warning can go I guess. Eelco
automatically marking pages as stateless: is this really a good idea?
I'm wondering whether it still is a good idea to automatically mark pages as stateless if there are no 'statefull' components/ callbacks on it. It's not so much a problem that the page isn't stored - it isn't as there aren't any non-bookmarkable callbacks to it - but it can be a problem that a session isn't automatically created. See for example http://www.nabble.com/Re%3A-noob-question-about-wicket-p3903.html I'm not sure... on the one hand I like it that Wicket tries to be as efficient as it can be with storing stuff and creating sessions. On the other hand, like the referenced thread shows (if I'm right there), it can lead to situations people don't immediately understand. I'm leaning towards prefering the current situation, but I thought this would be a good time to get your opinions on this. Cheers, Eelco
Re: New WicketStuff developer: Grégory Maes
Cheers Grégory :) Eelco On 6/11/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Dear developers, Please welcome Grégory Maes among the WicketStuff developers. Grégory has filed [1]several patches on WicketStuff Dojo, and has shown a long-term interest in this project. He now deserves to apply the changes himself. Welcome Grégory! -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ [1] http://wicketstuff.org/jira/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?pid=1reporterSelect=specificuserreporter=gregory4662sorter/field=prioritysorter/order=DESC
Re: Wicket Trees Situation
a) remove the old (kinda unsupported) tree from extensions (is anyone even use it?) +1 b) move the current Tree and TreeTable* from core to extensions (sight, i know we moved it into core just recently) Don't know yet. c) move the new Tree into core. So the 'new new' tree is incompatible with the 'new' tree? Why can't you just give them different names and let them live together in a package? One of the anoying things currently is that you have to ask people whether they are working with the core or extensions tree; I bet that's as confusing for users as it is for us. Imho, it would be better to just delete the old one and keep all the trees we're gonna support in core projects together in one package so that users can find them more easily and compare their features. * I don't think it's a good idea to have a TreeTable in core anyway. We don't have DataTable in core and I'm pretty sure much more people are using DataTable then TreeTable. If I remember correctly I argued for moving everything related to repeaters to core a while ago. The initial idea was always that extensions was either for components that you rarely use in a project, or for components that need to 'mature' a bit. I don't think the latter is a very good idea anymore (we could have wicket-stuff projects instead) and imho, any component that you'd almost always use in any project could go to the core project. Datatables definitively fall into that category. And trees... well it is still my opinion that they have a place in lots of projects. Core is fine with me. Eelco
please help with finding and fixing stale documentation
People, We could use everyone's help. I just came across some stale documentation, particularly RequestCycle, which stated in large caption that it is not meant for being subclassed (which is nonsense of course). I'm a bit afraid that the API docs may be stale in more places. If you (including users) have some spare time at hands, checking a couple of your favorite classes for stale API docs, and delivering a good patch[1] when you find (big) improvements would be much appriciated! Thanks, Eelco [1] http://issues.apache.org/jira/browse/WICKET
Re: line precise error reporting: should this be on by default?
besides the fix you've implemented by clearing this metadata as soon as you can, you could also make the inspector temporarily null it out while it computes the size of things. then the inspector would give you results more in line with production sizes. The results should be good now for everything but the inspector page (which is still rendering, but the others are done). Eelco
Re: [proposal] 1.3.0 end game
On 6/7/07, Johan Compagner [EMAIL PROTECTED] wrote: can't we do an RC at the moment we graduate? (a bit more fuss then?) Also we can try to have only 1 or 2 release candidates so that the release is a bit earlier.. I think we need as many release candidates as it takes to get it free of (serious) bugs we know of. Martijn, your schedule looks fine, but I don't agree with 'give up' obviously :). A JIRA search on fix version = 1.3.x or no version gives 78 issues for Wicket core alone, and we should at least have taken a look at all of them. Eelco
line precise error reporting: should this be on by default?
Hi, I'd like to discuss the recent introduced functionality of line precise error reporting - this time specifically in it's own thread. It is a new facility that records the stack trace when a component is created and when it is added to a container. A relevant representation of the stack trace (a couple of lines) is saved as meta data on the component. It is used when you created and added a component, but fail to reference it in the right place in your markup. For example, if I remove the reference in HelloWorld.html from wicket-examples, I get an exception like: WicketMessage: The component(s) below failed to render. A common problem is that you have added a component in code but forgot to reference it in the markup (thus the component will never be rendered). 1. [Component id = message, page = org.apache.wicket.examples.helloworld.HelloWorld, path = 0:message.Label, isVisible = true, isVersioned = false] The label with id 'message' that failed to render was constructed at org.apache.wicket.examples.helloworld.HelloWorld.init(HelloWorld.java:35) The label with id 'message' that failed to render was added at org.apache.wicket.examples.helloworld.HelloWorld.init(HelloWorld.java:35) This is all nice, but comes at a price: slower execution and more memory consumption. If this was just a little bit, I wouldn't be too worried. However, in the project I'm working on, the slowdown is definitively noticable, and the memory consumption is too. For example, some of our heavier pages: deployment - development 25.1K- 680.1K 82.7K- 1.7M 47.3K- 814.6K 37.2K- 644.8K This is not a small difference, and I'm really wondering whether it is a good idea to do this by default. I find it personally anoying that the inspector pages (which I use regularly) don't give me the right information anymore. And for Wicket in general, I fear that people won't be aware of this difference (no matter how loud we shout out, most people will just miss this unless they experience a problem) and think Wicket is slow and consumes a lot of memory. I would prefer to keep this alive as a separate setting (note that it is now folded in with the IDebugSettings#componentUseCheck setting) and not have it on by default. WDYT? Eelco
Re: line precise error reporting: should this be on by default?
The memory footprint is bothering me way more than the performance hit is tbh. I would be ok with keeping this if we clear it after rendering. Eelco On 6/7/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Actually, the metadata could be removed at the end of the request, or as part of the render check (at a cost of processing time), so the memory footprint would not be noticable after the first render. The effect on the performance is not mitigated with that. The metadata currently is not cleared, so that it could be used in other exceptions as well, but that is not implemented. Possibly we could also profile the construction of the stack elements, to see how it can be improved. Currently I create stacks for both the construction *and* the addition to the component hierarchy. Maybe that is overkill? Martijn On 6/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi, I'd like to discuss the recent introduced functionality of line precise error reporting - this time specifically in it's own thread. It is a new facility that records the stack trace when a component is created and when it is added to a container. A relevant representation of the stack trace (a couple of lines) is saved as meta data on the component. It is used when you created and added a component, but fail to reference it in the right place in your markup. For example, if I remove the reference in HelloWorld.html from wicket-examples, I get an exception like: WicketMessage: The component(s) below failed to render. A common problem is that you have added a component in code but forgot to reference it in the markup (thus the component will never be rendered). 1. [Component id = message, page = org.apache.wicket.examples.helloworld.HelloWorld, path = 0:message.Label, isVisible = true, isVersioned = false] The label with id 'message' that failed to render was constructed at org.apache.wicket.examples.helloworld.HelloWorld.init(HelloWorld.java:35) The label with id 'message' that failed to render was added at org.apache.wicket.examples.helloworld.HelloWorld.init(HelloWorld.java:35) This is all nice, but comes at a price: slower execution and more memory consumption. If this was just a little bit, I wouldn't be too worried. However, in the project I'm working on, the slowdown is definitively noticable, and the memory consumption is too. For example, some of our heavier pages: deployment - development 25.1K- 680.1K 82.7K- 1.7M 47.3K- 814.6K 37.2K- 644.8K This is not a small difference, and I'm really wondering whether it is a good idea to do this by default. I find it personally anoying that the inspector pages (which I use regularly) don't give me the right information anymore. And for Wicket in general, I fear that people won't be aware of this difference (no matter how loud we shout out, most people will just miss this unless they experience a problem) and think Wicket is slow and consumes a lot of memory. I would prefer to keep this alive as a separate setting (note that it is now folded in with the IDebugSettings#componentUseCheck setting) and not have it on by default. WDYT? Eelco -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: CompoundPropertyModel#detach should check for IDetachable instead of IModel
On 6/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: All, I'm not sure the usecase is general, but in our application we have a couple of classes that implement IDetachable, but not IModel, and these are put into a CompoundPropertyModel The thing is that the CompoundPropertyModel does an instanceof check for IModel instead of the slightly more general IDetachable. Are there any objections to changing that check to IDetachable instead of IModel? Not from me. Eelco
wicketstuff server down often?
Hi, Some people were complaining that the wicketstuff.org server was down quite a bit. Anyone (Johan, Jan) has an idea why? Could it be bamboo? Or do we do hot deploys of the examples project everytime it is rebuild? Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
Ok, let's go for it then. Who's taking it up? Eelco On 6/5/07, Matej Knopp [EMAIL PROTECTED] wrote: I'm definitely +1 for metadata. The thread locals are clumsy and extremely dangerous. -Matej On 6/5/07, Johan Compagner [EMAIL PROTECTED] wrote: But i also need it for other stuff that are specific to specific implementations of certain things for example the AccessStackStore doesn't need such a thread locale but SLC does.. Fair enough. So you would use such a 'bag' in request cycle to store stuff like dirtyObjects (session)? Aren't you afraid this will open up a new can of worms (users misusing this facility rather then providing their own request cycle implementation for instance)? Isn't that the problem we also should then have on Session or Component? And i don't see it miss used a lot (at least all the examples i get from people here on the lists/web) also don't think that will happen a lot because most people (you and me included!) like to have a simple get/setter. But the problem is that we as the framework just can't do that for specific/default implementations of stuff. Then Requestcycle would become polluted. The nice thing about metadata is (compare to a pure put/get like hashmap) then they can be generified so with java5 you don't have to cast
Re: slf4j-api dep
Yeah, that sounds right. Eelco On 6/5/07, Al Maw [EMAIL PROTECTED] wrote: Hi folks, I'm pretty sure our slf4j dependencies are very wrong. I see the root pom.xml in trunk has a dependencies section that doesn't actually include slf4j-api (it's only in the dependenciesManagement). Instead, it includes slf4j-log4j12 and log4j, which surely isn't right? Isn't the whole point of using slf4j so that we don't mandate a logging framework choice? If we're going to force log4j bindings we may as well use log4j everywhere. I think we should be depending on sfl4j-api for the core projects and that's it. The examples project or test scopes may well want bindings for log4j. Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: svn commit: r544015 - in /incubator/wicket/trunk: jdk-1.4/wicket/src/main/java/org/apache/wicket/ jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/resolver/ jdk-1.4/wicket/src/main/java/org/a
On 6/4/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: * [EMAIL PROTECTED]: Author: ehillenius Date: Sun Jun 3 17:13:59 2007 New Revision: 544015 URL: http://svn.apache.org/viewvc?view=revrev=544015 Log: simplified converterlocators by removing IConverterLocatorFactoryLocatorFactoryFactory. ^ Indeed, that seems to be a very complex interface, looking at its name!!! ;-) ;-) Glad you got my joke :) Eelco
Re: svn commit: r544015 - in /incubator/wicket/trunk: jdk-1.4/wicket/src/main/java/org/apache/wicket/ jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/resolver/ jdk-1.4/wicket/src/main/java/org/a
On 6/4/07, Johan Compagner [EMAIL PROTECTED] wrote: it is harder now to specify converters on the session. (which we always had as far as i remember) because now you by pass that. Well, it's one of these things that probably started with a good idea at some point in the past, but after a few refactorings was lost again. The only thing that was really session dependent was the instance of the locator, but it was actually created by the locator factory from the application settings. Furthermore, the relevant getConverter method in Session was final anyway, so it didn't do anything in terms of flexibility for people. And I'm glad it was final, otherwise the break would have been more nasty and I probably wouldn't have done this refactor. However, I was writing about custom converters for Wicket In Action this weekend, and I just couldn't live with the complexity of this feature. I think it is enough to have one level of indirection (the locator) and a factory for the locator doesn't do anything other than increase complexity. Now, with the changes, it is very simple to customize converters (override newConverterLocator in application) and the locator pattern is flexible for any use case you might think of, including session dependent ones of you would need that (though I'm pretty sure you don't). Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
i am getting a bit tired of all those threadlocals that have to be cleaned... I already discussed this with matej and i thing we should give the RequestCycle metadata... then we can store any thing we want and it is auto cleanup Agreed. RequestCycle currently doesn't have metadata though. What's the advantage of using meta data there instead of a normal property? I think none... Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
Sorry, but I don't agree. I think it's YAGNI. Metadata is a bit uglier to read (at least the code to access it), it's harder to trace in the debugger and just less obvious. I actually don't think it would be that out of place to put the (immutable instance of) request parameters as parsed in the first step of request cycle processing in the request. Eelco On 6/4/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 6/4/07, Eelco Hillenius [EMAIL PROTECTED] wrote: i am getting a bit tired of all those threadlocals that have to be cleaned... I already discussed this with matej and i thing we should give the RequestCycle metadata... then we can store any thing we want and it is auto cleanup Agreed. RequestCycle currently doesn't have metadata though. What's the advantage of using meta data there instead of a normal property? I think none... I think the advantage of metadata is to have less tight coupling of other parts to the request cycle. We are going to use the request cycle as a Bag of stuff, which is needed during RC processing, but don't have a direct relationship to the RC, other than that it is part of the RC. Having a metadata facility in the RC will facilitate this, and not make the RC 'bloated'. Just thinking out loud. Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
But i also need it for other stuff that are specific to specific implementations of certain things for example the AccessStackStore doesn't need such a thread locale but SLC does.. Fair enough. So you would use such a 'bag' in request cycle to store stuff like dirtyObjects (session)? Aren't you afraid this will open up a new can of worms (users misusing this facility rather then providing their own request cycle implementation for instance)? Eelco
Re: Please grant me some Confluence karma
Who are the admins currently? Eelco On 6/2/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: I'd like to edit this page: http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki This is restricted to group wicket-stuff-admin and I am in confluence-users only. Thanks, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Chaining IComponentResolvers
But the component resolver is too eager. Look at the failing unit test for an example. Eelco On 6/2/07, Juergen Donnerstag [EMAIL PROTECTED] wrote: You can: MarkupParser.appendMarkupFilter(final IMarkupFilter filter, final Class beforeFilter) Juergen On 5/24/07, Al Maw [EMAIL PROTECTED] wrote: Hi, I've created a bug for this. https://issues.apache.org/jira/browse/WICKET-590 It's currently causing the build to fail - we really should fix this one way or another. Al Al Maw wrote: Hi folks, We have a bit of an issue with IMarkupFilter implementations, in that you can't currently layer two different IComponentResolvers if they both want to alter the same thing. This is currently an issue for SimplePageTest for testRenderHomePage_7, which is why that's failing. Specifically, it goes: input type=image src=test.gif wicket:message=attr-name:i18n-keytest 2/input Correct behaviour here is: - Prepend the src attribute with ../ links to make it context-relative. - Add an attribute attr-name with the appropriate i18n message. MarkupParser adds WicketMessageTagHandler is before the RelativePathPrefixHandler, so currently that wins and resolves the component first. It doesn't get added as a RelativePathPrefixHandler auto-add component, so the behaviour to prefix URLs isn't added, so the src attribute remains test.gif, not ../test.gif and the test fails. We need to somehow support chaining these things together, but I'm not sure how - it's really not obvious. I wondered if anyone out there might have any bright ideas how best to fix this. Al !DSPAM:465435e2192032419821387!
Re: Documenting Validator Resource Keys
private static final String RESOURCE_KEY = EmailAddressValidator; but AlMaw also mentioned using Classes.simpleName(...). That sounds like a better idea to me. Eelco
Re: Line precise error messages while constructing component tree
Where is it used and what does it look like Martijn? Also, could you open and resolve a JIRA issue for this so that it is part of the change log? Cheers, Eelco On 5/9/07, Martijn Dashorst [EMAIL PROTECTED] wrote: OK, I am now committing this feature. It is in! Martijn On 5/1/07, Al Maw [EMAIL PROTECTED] wrote: Martijn Dashorst wrote: I just had a small idea, to regain the line precise error message when we construct the component tree we lost in the constructor change removal. Why don't we record the stack trace in Component#Component() if we are in development mode, and put it in the meta data or in a temporary store in the request cycle? This way if something goes wrong during construction, we can display the component that is in violation and show the exact line number where the component is constructed. Something similar can be done with the 'add' method. Yes! That sounds like an excellent idea. :-) +1 Alastair -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
+1... But just to make sure: is the DEPLOYMENT configuration going to be default? Nope, DEVELOPMENT is the default (see one of the other threads this week). Eelco
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Yeah, good idea. Too bad we can't use blink ;) Eelco On 5/31/07, Al Maw [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: +1... But just to make sure: is the DEPLOYMENT configuration going to be default? Nope, DEVELOPMENT is the default (see one of the other threads this week). But I'll make the log warning larger while I'm there. Something like this should do the trick: *** WARNING: Wicket is running in DEVELOPMENT mode. *** *** ^^^*** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getConfigurationType() for more information. *** We could even log it to System.err, so Eclipse makes it red. I can't see any objection to System.err logging in dev mode. If someone deploys in production their app server admin might even come and clobber them with a big stick. ;-) What do you think? Al
development mode being the default
List, I'm still worried about the fact that development mode is our default setting. Imho, this is a mistake as the development setting is a dangerous setting for production systems: it uses more memory (for precise line reporting), is less efficient (render check) and can potentially bring down a server (when it runs out of file descriptors due to resource polling). I'd much rather have a safe default than a convenient default. Anyway, we've had endless discussions about this, and unfortunately I seem to be alone having this opinion. I'd still like to do something extra though, and Martijn mentioned a good idea, which is to have something similar to the debug link we have for Ajax when in development mode. If we would implement this idea, we could e.g. place an icon that represents this (maybe combine with the Wicket logo, wouldn't that be nice?) in the lower right corner of the browser, much like the ajax debug link is placed right now. WDYT? Eelco
Re: development mode being the default
my 2 cent would be to force the setting to be present, else the startup would fail - so the developer *has* to set it manually in any way but your and Martijn's idea sounds very nice to me. An idea would to extend the logo/ link and bring up a console where the current page is displayed together with the whole component tree, all used models and memory consumed by each of them... that would IMHO speed up developement as you see bottlenecks or wrongly implemented models very early! That could be cool yes. It would be like a development dashboard or something. Maybe we could have one clickable icon that opens this up and through it you can do things like look at the ajax logs, component sizes etc. Though the component sizes wouldn't be accurate because of the fact that you are running in development mode... :) Eelco
Re: development mode being the default
And we have that component: the inspector bug... We moved it to wicket-examples because it was a security risk. Sure. But if it would be part of the 'development dashboard' it wouldn't be a security risk as we don't want people to run in develpment mode in the first place, right? Eelco
Re: A new proposal for Wicket Portlet support
Wow, that was a long mail. It's a bit unfortunate that many of the abstractions in Wicket actually came from the idea of separating the servlet and portlet environments, and that we won't need those now, but I guess that's the way it goes. Most of those abstractions proved to be useful anyway. I think I agree with the proposal for the large part. For the details, I think it is better to discuss actual code. The goal you are setting seems to be high, but if you can pull it off, it sounds excellent! One thing about the implementation you're working on. Do you think you can provide a test project with a configured portlet environment (e.g. based on JetSpeed) so that it is real easy for people (including the other team members of Wicket) to check it out and let our debuggers loose on it? For me, and at least a couple of others, the fact that it is quite some work to set a portlet server up, configure it to run a (Wicket) application etc has been the greatest stumbling block in trying to help out and review. If you can provide an environment that is really easy to set up, I bet there will be quite a bit of interest and it would increase the changes of succes this time considerably. Cheers, Eelco
Re: multiple IComponentResolvers
Ah, yes. I missed that one. Just came back from a vacation :) Eelco On 5/28/07, Johan Compagner [EMAIL PROTECTED] wrote: AlMaw also already looked at it: http://www.nabble.com/Chaining-IComponentResolvers-tf3803758.html#a10763056 is juergen around? johan On 5/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Not sure whether someone was already looking at this, but currently org.apache.wicket.markup.html.basic.SimplePageTest#testRenderHomePage_7 is failing. The problem is that input type=image src=test.gif wicket:message=attr-name:i18n-keytest 2/input is resolved by WicketMessageTagHandler and thus not by RelativePathPrefixHandler. I'm not sure what the best solution is to this, but my first question is whether it is really a good idea to create auto components for all the tags we find that need to have the relative path fix in the first place. I understand we need to do this dynamically because of URL mounting and stuff, but can't we use for instance IResponseFilters for this problem instead? If I didn't overlook something, and the above thought is correct, the same goes for wicket:message tags. Do they really need to be resolved to components? I'm afraid those auto components can add up quite a bit when it comes to memory usage. WDYT? Eelco
Re: Wicket portlets (current status)?
This is soon to be picked up by Ate and possibly some others. He plans on submitting a proposal on this list early this week. Do you plan to work with this Michal? Or have you already been working on it? We definitively need a couple of people testing and contributing this time; it'll be the third try for portlet support. Eelco On 5/28/07, Michal Palička [EMAIL PROTECTED] wrote: Hello, what is the current status of the Wicket's portlet support? There used to be the wicket-portlet-examples module in the WICKET-2.0 branch. The branch has been discontinued. It seems that there is no portlet support in the current trunk. What are the plans regarding the portlet support in Wicket? Thank you in advance mp.
Re: Wicket portlets (current status)?
two or three weeks a go I had a look on the current source for the portlet integration. They are currently stored at the wicket stuff project. This source do not compile with the wicket 1.3 release (this was two or three week ago). I play around with the source and get some examples of the normal examples work in the liferay portal. I stop working, because I had difficults to show images in the portlet. I had a look at the sources to understand what the problem is. During looking at the source I see some tricky (tricky from the viewing point of a portlet container -- correctly from the point of a servlet container) points in the wicket 1.3 sources. This points must be solved to get wicket running in a portlet container (e.g. a portlet container has no HttpRequest, a portlet container has no path and so on, typecast from WebRequest to HttpWebRequest or getting the path of the application, which is not available in a portlet container). Up to now I had now time to write down the points which will be difficult to solve and currently the source of 1.3 will be code freezed so this stuff could only be solved in future releases. The architecture of wicket looks like that the protocol over which wicket will be use should be plugable. Is this right? It should be yeah. Around Wicket 1.0 we introduced a couple of extra abstractions to facilite portlets. I'm pretty sure we've had basic portlet support up for some time, so it should be possible to fold this in for 1.3 again. The main issue now is that we need enough people with enough energy to work on it and this time finish the job. Eelco
Re: Build Failed
Look, having a failing unit test only works when it is indeed fixed ASAP. This is a known issue for a least a few days now, and there isn't even any serious discussion on how this might be fixed, so atm a quick fix seems unlikely. Also, though the problem can be anoying, it's not a show stopper in my book. The issue[1] was filed as minor, though I just bumped it up to major as it is a structural (low level) framework bug which imo are more serious bugs in specific components. I'm commenting the failing unit test now, so that it doesn't block the rest of our development. I don't disagree with committing a failing unit test every now and then to get some attention, but an issue related to that either should be fixed within one or two days, or the test should be commented and the issue marked as a known one, possibly bumbing up the priority to make sure no-one forgets it. Eelco [1] https://issues.apache.org/jira/browse/WICKET-590 On 5/28/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 5/28/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Mmm actually I don't really agree, making the build fail should not be intentional. We could have some convention like for example naming the failing unit test methods after bugTestXXX() instead of testXXX() to make it obvious that the test does not run and that there is a bug. I really disagree with this: it is already hard to make a bug reproducable. Often the person reproducing the bug does not know how to solve it. The person having *time* to solve it, usually doesn't have time to build a test case for it. Having failing test cases on trunk is obviously not good, but it is better than not having testcases, or testcases that don't get run (which is what you are proposing). If you commit a failing testcase, it is necessary to make sure dev@ is notified, so people know it is not their fault and that it is intentional/necessary. It is also necessary to fix the thing pronto, but if it were that easy, the fix would've been committed together with the test case, wouldn't it? Trunk is for development: at any given time the test can fail. They just need to get fixed quickly. Note that this is not an excuse for not running and fixing the unit tests before a commit. Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: Build Failed
When you comment such a failing test, then at the very least add the class and method to the issue. Otherwise it will be HELL to find the test again. Also, ensure that the method is commented with the JIRA issue number. The test was already mentioned in the JIRA issue and of course I added a TODO with a reference to the JIRA issue in the test. I agree that having dirty laundry for weeks gives a very bad smell, but that doesn't mean the laundry should be thrown away or completely hidden from sight. Sure. But it isn't as there is a JIRA issue for it. Submitting a failing unit test is not only a way to get attention: I can invest time to create unit tests that fail, but I can't always solve the problem or have the time to solve it (creating a unit test that fails for a particular bug is *HARD* and time consuming). So I see it also as a way to contribute. Sure, but still unless they are intended to be fixed within one or two days, they should not block further builds unless the issue is really, really grave (in which case they should be marked blockers and in which case I would be fine with keeping the tests active). Also, please note that when we move to JDK 1.5, we can put this discussion to rest, as we can annotate our tests to not run (JUnit 4.x). They will then be reported as skipped tests and not end up in oblivion. TestNG is also a possibility, but I overheard that the maven surefire plugin is not up to par. That's perfect news. Exactly what we need in such cases. Eelco
