Re: Commons logging is evil
Eelco Hillenius wrote: But Al, maybe you want to share what problems this would fix for you? TBH, I rely on so many other libraries that use commons-logging in most of my projects, that this isn't specifically going to fix anything for me. However, I've enough hours dealing with nasty commons-logging classloader pain to feel that the world would be a better place without it, and that we should help to hasten its demise. Even once you have commons-logging set up properly, with all the JARs in the right place, it hangs onto things internally, preventing your webapp's classloader from being garbage collected, and leading to your container OutOfMemorying when you hot-deploy things. You need to call Introspector.flushCaches() and all the rest of it in an attempt to fix this, and the whole thing just isn't obvious or nice. SLF4J is. So yeah, I guess this isn't terribly important, but I figure it'd be nice. Al
Re: Typos in BodyTagAttributeModifier javadoc
Jean-Baptiste Quenot wrote: The javadoc is weird because the end tag is written as a start tag . See attached, it's against branch 1.x. Thanks. Applied on 1.x and 2.x. Al
FilePageStore getWorkDir() override
Hi Guys, I think we should add a method "protected File getWorkDir()" to FilePageStore so people can override things in code. Having things always go into javax.servlet.context.tempdir isn't convenient for me, and ideally I'd configure this stuff from Spring, anyway. ;-) Sound good? Al
Re:
Juergen Donnerstag wrote: what do you prefer? wicket:div? wicket:span? wicket:tag? anything else? I dislike both div and span, as this construct is really nothing to do with either, and they just make it confusing. To me, at least, is meaningless. I like Johan's most, as one generally uses a WebMarkupContainer for this, so that's most consistent. Al
Re:
Martijn Dashorst wrote: The only problem I have is that it will not work in any browser for Ajax replacements. I know this is not the targetted usecase, but I think this will confuse (novice) users. I think this should be fairly obvious to most people. In order for AJAX replacement to work, the element needs to have setOutputMarkupId(true) anyway. So if a novice understands that, then they'll understand why this doesn't work. If you're worried, write an example for it (that's where 95% of people learn things from) and put a big comment in the markup next to it. bla foo Will work in IE afaict, but But it's not valid XHTML (or even HTML 4), so we really shouldn't encourage that. :) Al
InternalFrame in 2.x
FYI wicket.markup.html.link.InternalFrame was empty: http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/src/main/java/wicket/markup/html/link/InternalFrame.java?view=log It's been replaced by InlineFrame, so I've removed it. Al
Re: VOTE: include WICKET-218 in 1.2.5
Igor Vaynberg wrote: include https://issues.apache.org/jira/browse/WICKET-218 in 1.2.5 I've only seen this once before, but why not? +1
Re: VOTE: remove Page.before/afterCallComponent()
Frank Bille wrote: On 1/22/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: this api is simply too fragile. any custom requesttarget impl has to call this in order for it to be consistent, and if its not consistent its useless. +1 because of fragile api. +1 This is currently biting me for AJAX stuff. Al
Re: Packaging our releases
Martijn Dashorst wrote: Our current Wicket release distribution consists of several zip files, [...] Wheee, this is almost getting religious. :) Maven 2 users just, errr, use Maven 2. :) So for the others, I'd have thought it simplest to have a single zip/tgz download containing the wicket sub-project JARs plus all their deps. You can easily automate this using the mvn assembly plug-in. Maven 2 will generate a nice dependencies report, which we should probably stick up somewhere, so if someone is not using Maven 2 and wants the smallest set of dependency libraries, they don't need to go hunting around to work out what they need. -1 on all wicket sub-projects wrapped into single JAR. Spring started out this way and has now fragmented into sub-project JARs, and they wish they'd done it like that from the start. Most people will only use wicket and wicket-extensions. (I'd also suggest renaming wicket to wicket-core, as it makes it more obvious there are other modules available, but whatever.) Al
Re: Getting rid of filterPath?
Igor Vaynberg wrote: On 1/27/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: * you repeat yourself and often forget to keep in sync with filter mapping maybe we should just parse web.xml and rip out the mapping. we already have an xml parser :P Yeah, I've just thought about doing that, and it certainly works, although it's a bit ugly. However, I've thought a bit harder, and I'm not convinced it's actually necessary. I think we can resolve it from the inbound request. I'll post more on this later, when I've played with it a bit more. I'll be putting various other fixes in today for all this. Al
Session.dirty() and Stateless pages
Hi, There's code in SecondLevelCacheSessionStore.SecondLevelCachePageMap which checks if a page is stateless when it is put() and doesn't bother calling dirty() if so. However, dirty() is always called from various constructors (for example the Session constructor calls setLocale() which calls dirty()). This doesn't seem right. Should stateless pages never have dirty() sessions? If that's the case, should we fix these and have a call to Session.dirty() trigger a bind()? I've just fixed Session.bind() so it actually persists the session, which it didn't before (this normally doesn't matter, but causes oddness if you redirect from a stateless page to a stateful one, expecting bind() on the stateless page to propagate the session to the stateful redirect page like the javadoc says it will). Thoughts welcome. Al
Re: About WicketFilter refactoring
Igor Vaynberg wrote: we already have a pull parser in wicket, why arent we using that? Hmmm. Do we? It seemed like it was written for HTML. The code is probably trivial - feel free to improve it, or point me in the right direction to. Al
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
Eelco Hillenius wrote: On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: +1 although almaw is working on his datepicker, and the one in wicket-stuff is prob 75% there, so we should have a good replacement rsn :) That would be cool, and I think a good match for that project as well. Might be easier to find and stuff. -0 :-) Yes, Joda time is nice, but I want the date picker in core or extensions where it belongs, not in yet another module, so I'm writing one with no Joda-time deps. It's just not necessary IMHO; the date manipulation problem isn't a faff, it's writing the Javascript that is. Al
Re: VOTE: wicket-datetime (was: VOTE: add Joda time as a dependency)
Eelco Hillenius wrote: Al, are you seriously working on date picker you want to contribute to Wicket? Yes, but it's really not very far along yet and I don't think we should hold up 1.3 for it (certainly not the first beta at least). It's relatively easy to make a datepicker if you have either mootools or prototype available. These clash with each other and are both popular. It's a hassle supporting a date picker for each, so the current strategy it stripping out the bits of mootools that I actually need, namespacing them so they can't interfere with anything else, and the writing something from scratch. I don't trust javascript to get the locale and date formatting right for me, so I'm doing that in Java with some
Re: wicket-1.3
nilo de roock wrote: I downloaded wicket-1.x mvn install does not work ( see below ) Is there something wrong with the pom.xml, perhaps? Please read and follow the instructions on the wiki, which point you to this document: http://svn.apache.org/repos/asf/incubator/wicket/branches/wicket-1.x/wicket-parent/README.TXT Regards, Al
Wicket Stuff Wiki update + shout out to all you lurking contributors...
Hi all, I've given http://wicketstuff.org a bit of love. Let me know what you think. Better yet, all you wicket stuff contributors please contribute to the wiki. :) When adding a top-level project page, make sure you add an appropriate label so it is listed on the root wiki page. We currently have, "javascript", "java" and "example" categories. Best regards, Al
Re: Move parts of documentation from wiki to WICKETxSITE
Martijn Dashorst wrote: Why? It is part of our documentation. It is maintained by wicket core devs. There is no reason for it to be at the general wiki. The purpose of our core site is to add content to it, not keep it a 2 pager. Hmmm. I edited this before I was a core developer. If your community can help keeping docs up to date, then I suggest letting them. And that is best done by keeping things on the wiki. Unless someone wants to volunteer to be the official documentation collator and editor, we're best off letting everyone contribute as they see fit, I've have thought. That means leaving as much stuff on the wiki as possible. IMO the only docs that should live on the web site proper are things that will either never become out of date or are very important to keep up to date and are therefore unlikely to stagnate. Examples: - Official introduction to Wicket. - Jumping-off points for other documentation, etc. - Where the IRC channel and mailing lists live. - Where things are in Subversion. - Guide to building the project from source. - How to become a committer. In short, if a document can legitimately be improved by a community member, it should live on the wiki. In my eyes, this definitely includes migration guides. Al
Maven 2 project structure with wicket-parent
Hi. At the moment, you need to run wicket-parent's "mvn install" with a profile (-Pjdk1.4) to get it to build things if you have a JDK5 install. This isn't terribly obvious, to say the least. I'd like to propose we move the JDK1.4 modules in that profile out into the main build, as we *always* want to build these, regardless of whether we're on JDK5 or not. If you're on JDK5 it'll then build the 1.4 modules and the 1.5 ones, which is definitely the desired behaviour IMHO. You'll then be able to run Maven 2 from wicket-parent and have it do the "right thing" whether you're on JDK 1.4 or JDK 5. I've fixed the license headers for everything, too, with this you'd be able to go like this to have a fully-working set of modules in your local repository: svn co https://svn.sourceforge.net/svnroot/wicket/branches/wicket-1.x/ cd wicket-1.x/wicket-parent mvn install ...and have it all Just Work(tm), even when you don't have anything in an existing repository - it should bootstrap itself properly. Let me know if there's some reason to object to this, otherwise I'll commit it shortly. Al
Re: Maven 2 project structure with wicket-parent
Martijn Dashorst wrote: -1 I have set this up so that I can run with jdk 1.4 and build the 1.4 projects *USING* only 1.4, and ONLY the 1.5 projects when I run using 1.5. This is to prevent any 1.5 stuff from entering our project. But I don't think it does that exactly - let me explain... This is the current situation: Running a 1.4 JDK (java -version says 1.4, JAVA_HOME >> a 1.4 JDK) = - mvn install builds the 1.4 modules. - You can't build the JDK 5 modules. Running a 1.5 JDK (java -version says 1.5, JAVA_HOME >> a 1.5 JDK) = - mvn install builds the 1.5 projects _only_. If you don't already have the 1.4 modules mvn installed, it all falls over. - To build the 1.4 modules, you need to issue a -Pjdk1.4, which causes the base 1.4 projects to built ***but using your 1.5 JDK***. If you have any 1.5 JRE library dependent code in there, it'll build regardless and the build will succeed when it probably shouldn't. Therefore to guarantee that you're not introducing 1.4 code, you need to compile the base modules using a 1.4 JDK, ***regardless of how this is set up***. We are already making sure no JDK5 code creeps into the 1.4 modules by building them on wicketstuff.org/bamboo using a 1.4 JDK. The only thing we'd affect if we changed things as I detailed, is that if you're running a 1.5 JDK it'll all build nicely in a single step without any magic Maven profile switches, which would be much more convenient for everybody. IMHO, asking people to install two different JDK versions just so they can build the code is ridiculous - people won't do it and will just use -Pjdk1.4, because why shouldn't you? People who care (core developers) should probably have both JDK versions set up in their IDE with each project on the appropriate version anyway, so the code should not be broken. If it is, our continuous integration server will provide sufficient safeguard against people accidentally checking in code that breaks things that this just isn't an issue. Regards, Al
Re: Maven 2 project structure with wicket-parent
Frank Bille wrote: Yes I agree with Martijn. We really want to catch if any 1.5 stuff is in 1.4projects. But Al, if you can get maven to do that (forcing 1.4 in 1.4 projects) it would be nice. I don't know if maven can do that, though. See my other reply. The thing that matters is what your JAVA_HOME environment is set to. If you're running Maven using a JDK5 on the command line, it doesn't matter what you do - it won't magically pick this up. Which is why we have continuous integration, where we actually run Maven with different JDKs depending on the project. So I'd strongly like you to look at this and understand what I'm saying and reconsider, as I think it'd be a big improvement, with absolutely no difference in picking up backwards-compatibility issues. Al
Re: Maven 2 project structure with wicket-parent
Alastair Maw wrote: Frank Bille wrote: javac -source -target ?? I'm almost sure this work, but I don't know if you can tell maven to use those (it worked with ant AFAIK) Yes, we already do this, obviously. :-) Only now I look, actually, we don't. :-) We certainly should do, but that's only half the story, as I've explained. Al
Re: Maven 2 project structure with wicket-parent
Alastair Maw wrote: Frank Bille wrote: javac -source -target ?? I'm almost sure this work, but I don't know if you can tell maven to use those (it worked with ant AFAIK) Yes, we already do this, obviously. :-) Only now I look, actually, we don't. :-) We certainly should do, but that's only half the story, as I've explained. Al
Re: Maven 2 project structure with wicket-parent
Al Maw wrote: javac -source -target ?? I'm almost sure this work, but I don't know if you can tell maven to use those (it worked with ant AFAIK) Yes, we already do this, obviously. :-) Only now I look, actually, we don't. :-) To clarify: We do for wicket, but not for wicket-extensions and some others, which we should. Sorry to all for the amount of spaminess on this thread. Al
Re: Maven 2 project structure with wicket-parent
Johan Compagner wrote: first of all will javac -source 1.4 -target 1.4 always do the right thing? It does for us, at least. And then i thing about the changes in StringBuilder/StringBuffer I guess StringBuilder will not be used but StringBuffer will Sun deliberately design it so that you can compile code on newer JDKs to run on older ones. The optimiser has specific version-dependent knowledge about things like that. Are we really using a different jvm now on our Bamboo server? Last time i checked it always did that with java 5 Yes, we are. This is a significant advantage of Bamboo over Continuum (the other being the absence of so many bugs). ;-) Look at (for example): http://wicketstuff.org/bamboo/build/admin/buildConfiguration!default.action?buildKey=WICKET1X-WICKET Which has the build JDK to use. I'm only trying to simplify and automate things. :) Wouldn't it be nice to go mvn release:prepare ... mvn release:perform and have it build all the 1.4 and 1.5 modules, tag them in SVN, release them to the repo, etc? Regards, Al
Re: Maven 2 project structure with wicket-parent
Igor Vaynberg wrote: i guess almaw played around with it w/out telling us :) We have some projects that are, err, "significantly" more complex than Wicket in terms of Maven 2 builds, class version compatibility (which gets interesting when you bring RMI classloaders into account) and stuff. javac even goes so far as to make sure it mimics the previous behaviour of the evaluation of a class literal causing the class to be initialised (which it doesn't do in Java 5, but does if you do a -target 1.4 using the 1.5 javac). Al
Re: Maven 2 project structure with wicket-parent
Martijn Dashorst wrote: I have been thinking about forcing the JVM in the plugin section of the 1.4 projects. This is possible, but it is highly installation dependent, and therefore not implemented (yet). I was hoping for a 1.4 section in the pom, which would then load the corresponding platform or machine dependend settings from either the settings.xml (local configuration) or the defaults from some obscure maven config file. Hmmm. I could be wrong (there's a lot to know about Maven 2), but I don't think this is yet possible. I'm pretty sure Maven compiles against the rt.jar that's beneath your the directory specified by your JAVA_HOME environment variable, and there's no way to override that. I guess we could fork an Ant task that required -Djava.home.14 and -Djava.home.15 properties, then forked two different Maven 2 builds, but that all seems deeply ugly and inelegant. Note that provided your dependencies don't use JDK5 classes, javac -target 1.4 won't somehow statically link against JDK5 code. It's the nature of Java that all the linking is done at runtime. Provided all your code compiles using -target 1.4 and you didn't use the 1.5 rt.jar it'll all be fine. (Obviously you can check the rt.jar issue when you do a release by compiling/testing the tagged version against a 1.4 JDK, if that's the way you want to do it. I'd hope Eclipse and/or Bamboo would tell you this much sooner provided you'd set them up properly.) So a full release complete with JDK1.4 compatibility check would be something like: Quick check in bamboo/eclipse to make sure it all compiles against rt.jar from 1.4. mvn release:prepare svn checkout http://.../tags/foo foo cd foo/wicket-parent mvn test cd ../.. rm -rf foo mvn release:perform Sorted. If mvn test goes wrong, delete the tag, fix, and start again. It's up to you at the end of the day, though, I guess. :) Al
Re: [Wicket-dev] 2GB sources?
nilo de roock wrote: The following snippet is part of ./wicket-parent/pom.xml false src/main/java ** **/*.java false src/main/resources ** **/*.java This seems to be the rootcause because after removing this the problem no longer occurs. I would like to ask one of the maven specialists to have a look at this. When this issue is solved I will commit the other changes I have made to the pom. Aaah. Can you try replacing the ** with **/* and tell me if that fixes it? Al
Re: Single-page applications: bad idea in Wicket ?
Matej Knopp wrote: First of all, the hybrid urls would fix the refresh problem, but definitely won't fix ajax back button. I don't see much we can do about supporting back button with ajax. That can be possible with full blown ajax framework (like backbase), but wicket was never meant to be it. I see multiple problems: 1 - the urls of page links have to be changed. Fixing href of anchors could be possible (although a big ugly hack if you ask me), but we have lot of url in generated javascript. I don't see easy and reliable way to fix it. I need to look into this in more detail, but do we generate URLs in JavaScript that matter when things change? If so, we surely already need to be reloading that JavaScript file? So it won't work in an AJAX world anyway, if you see what I mean. If the URL is generated within the AJAX requestcycle, then it should be fine - we can append the # reference there. Another problem is the page url. It would reflect old version and there is nothing we can do about it. So if we supported ajax versioning, imagine this situation. User comes to a page, interact with it and creates 20 new versions. Then he for some reason refreshes the page and gets those 20 versions reverted. This is IMHO _much_ worse than not versioning at all. Yeah, you need to update the URL and add a #versionNumber anchor to it, so this doesn't happen. IIRC, Safari has issues with this - it doesn't update the history properly so this approach doesn't work well with that browser. Only way we can alter url in javascript is to change the hash (part of url after #). Unfortunately, the hash doesn't get submitted to the server, so on next request the server can not find out what the hash was. This is the approach Google use no some of their apps to fix the back-button issue - you keep a version number after the hash. You can obviously push this over in your AJAX requests, but you need it to work for non-AJAX stuff too, as you say. The things you need to fix are pretty much anything with a URL in, right? So we could just walk the DOM on each AJAX round-trip and add/change any src/link/href/whatever to have a version number in it as a parameter? I don't think that's that much of a hack, fwiw. See above for Javascript thoughts, although more investigation required on that (I don't know if you might have a component that is generated in page version 3 need to maintain a URL to a component generated in page version 2 - I don't think this makes sense, in which case this is all probably pretty straightforward). I'm not sure how all this interacts if you genuinely want to link to a page using an anchor. :) http://www.contentwithstyle.co.uk/Articles/38/ is definitely worth a read. Al
Re: shutting down wicket-stuff lists?
Eelco Hillenius wrote: How do you feel about shutting down the wicket-stuff lists (wicket-stuff-develop@lists.sourceforge.net, [EMAIL PROTECTED])? I think traffic is too low to really justify having separate lists, and traffic likely will be of interest to subscribers of the core lists as well. If we just shut them down, it'll be less confusing to people. I'm +1 on this. Slightly embarrassingly, I didn't even know they existed. :-) Al
Vote to remove final on Component#getEscapeModelStrings()
Hi, Why is getEscapeModelStrings() in Component final? It would be nice to be able to override this, for situations such as highlighting labels with null model objects or similar. Sure, I can do the escaping myself, but it seems tedious. So, vote to make it non-final. +1 :) Also, shouldn't it be called isEscapeModelStrings() in common with other boolean-style getters. I shouldn't imagine many people call this outside the framework. Rename in 1.3/2.0 and note in the changelog? +1 :) Regards, Al
Re: shutting down wicket-stuff lists?
James McLaughlin wrote: > It might be worthwhile to keep wicket-stuff-develop so that when it > comes time to coordinate a release or encourage > wicket-stuff-developers to make some changes (like mavenizing their > projects) we won't pollute wicket-user. But for this to work, we would > need to make sure all the project maintainers are subscribed to it. > I'm ashamed to say, i don't think that I am. I think we should use the news section of our shiny new confluence and encourage people to subscribe to the RSS feed instead, but that's just me. Al
Re: Vote to remove final on Component#getEscapeModelStrings()
Jonathan Locke wrote: +1 however, should not be renamed. it is in the javabeans spec to use "is" and "get" interchangeably for booleans as it makes sense case- by-case. since "isEscapeModelStrings" doesn't make any sense in english, the "get" form (which makes some sense) is preferred IMO. Fair enough. Everything else in there starts with "is" for booleans. I think it's just that I find getEscapeModelStrings somewhat ugly and it's not very discoverable given most of the other "display options" start with "is". We could deprecate it and make it isHtmlEscaped() instead? Or is that too web-specific and therefore in violation of things? I'd point out that currently it's a final method in Component in the getModelObjectAsString() that does the work, doing HTML-specific markup. I'd imagine if you want to write a set of components to render WML or something that you'd want a different escape mechanism in there? Besides, you might want to override this and use Spring's HTML escaping, as it's much better than ours. I'm now thinking maybe we should have an IStringEscaper which you can provide in IMarkupSettings. :-) Any thoughts on making this nicer and less in violation of our current base components/web components split? Al
Re: VOTE: add Jean-Baptiste Quenot as a comitter to Wicket
Martijn Dashorst wrote: On 2/8/07, Frank Bille <[EMAIL PROTECTED]> wrote: Finally.. I'm tired of all his patches :) meritocracy according to Wicket: when we get tired of your patches we'll add you to the team :) Worked for me. :) +1 (binding) (Provided he learns how to run unit tests before he commits stuff.) :) Al
Re: Vote: add jhighlight dependency to wicket examples for 1.x and 2.x
Eelco Hillenius wrote: I'm fine with adding anything for examples if it is covered by the proper license. So, that's a +1. Same. I'm using com.uwyn.jhighlight on our internal pastebin, and find it much better than the one on papernapkin.org. IMHO, highlighting should be done server-side, not in JS. It's a nice lib, just works. +1 Al
Re: some more urls things..
Johan Compagner wrote:
i was running the threadtest App1Test1 which does this
"/app1?wicket:bookmarkablePage=one:
wicket.threadtest.apps.app1.Home",
"/app1?wicket:bookmarkablePage=two:
wicket.threadtest.apps.app1.Home",
"/app1?wicket:interface=two:${iteration}:link::ILinkListener",
"/app1?wicket:interface=one:${iteration}:link::ILinkListener",
"/app1?wicket:interface=two:${iteration}:link::ILinkListener"
i altered some behaviour in the link.onclick. But then i noticed that the
last 3 calls where never called!
it is this code first thing in WicketFilter.doGet(_
String relativePath = getRelativePath(servletRequest);
// Special-case for home page - we redirect to add a trailing slash.
if (relativePath.length() == 0 && !Strings.stripJSessionId(
servletRequest.getRequestURI()).endsWith("/"))
{
String foo = servletRequest.getRequestURI() + "/";
servletResponse.sendRedirect(foo);
return;
}
so when the url doesn't end with / then we send a response to xxx/
What about the params!
On a production site, this will never happen - once you are into the
system all the URLs like that are generated with trailing slashes.
Shouldn't the test be there if there are request params then it is not a
request to home??
We should probably rewrite this so that it redirects including the
params. I'll go fix that now. It's important that we have a trailing
slash for reasons that are complex - if you don't have a filter path it
all goes wrong otherwise.
Note that Wicket won't generate URLs like this without a / on the end of
them, so this is really only a problem with unit tests that fake all
this stuff in (or possibly if people have bookmarks with params in their
browser that they expect to work when upgrading from 1.2.x to 1.3, which
probably won't work anyway for other reasons).
Al
Re: Migration guide and datepicker
Eelco Hillenius wrote: Btw, a link to the wicket-datetime project would be good there as well. [...] See the 1.3 migration page, now all fixed. Al
Re: svn commit: r505710 - in /incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket: behavior/HeaderContributor.java markup/html/IHeaderResponse.java markup/html/internal/HeaderResponse.
[EMAIL PROTECTED] wrote: Author: knopp Date: Sat Feb 10 08:02:31 2007 New Revision: 505710 URL: http://svn.apache.org/viewvc?view=rev&rev=505710 Log: HeaderContrbutor cleanup backport Modified: incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/behavior/HeaderContributor.java incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/markup/html/IHeaderResponse.java incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/markup/html/internal/HeaderResponse.java This doesn't work in the world of relative URLs. I'm going to forward-port the changes to 2.0 later this week and I'll clean this all up when I do that. We really need some unit tests for this. :-/ Al
Re: [WICKET-63 Create wicket-parent build for wicket 2.0] solved?
Martijn Dashorst wrote: Can this one be closed? http://issues.apache.org/jira/browse/WICKET-63 I thought Al was working on this? Eelco did this, I've only updated it to make it a proper multi-module build. I expect the Wicket 1.3 build will be in a state of flux while we learn how we should best configure that during the initial 1.3 release cycles. We should learn from that and apply it to 2.0 later. It seems to work find for now, so I'm closing that one. Al
Re: VOTE: turn custom serialization on by default
Eelco Hillenius wrote: We're having a bit of an issue where Johan is developing custom serialization for Wicket to make it faster and smaller (same thing really). +1 to turn it on ASAP for the betas. We really can't have the 1.3 release go out without this being solid, especially if we're going to try to bandy performance figures about (people will test with the default set-up, and that had better work). Al
Re: Summer of Code '07
Martijn Dashorst wrote: Can we define some assignments for the Summer of Code? Would be nice to have one or two students work on for example WML, XUL or any other part that we feel to be in for some work? Summer of Code is great if we can find something nice to do, but I'm not sure WML or XUL are it, to be honest. Although it's a nice idea to have something well defined to work on like this, do we really need either WML/XUL in Wicket? The existing portlet support doesn't seem to be well used, and provide maintenance headaches, even though it's actually quite close to the standard Web* stuff we have. WML is pretty much dead for anything other than small sites that sell mobile content or provide simple info. Barely anyone is building complex sites in it - everyone just uses XHTML with appropriate mobile stylesheets. Let's not try to shoehorn Wicket into WML development when there's not really any demand for it. It will make life harder for no good reason. I suspect the same is true (possibly more so) of XUL. Please remember that just because you can add features, doesn't mean you should. Look at Netscape in its open source heyday - they started adding every last little feature anyone had a patch for, without stopping to consider if it was actually useful. It's as much about what to leave out as it is what to include. And I think we should leave WML and XUL out. Alastair
Re: i think i have asked/proposed this before: IBehavior.isEnabled();
Johan Compagner wrote: Any objections now? (for 1.3 and 2.0) Because you can't remove a behavior from a component and now you also can't dynamically disabled one either. So thats a bit annoying. Yeah, defn. would be useful. +1 Al
Re: strange code in WicketFilter
Xavier Hanin wrote:
Whlie browsing the wicket1.x code, I've stumble upon a piece of code which
seems strange in the WicketFilter class:
public void setServletMode(boolean servletCompatibilityMode)
{
this.servletMode = true;
}
Shouldn't the servletMode be assigned to servletCompatibilityMode?
Yeah, that is a bit odd. It's a hangover from developing something else.
The entire method is no longer used - I've removed it. Thanks.
Al
Re: [VOTE] All examples in one project, Java 5 required
Martijn Dashorst wrote: [ ] No, I object! Java 1.4 examples are the thing I live and die for [X] Yes, make one examples project to rule them all, and by all means, make it Java 1.5 dependent Al
Re: multi-file upload component
Igor Vaynberg wrote: a few people were talking about the need to have a component that can upload multiple files as opposed to creating a bunch of fileuploadfields. [...] [...] looking forward to feedback. Feedback from me is: Oooh, shiny. :-) Al
AjaxSubmitButton in Panel inside ModalWindow in a Form
AjaxSubmitButton in a ModalWindow using a Panel as content doesn't work if the ModalWindow component is itself embedded in a Form. The issue is that ModalWindow tacks its content on as a on the element, which places it outside the original element. If we fix ModalWindow to inject its Panel content into the middle of the page where the component actually lies, then all the CSS is messed up - it uses position: absolute, which will work fine until you put the ModalWindow component inside something that is position: relative; If you add a to the ModalWindow's Panel, then the nested Form resolution stuff removes the element because it thinks it has a parent , even though when it's rendered it's actually outside it. I'm not sure how to fix this, or even if it's possible to. Maybe we can make the nested form hierarchy check stop traversing its parents at ModalWindow boundaries, and require than things inside a ModalWindow have their own Form? Al
Re: VOTE release 1.3beta
Igor Vaynberg wrote: this vote is to release 1.3beta +1, but only after I've made the Maven 2 stuff nicer, so we can make this repeatable (WICKET-228). Al
Re: [VOTE] All examples in one project, Java 5 required
Martijn Dashorst wrote: I propose to make the examples projects Java 1.5 dependent. Everyone said yes, so I assume this is going ahead. Has there been any progress on this? I'm wanting to fiddle with Maven 2 build procedures and things prior to getting the 1.3 beta out, and if you have tons of outstanding commits with this, it may be tricky. :-) Al
Re: roadmap
Johan Compagner wrote: i really hate that roadmap, really i do. [...] So you really want quickly 1.4 after 1.3 and i guess 1.3 is completely in maintenance mode pretty much directly because if we start working on 1.5 you really don't want 1.3 anymore Absolutely. As soon as we've pushed 1.4 out, full steam ahead on 1.5, with 1.3 very much in bug-fix-only and encouraging people to switch to 1.4 ASAP. That means that people that all do 1.3 stuff now are going to 1.4 anyway (especially because it is also not java5 yet again) Yes. But they get to do a really complicated Model refactor over the course of a few weeks, rather than Right This Second. If we have an agreed roadmap, then the users will even see this coming and be able to make their own mind up as to whether they want to split their upgrade effort into two chunks, or just wait a little longer 'til 1.4 comes out. Releasing so quickly is in my eyes a bad thing. And i really don't want to release as much under the incubating flag (i sort of already don't want to do that for 1.3!! but i can live with that if we really really have to) Another fly in the ointment is that we will need to move to the org.apache.wicket namespace at some point. If we have both JDK 1.4 and JDK 1.5 branches that we're trying to keep in sync, merging will be slightly more annoying due to the import mismatch, although I guess that's fairly minor. The main point here is that we probably won't graduate from incubation until we switch to this namespace. Would people be happy to do this for 1.3? It's a pretty trivial update for people - just global search and replace on "import wicket." to "import org.apache.wicket." (with the exception of things in wicket-stuff like the datepicker). We should maybe start a vote on this. We will certainly have to do it in 1.4, no matter what that looks like. so i am -1 on this release cycle. what you call 1.3 and 1.4 should be in my eyes 1.3 and why you call 1.5 is in my eyes 1.4. Yes, that's right. I'm just splitting 1.3 up into two smaller chunks in an attempt to make things happen sooner and be more manageable. If we put the model refactor into 1.3 then I reckon it will be ready for release around about the same time that 1.4 would otherwise be, or possibly even later. You see, this split would allow us to parallelise the two things that I can see taking a while; getting an Apache-grade release out, and having users migrate to the new Model code. If we don't parallelise it, I think we'll end up doing things in a more sequential fashion and the whole process will take longer. Once we have a good solid release process, rolling out a 1.4 will be negligible effort. It therefore wouldn't surprise me if it took longer to do a 1.3 with the model change in it than to get to a 1.4 under this proposal. Of course, if you're happy to delay rolling out a 1.3 beta for yet another month, then that's fine. I can tell you that I'll be busy porting my models for a week or so and not testing things/writing build code if we push the refactor in right now. :( Give people a big chunk and let that sink in for quite a while. Dont go releasing like a mad man. I'm not convinced. Release early, release often. BTW, I'm on holiday the week from 19th -> 26th, so won't be around to help with releases and things during that time. Al
Re: almaw's new build-test branch
Martijn Dashorst wrote: How does the nested projects work with Eclipse? afaiu eclipse's workspace needs to be a flat structure... You just run mvn eclipse:eclipse at the top level and import only the bottom-level projects (use File | Import and uncheck three boxes, I guess). This isn't a big deal. You don't need to have the pom projects imported into Eclipse as Maven 2 builds. If you want the top-level project in there for convenience of editing the site stuff, add the src folder from it instead of the root. afair the release plugin tags/branches each project separately. This is not good imo. We don't release each project separate, but the whole branch in one go. I've used the release plugin in the maven 1 days and it was nothing but a big pain in the rectum. So, I've just tried to fake out a release in this branch. If it weren't for the failing unit tests I'd have some tags to show you, but the long and the short of it is that we will end up with two tags - one for the JDK 1.4 directory and one for the JDK 1.5 directory. This is the result of having to run two releases because you want to use two different JDKs, and there's not much we can do about it. The alternative is to write a little script which goes and updates elements in the POMs, tags everything in SVN, then does a fresh checkout and then a "mvn -DperformRelease=true deploy" in each of the jdk-1.* directories. This would actually be pretty simple. If it's the preferred approach, I'll have a go at that. It'd be nice to be able to do it with just Maven, though. I've used the release plugin in the maven 1 days and it was nothing but a big pain in the rectum. The Maven 2 version is a ground-up rewrite, so I don't think that's relevant. Last thing for the moment: inherit the top parent from org.apache/apache/4.0, this way you get the organization and some other things for free. Last time I tried this it bought almost nothing because the various plug-ins it pulled in were alpha versions that didn't even work. :) But yes, we should probably do that. Why is the root pom version 1-SNAPSHOT and the jdk* poms 1-3-incubating-SNAPSHOT? Can't we just put the version in the root pom and be done with that? Depends. If we need to use two different JDKs, we need to release the jdk-1.4 and jdk-1.5 trees separately. At this point, you'll need to have released the parent already. The thinking was that this is easily done by just having a static version number, so effectively you can release the parent independent of the rest of it. It's not going to change much, after all (especially if we remove the contributor list). Another thing I want to remove from the pom's are the contributor, developer list. These are rather dynamic and don't add much. The poms don't need to change and be released when these things are modified. Fine. This is in the root pom only in the new branch, so would be an easy fix. I thought we originally put stuff in there to keep the Apache folk happy. If not, let's ditch it. It gets out of sync and bloats things annoyingly. You can probably auto-generate something similar from JIRA, anyway. Al
Re: almaw's new build-test branch
Martijn Dashorst wrote: On 3/8/07, Frank Bille <[EMAIL PROTECTED]> wrote: Ok, so http://www.nabble.com/Maven-2-project-structure-with-wicket-parent-tf3175043.html#a8812638is still a problem? Yep still a problem. But the biggest problem with getting all stuff built in one go (*not* the release, but locally) could be resolved by adding an 'all' profile that lists all modules. If you don't mind building against 1.5, then that would solve the 90% usecase. The new structure no longer requires profiles: To just build JDK 1.4 stuff, execute mvn in the jdk-1.4 folder. To just build JDK 1.5 stuff, execute mvn in the jdk-1.5 folder. To build both, execute mvn in the root folder. Getting it all into Eclipse: mvn eclipse:eclipse in the root. File | Import > Choose the root folder. Check the ones you want and click OK. The release build, and our bamboo should always explicitly use JDK 1.4 for wicket, extensions datetime and spring. The eclipse project settings should also explicitly set a 1.4 profile to remove the possibility to use 1.5 stuff. Yeah. See previous threads on how mvn eclipse:eclipse will set you up for 1.4 compliant code (no generics, etc.) but still use the default (probably JDK 5) JRE libraries to build against. Hence the utility of bamboo. Al
Re: almaw's new build-test branch
Martijn Dashorst wrote: On 3/8/07, Al Maw <[EMAIL PROTECTED]> wrote: Martijn Dashorst wrote: The alternative is to write a little script which goes and updates elements in the POMs, tags everything in SVN, then does a fresh checkout and then a "mvn -DperformRelease=true deploy" in each of the jdk-1.* directories. This would actually be pretty simple. If it's the preferred approach, I'll have a go at that. It'd be nice to be able to do it with just Maven, though. I think just doing a svn cp branches/wicket-1.x tags/wicket-1.3.0 svn cp tags/wicket-1.x releases/wicket-1.3.0 svn switch releases/wicket-1.3.0 find . -name "pom.xml" | xargs sed -e "s/version>1.x-incubating-SNAPSHOT/version>1.3.0-incubating-beta1/g" mvn4 -DperformRelease=true install site assembly:assembly mvn -DperformRelease=true install site assembly:assembly svn commit -m "Release 1.3" scp `find . -name "*.zip"` people.apache.org:~/public_html/release-1.3-incubating-beta1 scp `find . -name "*.gz"` people.apache.org:~/public_html/release-1.3-incubating-beta1 scp `find . -name "*.md5"` people.apache.org:~/public_html/release-1.3-incubating-beta1 scp `find . -name "*.sig"` people.apache.org:~/public_html/release-1.3-incubating-beta1 We can automate the scp stuff as part of the -DperformRelease=true. We should surely also be copying doing a proper deploy, not an install, so that we copy the JARs for the projects to apache's Maven repo, so they can be synced up with repo1.maven.org? I'm still in favour of using the release plug-in if we can, as it scps the site to the right place, doesn't let you tag if there are test failures, and all the rest of it. We also need to sign the release using gpg, as I understand there is a maven plugin for that as well. OK, I'll see if I can look into this at some point. Al
Re: mvn eclipse:eclipse
Johan Compagner wrote: that does something more. Please make a doc in every wicket project pointing this build process out! :-) If we move to my proposed direcotry structure we don't need this any more. Time to start a vote, methinks. :-) Al
VOTE: Move modules around to make releasing easier in 1.x branch (and rename branch).
As detailed in the thread "almaw's new build-test branch" I've been thinking about how to make the release process work more smoothly. I've restructured how 1.3 is parented, etc. in the branch "al-test-wicket-1.3.x". You can see how it looks here: http://svn.apache.org/viewvc/incubator/wicket/branches/al-test-wicket-1.3.x/ Advantages: - It massively simplifies the pom.xml files and reduces redundancy and duplication, and removes the potential for the configuration of the various modules getting out of sync. - It's really obvious which projects need JDK 5 and which don't. - We will hopefully be able to use the Maven 2 release plug-in for the jdk-1.4 and jdk-1.5 bits and make everything more automated. - We don't need -P profile switches to build things any more. - Getting the whole shooting match into Eclipse is now: - One command to check it out. - One command to build the Eclipse .project, etc. files. - Three clicks in Eclipse to import all the projects, which will then all depend on each other correctly. - Removes the wicket-parent project, which is a bit mystical and lots of people don't discover by themselves. Disadvantages: - Everyone will need to update their workspaces. So, please vote: [ ] Yes, change the 1.x branch so it looks like that. [ ] No, don't restructure it! That's a rubbish idea! We could also take this opportunity to rename the 1.x branch to 1.3.x. If you voted yes above, please also vote: = [ ] Yes, rename the branch to "wicket-1.3.x" at the same time so I only need to set my IDE workspace up again once. [ ] No, don't rename the branch, we'll postpone that until we release a beta, or a 1.3.0 final, or something. Given it's a bit of a faff for everyone, if this does go ahead I will post a time when I will move stuff at least a couple of days in advance so people can get their outstanding commits in, which should make it easy for everyone. If you were to have outstanding commits when things are moved, svn will keep the changes in orphaned files so you can move them across manually to the new layout. It's just a little less convenient. Al
Re: VOTE remove sandbox from branches/trunk in favor of top level directory
[x] yes remove branches/*/sandbox Al
wicket-threadtest has moved
Martijn has recently moved things around in the 1.x branch. We didn't think wicket-threadtest should be a released artefact, so it's now living in wicket-1.x/testing/wicket-threadtest. Al
Re: [Vote] Al's repository restructure
Jonathan Locke wrote: this is SO much better. thanks almaw! Thank Martijn, who actually put in the elbow grease to make it all work (site templates, etc.). I just faffed with some pom files. Anyway, glad you like it. :-) Al
Re: 1.x test errors?
Gwyn Evans wrote: Ignoring the Velocity warnings (anyone else get them?), I get 5 test errors - See attatched. Yeah, I also get these. Guess we ought to look into why they're there. The stuff is defined in the parent pom, so I'm wondering if it doesn't propagate down to the children. Perhaps if we put in a element and redeclared them it'd work? I'll look into this at some point. Al
Re: Release 1.3 - status
Martijn Dashorst wrote:
I've been working on the release and have come to a last point: how to
package stuff.
The default src assembly is IMO moot: it packages each project without
context. It seems to me that a zip containing the sources for all
projects is better, as it makes it one package as a whole
The default bin assembly doesn't include jar dependencies so our users
have to download all the dependencies themselves.
You can do this with the stuff in the assembly
descriptor though.
/lib
false
I don't know how this should behave, to be honest. Most libraries
package their dependencies if the licensing allows that. Wicket doesn't
have that many dependencies, so I don't see that this is a bad option.
The only issue with that is that if we provide a single TGZ for the
whole release then it's not obvious which dependencies belong to which
project. The examples project, in particular, has a bunch of extra
dependencies. I guess we can document this somewhere, suggest people use
Maven, or come up with some way to package things as lib/wicket/,
lib/wicket-extensions/, etc.
The sites generate for the most part in the jdk-1.4 section. They
still require a site.xml (and I included for most a index.apt which
has an incubation disclaimer). The site.xml is needed otherwise the
maven site plugin doesn't use our skin.
Yeah. Are the site.xml files the same for every project? If so, we might
be able to set it up to use the same one for all the projects, using
something like ${user.dir}/src/site.xml
(where user.dir is the system property for the current working
directory). This would break running the site plug-in from the
subdirectories, but people won't be doing that, will they?
I've reinstated the profiles, but with a twist: now if someone runs
maven using a JDK-1.4 it will only build the JDK-1.4 modules.
Otherwise all projects are built (including the JDK-1.4). You'd get
errors if you try to build the JDK-1.5 modules using a 1.4 java
version, but I'd rather avoid those as well.
Makes sense.
In the root pom we need to define where the snapshots and distribution
repository live. I set them to my p.a.o. (people.apache.org) account,
but I don't think that the root pom should have that information. I'd
rather have the directory/deployment url be in my local settings.xml
file. Then everyone can be the release manager.
Yeah, we should use properties for these, I guess. Unless actually
having these hardcoded will be useful, as you'll be able to tell where a
particular release was deployed to in a way you wouldn't with random
properties.
TODO:
- decide the final assembly formats
Presumably both zip and tgz. I wonder if we should split it into two
assemblies - one for JDK 1.4 and one for JDK 1.5? I think I vote for
some kind of grouping rather than providing 10 zips to download.
- fix jdk-1.5 sites, and the multi-module site build (links between
projects don't work)
Hmmm. You should be able to link to things in the site.xml using:
And:
Doesn't this work?
- see if maven release plugin is a good fit (doubt that)
Yeah, me too. We want to tag both jdk-1.4 and jdk-1.5 at the same time,
under a single tag. This doesn't fit with the mvn4, mvn5 build process.
Al
Re: Adding a PageNotFoundPage?
Jean-Baptiste Quenot wrote: * Johan Compagner: What do we now when a bookmarkable page is asked for but not found? just the 404? with nothing else? Currently we log an error and return the error page with status code 500, that's BAD! Err, if you use a filter then you fall through and do whatever the container does. Please don't break it for the filter case. Al
Re: Adding a PageNotFoundPage?
Igor Vaynberg wrote: erm no the important thing is that what we do is set the 404 header that way the filter chain knows its a 404 and can handle it properly as opposed to us happily streaming our own error page with a 200 Errr, no. :-) We don't want to stream anything at all in the filter chain case. Currently WicketFilter looks to see if things match a Wicket page/request with isWicketRequest() (line 118 on WicketFilter) and leaves it the hell alone if it doesn't. Don't you go changing that to serve a 404 instead, or everyone's other servlet mappings and static resources and things will break. You can modify doGet() to serve a 404, that's fine. By that point, the filter thinks it's a Wicket request, so you probably should. In the filter case, one can achieve all this by mounting a 404 page, and using to point to it. It certainly seems to cover all my use cases, and that way you can serve the same 404 page for non-Wicket URLs. I don't think you ever get 404 pages if something has passed the isWicketRequest() check. Al
Re: Adding a PageNotFoundPage?
Igor Vaynberg wrote: errr, no! what if iswicketurl does return true? maybe you do ?bookmarkablePage= some.FooBarPage and FooBarPage does not exist. what to do then? we should just set the header to 404 and let the chain continue Hmmm. Shouldn't we leave it all alone and just let the request fall through to lower in the chain? I'm pretty sure that's what we should do. The default servlet will then look for a resource called ?bookmarkablePage=some.FooBarPage on the filesystem under the context root, fail to find it, and 404 that. You'll need an set up in the filter case either way, I'd have thought. Al
Re: Adding a PageNotFoundPage?
Igor Vaynberg wrote: well yes, but jbq was saying we should create a special page for when this happens. and i disagreed. and then you disagreed with me, so are you agreeing with jbq? I'm agreeing with you. This stuff is so much easier to do on IRC / IRL. :) Well, it should probably be like this: If you're using WicketServlet, serve a 404. If you're using WicketFilter, let it fall through and let the container deal with it. agreed As the container will do it for you. In a way it won't for the servlet, obviously. If you're using WicketFilter then you need an mapping in your web.xml Unless you're happy with the default container 404 page. In which case, fine. I think I confused filter and servlet darn So, erm, yeah. :-) I'm not against a PageNotFound page for the WicketServlet. I think the user should provide one for the filter case if they're not happy with the default container one. I guess we need a setting for a servlet-based one so the user can customise it. Al
VOTE: New roadmap and desicion on the future of Wicket 2.0 branch
There's been a lot of comment and discussion lately about the future direction of Wicket, and the trunk/2.0 branch in particular. We've done some hard thinking and we now have a roadmap for the future. When What Now Backport the Model refactor and other remaining non-JDK-5 features from 2.0 to the 1.3.x branch. Soon Release a 1.3.0-beta to the community. Soon Release a 1.3.0-rc1. [2, 3, etc. if required] A bit later Release a 1.3.0 final. Fork a 1.4.x branch from the 1.3.0 release. Apply generics and other JDK-5 features to 1.4.x branch. This will make 1.4.x look just like 2.0, but with the same constructor/add logic as 1.2.x/1.3.x currently have. "now" ~= right now. "soon" ~= within a couple of weeks. "A bit later" ~= within a month or so. We will discontinue support for 2.0 once we have branched 1.4.x and added generics support into it, at which point the 2.0 branch will be renamed in subversion and left to stagnate. As already thrashed out in various discussions, this will achieve the following: - Provide a migration path for 2.0 users within a month or so, so they are not left high and dry. 1.4.x will be basically the same as 2.0 currently is, only with the constructor change backed out. - Give us two branches that will be very similar apart from JDK 5 features, and thus make it easy to back-port fixes/features from the 1.4 branch to the 1.3 branch. - Give us a 1.3.0 beta that is feature-complete, and thus make upgrading from beta >> RC >> final releases trivial. Best regards, Al
Re: VOTE: New roadmap and decision on the future of Wicket 2.0 branch
We've done some hard thinking and we now have a roadmap for the future. +1 Al
Package rename heads-up for wicket-1.x branch
Hi folks,
As part of our ongoing incubation process at Apache, we're going to be
renaming the core wicket package from "wicket" to "org.apache.wicket"
shortly (not quite sure when yet, but soon).
If you're developing against the subversion wicket-1.x branch, you'll
need to change your imports accordingly.
If you're on a box with find and sed (i.e. Linux, MacOSX, BSD, etc.)
then you should be able to execute this in your project's directory:
find . -name "*.java" -exec \
sed -i -e 's/import wicket\./import org.apache.wicket./' {} \;
If you use Eclipse you can do something like this(*):
- Make sure your project is backed up, etc.
- Select the project you wish to update in the navigator.
- Go to the "Search" menu and click "File".
- Type "import wicket." (without the quotes) into the
"Containing text:" field.
- Click "Replace..."
- Set the "With:" field to "import org.apache.wicket."
- Click "Replace All".
If someone feels like telling IDEA/NetBeans/ other IDE users how best to
accomplish this, by all means tell us. :-)
You may need to fix some imports back if you use contrib modules from
wicket-stuff or elsewhere.
Best regards,
Alastair
(*) I tried to cook up a refactoring script for this, but it seems
that's not really supported in a project-independent way for package
renames, which is a pity.
Re: Retry: [VOTE] Release wicket-1.3.0-incubating-alpha
Frank Bille wrote: Ok +1 on releasing to IPMC. I don't expect them to just eat it without comments. I guess the biggest point will be the license header aspect. I would therefor appreciate if we could agree on what I have wrote in the wiki[1] or else reach consensus on what our opinion is on this. Frank [1]: http://cwiki.apache.org/confluence/display/WICKET/Wicket+1.3.0+incubating+alpha+1 Agreed. I think "But we have also decided..." on the wiki is a bit, err, strong. It makes us look like we're ignoring the ASF's rules when we're actually trying to keep everyone happy. Thoughts: - It can probably be argued that properties files don't have any degree of creativity in them. - I don't really see why we don't put a license header in the examples/test HTML files. It wouldn't kill us. You could argue that the test HTML files are nearly all auto-generated, but given we do the autogeneration, it would be pretty easy to add in. Good work, Martijn - it's much appreciated. Al
Re: [VOTE] release wicket-1.3.0-incubating-alpha (new version)
Martijn Dashorst wrote: I've tried to remove some issues from our previous round. The less issues to cope with, the better. - just one target directory still eludes me, the rest have been eliminated - jetty jars are now provided, and not put in the examples war - build artifacts now go into target/dist and target/m2-repo (making the build process self contained and more platform independent) So another round, another vote. [ ] Yes release the damned thing already [ ] Yes, this is the last time I vote on this... My + and 1 keys show signs of wear [ ] No, I found this issue and you'd better fix it, or ... Yeah, +1 to release it to the incubator folk. I can't verify the ASC sigs, 'cos I don't have your public PGP key. Other than that, things I've checked are: - Tests all pass. - mvn install works with nothing in local repo already. - SHA1 and MD5 sums are OK. - Tarball and ZIP have exactly the same contents. - The links in the README, etc. text files work/exist. I might write a script to automate as much of the above as possible. Things I haven't checked: - That the JAR files in /lib all work. - That the wicket-examples WAR works. Obvious those are quite important. :-) If someone else can verify those, then I'm +1 on the rest of it. Some minor quibbles, none of which stand in the way: - There's a src/dist folder that's empty. - I'm not sure we need the release.sh script in the actual zip/tgz. - It'd be nice to make the eclipse.sh script executable (for the tar.gz, at least). You can do that with a 0755 element in a element in the assembly descriptor, but it's hardly a big deal. - I think we should move the EclipseCodeFormat.xml from wicket to the top-level parent folder. - While checking all this, I noticed that the JIRA link on http://incubator.apache.org/projects/wicket.html doesn't work (it needs an http:// on the front). Thanks Martijn! Al
Re: svn commit: r528350 - in /incubator/wicket/branches/wicket-1.x: jdk-1.4/wicket/src/main/java/org/apache/wicket/ jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/ jdk-1.4/wicket/src/
Jon,
This appears to have broken the world. Please can you at least do a
basic test against wicket-examples when you make changes like this?
The unit tests for wicket-examples are currently failing with 50x
errors, I presume due to this.
Issue is related to session creation. I'm using a stateless log-in page
if that makes any difference.
Al
[EMAIL PROTECTED] wrote:
Author: jonl
Date: Thu Apr 12 21:27:24 2007
New Revision: 528350
URL: http://svn.apache.org/viewvc?view=rev&rev=528350
Log:
Moved call to session factory to Session.get(), removed session setting on PageMaps, moved session factory to Application and removed getDefaultSessionFactory.
Modified:
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/AccessStackPageMap.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/Application.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/IPageMap.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/IRequestCycleFactory.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/PageMap.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/RequestCycle.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/Session.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/HttpSessionStore.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/MockWebApplication.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/SecondLevelCacheSessionStore.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebApplication.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebRequestCycle.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebSession.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/AbstractRequestCycleProcessor.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/session/ISessionStore.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/tester/WicketTesterHelper.java
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/test/java/org/apache/wicket/model/StringResourceModelTest.java
incubator/wicket/branches/wicket-1.x/jdk-1.5/wicket-examples/src/test/java/org/apache/wicket/examples/panels/signin/CookieTest.java
Modified:
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/AccessStackPageMap.java
URL:
http://svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/AccessStackPageMap.java?view=diff&rev=528350&r1=528349&r2=528350
==
---
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/AccessStackPageMap.java
(original)
+++
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/AccessStackPageMap.java
Thu Apr 12 21:27:24 2007
@@ -124,12 +124,10 @@
*
* @param name
*The name of this page map
-* @param session
-*The session holding this page map
*/
- public AccessStackPageMap(final String name, final Session session)
+ public AccessStackPageMap(final String name)
{
- super(name, session);
+ super(name);
}
/**
Modified:
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/Application.java
URL:
http://svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/Application.java?view=diff&rev=528350&r1=528349&r2=528350
==
---
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/Application.java
(original)
+++
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/Application.java
Thu Apr 12 21:27:24 2007
@@ -536,6 +536,11 @@
}
/**
+* @return Request cycle factory for this kind of session.
+*/
+ protected abstract IRequestCycleFactory getRequestCycleFactory();
+
+ /**
* Gets the [EMAIL PROTECTED] RequestLogger}.
*
* @return The RequestLogger
Modified:
incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/org/a
Re: svn commit: r528350 - in /incubator/wicket/branches/wicket-1.x: jdk-1.4/wicket/src/main/java/org/apache/wicket/ jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/ jdk-1.4/wicket/src/mai
Eelco Hillenius wrote: On 4/12/07, Al Maw <[EMAIL PROTECTED]> wrote: This appears to have broken the world. Please can you at least do a basic test against wicket-examples when you make changes like this? Should be fixed now. Great, thanks Eelco. Al
Re: [proposal] adopt animate.js into wicket-extensions as our core effects library
Martijn Dashorst wrote:
On 4/13/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I'm mainly thinking nice but do you have any concrete plans
(components, behavior) for it?
I think just a behavior (or class) with some examples. The philosophy
of the library is to not create 200 classes for every effect known to
man, which is what moo, rico, dojo and scriptaculous do. This library
is an enabling library for effects.
We could use it to provide an AccordionPanel without constraining you to
prototype or moo or whatever.
We could easily provide framework support for fade-from-yellow
highlights (the standard draw-attention-to-updated-items AJAX idiom).
A simple Java API to invoke transitions with AjaxRequestTarget would be
really cool (we could provide some predefined ones, I guess).
target.appendAnimation(component, new Highlight());
target.appendAnimation(component, new Highlight().setColour("#ff"));
target.appendAnimation(component, new FromClass("yellow"));
target.prependAnimation(component,
new Animation[] {
new ToClass("wider"), new ToClass("taller")
}
);
That sort of thing. :-)
Al
Re: WebClientInfo throws exception when User-Agent is not set, but should it?
Martijn Dashorst wrote:
The following code is in WebClientInfo's constructor:
public WebClientInfo(WebRequestCycle requestCycle)
{
super();
HttpServletRequest httpServletRequest =
requestCycle.getWebRequest()
.getHttpServletRequest();
userAgent = httpServletRequest.getHeader("User-Agent");
if (userAgent == null)
{
throw new WicketRuntimeException("unable to read header
'User-Agent'");
}
properties.setProperty(ClientProperties.REMOTE_ADDRESS,httpServletRequest.getRemoteAddr());
init();
}
If I'm not mistaken, browsers can suppress headers, amongst which the
User-Agent. Shouldn't the WebClientInfo support this?
It's rare, but sometimes you get real requests that don't have this
header. I could have sworn I opened a bug for this a while back.
Yes, IMHO this is broken - it causes failures for a small minority case
that's really not obvious. At the very least, the WebClientInfo
constructor should throw a checked ClientInfoNotAvailableException or
similar.
Al
Re: [vote] Move trunk to branches, promote wicket-1.x to trunk
Martijn Dashorst wrote: This is a vote to promote 1.x to trunk and demote trunk to branches with an appropiate label, and do it soon (as in now) [x] yes, switch them [ ] no, don't switch them And yes, make sure the branch name for 2.0 has "discontinued" in it. Al
Re: [vote] Name the release after 1.3
Charlie Dobbie wrote: [x] Apache Wicket 1.4 (Non-binding vote) Having declared 2.0 a dead-end, you shouldn't release anything with the same version number within six months at least - there's too much potential for confusion IMHO. Not to mention tutorials and code snippets that are floating around labelled "for Wicket 2.0". Yikes. I have to agree with this, much as it may be a pain for the book. :-/ I'm inclined to adopt the full-on Apache versioning scheme, which means: - Non-backwards compatible updates are x.0.0 - Backwards compatible updates are x.y.0 - Forwards/backwards interchangable patch versions are x.y.z What about 3.0.0 with a move to this versioning scheme thereafter? Regards, Al
Re: WICKET-40 Parameters of nice URL's pages with 'sensitive' characters
Jean-Baptiste Quenot wrote: Take it as my favourite one to be fixed then, and don't mind the serious tone, I'm always serious ;-) Yes, needs fixing. Am looking into this right now. However, we agreed not to release beta before all important refactorings are merged, but on the other hand we should go on because we'll always find some more refactoring to do ;-) This isn't a refactor. It's a bug fix. No code will need to change, unless you're triple-escaping things. If you are doing that, you know this bug exists, hopefully. Al
Re: Line precise error messages while constructing component tree
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
Re: [VOTE] Propose Wicket for Graduation
[x] Yes, propose Wicket for Graduation [ ] No, Wicket is not ready to graduate Al (sorry, been away for a couple of days).
Re: Hibernate Validator integration?
Ryan Sonnek wrote: I'd appreciate anyone interested to take a look and let me know what they think. You currently setRequired(true) on a NotEmpty, which isn't what that intends at all. It's purpose is to make sure a String is length > 0, or a collection has more than zero elements. Similarly, the Length element can and probably should be using a StringValidator for a TextField and not setting maxlength. Maybe it should do both. ;-) It strikes me we probably need a: Hibernate Validator Attribute + Component type -> Validator mapping ...because what sort of validator you want to use will be dependent on the component type. Al
Re: poll: validators and behaviors combined... contribute or IS-A?
Eelco Hillenius wrote: I guess my point is made. I'll back off for a bit and see what other people have to say about this. Anyone's opinions are welcome, and core developers, please contribute so that we can make this decision in consensus. I wouldn't call it IBehaviorProvider if it's tied into validators. ;-) Perhaps call it IBehaviorProvidingValidator and make it extend IValidator, so it's more obvious what's going on and what the interface is for. That said, I think I prefer this approach to IComponentFacet for the following reasons: - When a user goes CTRL+SPACE in Eclipse on their component, having an add(IComponentFacet) method will be much more confusing and less discoverable than add(IBehavior) and add(IValidator) methods. As a newbie I'd be thinking, "what the hell is a facet?" whereas at least "validator" is pretty self-explanatory. - Conceptually, users are adding a validator. The fact that it adds a behavior to help prevent invalid input or add feedback or whatever is secondary to its main purpose, which is validation. It therefore makes more sense to me that it's an IValidator first and foremost. Putting IBehavior on a level footing with that doesn't make much sense to me if I'm wearing my user hat. - It's nice and simple - I don't have to think hard about whether it might suck or not. ;-) Regards, Al
Re: Hibernate Validator integration?
Bruno Borges wrote: What if we want to have in one IValidator, more than one IBehavior? just wondering... :) This could be important and usefull, if in one Validator two _very simple_ behaviors are needed, and they need to be keep separated with each other. []'s We could have a method that adds behaviours, rather than provides them. Instead of: public IBehavior newValidationBehavior(Component component) Have: public void addBehavior(Component component) At that point, I'm wondering if there's any point calling it addBehavior() - surely we should just have a much more generic hook instead, where you can add IBehaviors, or do anything else you want? Something like: public void onAdd(Component component) So Component#add(IValidator validator) calls validator.onAdd(this); What do you think? Al
Re: relative URL refactor (maybe?) and request target regressions
Jonathan Locke wrote: > i'm getting this exact problem too. is there a JIRA issue for this yet? Sorry. I'm fixing this right now. ;-) Al
Re: relative URL refactor (maybe?) and request target regressions
Hi folks, Can you do a SVN up on trunk and see if this is now fixed for you? Al Jonathan Locke wrote: > > i'm getting this exact problem too. is there a JIRA issue for this yet? > > > n8han wrote: >> Previously I was able to mount bookmarkable paths including a slash in >> 1.3.0 snapshot, but now ajax request targets on those pages are failing. >> There is no exception logged; the browser redirects to >> resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js. >> >> A separate problem is that request targets (ajax and regular) are no >> longer being processed under mounted bookmarkable URLs as they were up >> until now on 1.3.0. A mount like /code have targets like /code?wicket:... >> , but not they are /?wicket: as in Wicket 1.2. Is this intentional? >> >> Nathan >> >
Re: relative URL refactor (maybe?) and request target regressions
n8han wrote: > Previously I was able to mount bookmarkable paths including a slash in 1.3.0 > snapshot, but now ajax request targets on those pages are failing. There is > no exception logged; the browser redirects to > resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js. As mentioned in the other e-mail, this should be fixed now. It was caused by a small oversight in some refactoring, for which I apologise. > A separate problem is that request targets (ajax and regular) are no longer > being processed under mounted bookmarkable URLs as they were up until now on > 1.3.0. A mount like /code have targets like /code?wicket:... , but not they > are /?wicket: as in Wicket 1.2. Is this intentional? Yes, this is intentional, and it shouldn't be causing any problems (although it may get in the way of hybrid URLs, but we can fix that post-1.3). The reason for this is primarily due to how AJAX HeaderContributions work. CSS/JS/whatever needs to be relative to the URL for the page that is being viewed. When an AJAX request comes in, if the URL for the AJAX request at the same "../ depth" as the page view itself, then we just construct resource links relative to that, and it all works. Otherwise, we need to maintain state for the depth of the original page render. This is possible, but less easy, and I don't want to mess with this prior to the 1.3 release. Al
Re: relative URL refactor (maybe?) and request target regressions
Al Maw wrote: > n8han wrote: >> Previously I was able to mount bookmarkable paths including a slash in 1.3.0 >> snapshot, but now ajax request targets on those pages are failing. There is >> no exception logged; the browser redirects to >> resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js. > > As mentioned in the other e-mail, this should be fixed now. It was > caused by a small oversight in some refactoring, for which I apologise. > >> A separate problem is that request targets (ajax and regular) are no longer >> being processed under mounted bookmarkable URLs as they were up until now on >> 1.3.0. A mount like /code have targets like /code?wicket:... , but not they >> are /?wicket: as in Wicket 1.2. Is this intentional? > > Yes, this is intentional, and it shouldn't be causing any problems > (although it may get in the way of hybrid URLs, but we can fix that > post-1.3). > > The reason for this is primarily due to how AJAX HeaderContributions > work. CSS/JS/whatever needs to be relative to the URL for the page that > is being viewed. When an AJAX request comes in, if the URL for the AJAX > request at the same "../ depth" as the page view itself, then we just > construct resource links relative to that, and it all works. Otherwise, > we need to maintain state for the depth of the original page render. > This is possible, but less easy, and I don't want to mess with this > prior to the 1.3 release. Turns out this is actually required. I've patched in an extra param in RequestParameters for the URL depth of the original page, and updated the interface listener request encoding stuff to cope. Hopefully we should now be able to trivially support hybrid URLs in future and everything should now work as intended. ;-) Let me know if you see any oddness. Al
Re: relative URL refactor (maybe?) and request target regressions
n8han wrote:
>
> Al Maw wrote:
>> Turns out this is actually required. I've patched in an extra param in
>> RequestParameters for the URL depth of the original page, and updated
>> the interface listener request encoding stuff to cope. Hopefully we
>> should now be able to trivially support hybrid URLs in future and
>> everything should now work as intended. ;-)
>>
>
> I'm not sure if we're talking about exactly the same thing there; I'm still
> getting ajax requests to /?wicket... from a mounted page, with the current
> trunk. But I found some Apache proxy magic to make that ok with my setup:
>
> RewriteCond %{QUERY_STRING} ^wicket
> RewriteRule ^/$ http://localhost:8280/ [P]
>
> (I have an application that thinks it has a root context, but I only proxy
> requests to it from certain paths.)
>
> So that's fine, but modal window is not happy on those sub-pages. It opens
> correctly now, but buttons and links off of it fail with a redirect to a
> blank page as was happening before with ajax links from the page itself.
I've quite probably just fixed that, literally as you posted. Update and
try it now.
Apologies for the slight URL instabilities over this weekend. I've been
trying to get our URL handling in shape for the forthcoming 1.3 release,
and just after beta1 and over a weekend seemed to be a good time to do
that. Hopefully everything is now in good shape.
Regards,
Al
Re: [VOTE] Code Freeze for RC
Jonathan Locke wrote: > I'd like to propose that we freeze the codebase now so we can work on > bugs over the next few weeks for a Release Candidate. This is quite > critical timing NOW for people who have been promised that a mid-June > or early July launch of a commercial product on Wicket would be workable. > I know I am one such person, but I can also point to other such promises > made by the dev team (myself, eelco, others) on this mailing list. > > This said, I'm not so hell-bent on shipping that I'd argue for a freeze > before fixing something that's truly important. But we do really need to > wrap this up as soon as humanly possible so we can ship a FINAL product > in just a few very short weeks. So, here's the vote: > > [ ] I'm ready to freeze the codebase for RC bug fixing. > > [ ] Hold your horses, we REALLY MUST (fill in the blank) __ first. > > NOTE: If someone comes up with a good reason not to freeze, we can > revote with that on the ballot. [x] I'm ready to freeze the codebase for RC bug fixing. Caveat: I'll try to get WICKET-6 done tomorrow, but it doesn't really matter that much. ;-) Regards, Al
Re: Bug in AbstractAjaxDefaultBehavior causes AjaxSubmitLink to hang
Bart Molenkamp wrote: > Hi, > > I believe that there is an endless loop in AbstractAjaxDefaultBehavior. > On line 247, the statement: > > parent = getComponent().getParent(); > > should be changed to: > > parent = parent.getParent(); > > It was introduced in revision 537689 to fix WICKET-472. > > > Can someone fix this oneliner, or should I create a new issue for it?? Yes, my fault. Been staring at screens too long over the weekend. Sorry. Sorted. Alastair
JIRA versions
Hi folks, In an effort to better track our bugs, I've created some new project versions in JIRA. Renamed: 1.3 -> 1.3.0 Added: 1.3.0-beta1 1.3.0-rc1 1.3.1 Core devs: == Please can you push bugs that are currently marked for 1.3.0 and that you don't intend to fix imminently to either 1.3.1 or mark the fix version as unassigned? IMHO, we need to work out what needs doing for rc-1 and get it all into JIRA so it's all visible, and we can get it all sorted ASAP. Best regards, Al
Re: svn commit: r537771 - in /incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http: WebRequestCycle.java servlet/ServletWebRequest.java
Jean-Baptiste Quenot wrote:
That's sounds very hacky to me:
redirectUrl.replaceAll("../", "")
Can you describe the problem so that we try to provide a better
fix (and hopefully AlMaw is listening to us ;-))
Yeah, I think it's hacky too, especially given the rest of this is now
fairly sane. Rest assured I'm looking into it.
Al
Chaining IComponentResolvers
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: test 2 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
Re: Any documentation on how the wicketstuff.org server is set up?
Martijn Dashorst wrote: Basically I just read a message that the maven repo for our snapshots at wicketstuff.org could be cleaned (to avoid problems with too many versions lying around). Can/should we rm -rf the whole repository prior to a wicket build? Nope, bad plan: - We build different versions, so we'd need to vape 1.2.x and 1.3.x separately, rather than the whole thing, even if this was a good idea, which it isn't. - You don't want to vape things prior to a build, as if someone comes along while you're building they won't be able to download. Bad. - We already have the flag set on Maven to build a single SNAPSHOT rather than dated versions, so we're not wasting any space with this. IMHO, we should: - Not serve up all the dependencies - we should just have org/apache/wicket/ and wicket/ in there. - Remove the 1.3-SNAPSHOT stuff (1.3.0-incubating-SNAPSHOT is current). No one should be using 1.3-SNAPSHOT; we should actively break this. - Remove the 2.0-SNAPSHOT stuff (this one's open to debate). Al
Re: Any documentation on how the wicketstuff.org server is set up?
Johan Compagner wrote: - Not serve up all the dependencies - we should just have org/apache/wicket/ and wicket/ in there. hmm don't know how to do that directly because we just share the local repository of maven and bambo builds from that and deploys to it. So i guess we need to somehow have 2? one that has all and one that has only wicket? Hmmm. We probably need to have a for bamboo, which has a section that points to a local directory, which we serve as the maven repo, and then change the Bamboo builds to do a mvn deploy, not a mvn install. Or somewhat more simply, we could just create a parallel directory structure and symlink stuff: htdocs/ htdocs/wicket -> /home/foo/.m2/repository/wicket htdocs/org/ htdocs/org/apache/ htdocs/org/apache/wicket -> /home/foo/.m2/repository/org/apache/wicket (And make sure the Apache follow symlinks config directive is set.) Al
Re: [jira] Updated: (WICKET-271) investigate Ajax back button support
Johan Compagner wrote: this wont be fixed for 1.3 at least i dont think so, we have support for it on the serverside but no support on the client side yet Yep, that's why I removed 1.3.0 from the fix versions. ;-) Al
Re: Chaining IComponentResolvers
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: test 2 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: [vote] Accept wicket-contrib-velocity sub project
Martijn Dashorst wrote: In the licensing mumbo jumbo, graduation proceedings and fixing bugs for 1.3.0 we forgot to officially vote wicket-contrib-velocity in. So with further ado: [ ] yes accept wicket-contrib-velocity [ ] no, let's not accept wicket-contrib-velocity, because... +1 (binding) Al
Re: Build Failed
Martijn Dashorst wrote: You don't do anything wrong. In Wicket development (on the core project), the unit tests sometimes just don't run for a couple of days because they are used as a method of communication: someone knows how to reproduce a bug but doesn't know how to fix it. The unit test exposing the bug is then committed, so that someone else can look at it in due time. FWIW, this is http://issues.apache.org/jira/browse/WICKET-590 Al
Re: case insensitive check for attributes?
Johan Compagner wrote: should we try to match case insenstive? Not it is just a ValueMap of attributes so the problem is that we then have to lowercase all the attributes keys H. XHTML says all the attributes should be lowercased, so I see no particular problem with lowercasing everything in the markup loader, aside from the extra overhead. Someone will doubtless complain, though. Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: Build Failed
Jean-Baptiste Quenot 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. Sorry for this, this is probably my fault. ;-) Having failing unit tests for days on end is definitely bad - it massively reduces the utility of your continuous integration server. I originally intended this to be fixed pretty rapidly, hence the immediate tender for ideas on how to fix it on IRC and the dev mailing list. Once it wasn't, I should have commented the test out and made appropriate notes on the JIRA issue. We have a bug tracker to work out what bugs need fixing before we do a release, so commenting things doesn't shove them into "a big black hole where no one is looking at it". It's a bug we currently have scheduled for fixing before we push 1.3.0-rc1 out. That most definitely makes it on the immediate radar. Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: case insensitive check for attributes?
As far as I can see, the only reasons not to lower-case stuff automatically are that it's too magic and/or too expensive to check all the attribute modifiers. I can also foresee someone wanting to use upper-case and then running an XSLT transform over it or something, and complaining that we've broken their use-case. I'd be in favour of a runtime check in both DEVELOPMENT and DEPLOYMENT that AttributeModifiers are lowercase, perhaps with a setAllowUppercase(true) to cover the uncommon case if anyone needs it? You can go if (foo.toLowerCase() == foo) which is reasonably cheap (most attributes are less than ~10 chars, so it's just 10 or so comparison operations, no new String will be made if it's already correct. As a slight aside, but related to the magic, I've long been confused by AttributeModifier silently throwing things away if you omit the boolean constructor param. It seems to confuse fresh Wicket developers. Does anyone have a use-case for this? Why is it like that? Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Hi folks, I've been thinking a lot about this lately. Current issues: === - We default to DEVELOPMENT and we should make it more obvious that you should set DEPLOYMENT for production servers. - We currently provide the following methods to configure which mode you run in: - Set a System property. - Set a servlet context param. - Set a filter param. If you don't fit into any of those, it makes life difficult - you don't want to just call configure(DEPLOYMENT) in your init() method, because then configure() is called twice - once by Wicket internally, probably in default DEVELOPMENT mode, and once by you manually. This results in a bunch of DEVELOPMENT mode stuff running on your live environment, and it's not that obvious that this is what's going on. (See WICKET-6, where even JBQ doesn't seem to entirely get this.) To avoid this, you need to override internalInit(), which is a right pain, as although the one in WebApplication doesn't do much, the one in Application does (adds all the component resolvers, etc.) and you'd need to keep things in sync. Ugh. All the configure() methods are final, too, so it's not an option to munge the value and then call super() with it, either. Proposal: = I think we should have a pull model for this. In other words, we should make Application#getConfigurationType() abstract and call that to get the type. We then let people handle this however they want. Advantages: - More discoverable as it's an abstract method, like getHomePage(). - Much more flexible for configuration. - More "Wicket-like". - Less code for us to maintain. Disadvantages: - The 1.3 migration guide gets a little larger. ;-) Err, can I call a vote on this please? [ ] Yes, great idea, let's get it into 1.3.0-beta2 [ ] No, that's rubbish, because... Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Johan Compagner wrote:
is fine by me as long as the current stuff keeps working
like the system property which i use all the time
because i always set it directly in deployment but in my launch configs i
set it back with a system property
I guess we could implement a getDefaultConfigurationType() function
which you could delegate to, which would maintain the current
functionality as-is.
So "upgrading"/migrating would be as simple as:
public String getConfigurationType()
{
return getDefaultConfigurationType();
}
But at least it makes it obvious what's going on, and you can ctrl+click
through to the method to see what happens by default. This would be in
the javadoc, obviously.
Regards,
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
