Re: [Announce] Introducing Wicked Charts
Hi! As nice as it looks but unfortunately, I feel like it should be pointed out that only your wrapper is Apache 2 licensed. Highcharts itself is only free to use for non-profit/non-commercial applications and requires purchase of a license otherwise, see: http://shop.highsoft.com/highcharts.html As long as a project meets the requirements for a free license or one can afford buying a commercial license, that's fine. Unfortunately, it opens a trap for developers that are less cautious and rely on licenses of libraries without checking full dependencies before adding them to their projects. Highcharts may be well-known but I haven't heard of it before. There will be others who see your library but don't know they may require a license for Highcharts, so they may fall for the license. It always disappoints me a bit if I see something published under a really (even commercially) free license but then realize that its dependencies are unfree. Don't get me wrong, your project looks really nice and useful but the license issue should be handled more carefully. A short but prominent notice on your project homepage would be enough. Sorry for spoiling the party. :) Regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and Menu support
Depending on how your menus are supposed to be defined, you could statically put them into your markup or dynamically create them by using a ListView or similar. A nested HTML list structure, as already suggested, usually works best. There are a lot of ready-to-use CSS examples and JavaScript libraries to handle such menus, if you don't want to write it yourself. On 04/08/2012 07:52 AM, msalman wrote: I thought that the idea behind Wicket is to take care of these things for Java programmers. I would appreciate if some basic form of menu is made part of wicket core. Wicket is one of the few frameworks that leave you in full control of your markup, which means that it does not provide a lot of ready-to-include components that include markup and a full style. Instead it works more like casting your markup to Java components, so your HTML code becomes accessible from Java. There are of course some ready-to-use components in wicket-stuff etc. but less in Wicket core. This way, you are not forced to follow an HTML structure or CSS classes someone else wrote that may clash with the design you had in mind (modal dialogs are one exception, apart from that and trees I can't think of many standard components that use a noticeable amount of their own HTML/CSS). If you want to avoid HTML/CSS as far as possible, other frameworks may fit better. For example, you can avoid HTML/CSS almost completely with Vaadin or GWT if you don't need any custom layout (if you do, it can be a lot of work to style it). And then there are a lot of frameworks that are easier to style but require you to write some HTML/CSS yourself. If you want to stay with Wicket, you should get more comfortable with HTML and CSS (which will take a lot of exercise to get it right) or leave writing templates up to a web designer, which (due to a good separation of templates and code) is far easier in Wicket than with other frameworks. In most cases, you can simply take a design, add Wicket XML tags/attributes to it and start using that template from your code. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
I was searching for a Java framework two years ago because I wanted server-side persistence and a statically typed language with the option for easy AJAX and debugging while the output markup is largely maintained the way I wrote the templates. I think I found Wicket via DZone due to the 1.4 release. I already read a book from Manning before and liked that it was written in a way that enables the reader to jump right into programming after having read the introductory chapters. I was happy when I saw that Wicket in Action seemed to use a similar structure. I think I tried Wicket without the book first but got stuck really quick (at latest when I got to the point when I needed models which was quite immediate) and so buying WiA was a quick (and good) decision. As with any framework, it takes at least one project to get your head around it, so you better start with some personal project in your free time. On the following 2-3 projects you are iterating on the maybe I could have done it better that way process. But that's just the way it is for any framework in any language (and also without any framework at all). I assume the OP is using Wicket the first time without any guidance and just hasn't found into it yet. I wasn't able to put Wicket in use at work until January this year but now we are on our 2nd (my 4th) Wicket project. What I could observe is that 1) you usually don't find into Wicket until you read a book (with WiA it's sufficient to read the introductory chapters, jump into coding and come back to the chapters whenever you need to know something) 2) there is an aversion until you get your head around the correct use of models and anonymous inner classes, at least if you never did something like that before (WiA introduces it quite good but you have to start coding before you really get it) 3) you should follow the (excellent) mailing list to read about issues you may encounter and use it as a knowledge base once you hit some problem/question (better on an own email account than on the archives) 4) if documentation does not help, read the source code (I found it pretty readable which is much different from other frameworks I have used/tried before - being easily accessible with Maven and a decent IDE, there is no excuse not to look into it) So, the conclusion is: There should be better free documentation but if you pick up a book it's quite easy to get started and the best 30€ ever spent. - I agree that it is rather too easy for Wicket to make things stateful, when you don't want it To turn that into a point of critique: It may be hard to get stateless pages. I've made a similar experience where I had a search form that would not go stateless. I couldn't figure out where anything was persisted but if I had dug deeper, I may have found the cause, but that issue wasn't important enough to invest more time in it. - and in my opinion the stuff you need to do to achieve normal URLs (no ?, no version number, no nothing) is just a pain. *Every* URL, for stateless or stateless pages or whatever, should be normal, otherwise it is just not acceptable -- users never want to see those complicated-looking URLs under any circumstance I prefer the way Wicket handles persistence with at-most-once semantics by simply adding version numbers on the URL (after a redirect from an internal URL) as other methods are less successful in achieving that out of the box, pollute URLs even further or add hidden markup. IMO, two numbers on the URL are quite unobtrusive, especially as they are simply ignored and transparently reassigned if the session does not match (i.e. on a URL that has been pasted into an email etc.). - did not yet try out Ajax with Wicket, so I have no opinion on that It's incredibly easy to use; you should really try it. :) Just my 2¢. In all, a great framework that is much easier to use than e.g. things based on JSP. Keep up the good work, guys ! Full ack! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: new user registration email verification
It's like you already said in your first mail. For one of our websites the behaviour is: 1) generate some kind of a random, unique token s.th. like UUID.randomUUID().toString() 2) register token to user in database 3) email link including the token to the user (use a readily available email library) For your application to process the link, the link should end in a bookmarkable page with a short URL (so it doesn't take too much space in the email). If you append the token like you usually do (depending on the UrlCodingStrategy used), the page can get the token by accessing the PageParameters. If you have multiple types of opt-ins/confirmations (user accounts, newsletters etc.) then you could use one page to process all tokens and let it decide which additional page should be instantiated and redirected to after token verification depending on the token type you saved in your database. On our website we check the token for the correct pattern using a regular expression and then get the user's email address/data from the database and let the user confirm his address by re-entering it and continue with an account setup wizard. However, such a double-safety should rarely be necessary. We could as well confirm the account right away (or immediately show/redirect to the wizard instead); once you have the token you know what user is intended to be accessed so you can do whatever you want. Also make sure your tokens will time out after a week or so. You may also want to count token requests/validations and block users in case the number gets too high (get the client IP address by accessing the servlet request and record it somewhere). Maybe we are just a bit too cautious but our application hosts quite some data, so it can't be wrong. :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
I would stick with 1 (required to be checked). The main reason would be not to break compatibility with old versions. I actually used .setRequired(true) on legal checkboxes (disclaimers) in one of our applications because if I have a required checkbox I expect it to be needed to be checked. Although I will change that in our project now that I know such a change is being discussed, I wouldn't expect others to be that observant of the issue and have unit tests that prevent anything from breaking on a future upgrade. BTW an empty string (that's not null) is a string nevertheless. Following the argument that an unchecked (false) checkbox should be regarded as valid if it is required, an empty string should be accepted as a valid input as well. I've just tested it with Wicket 1.4 and actually both of the following TextFields validate to a failed state: TextField tf1 = new TextField(text1, new PropertyModelString(this, test1)); tf1.setRequired(true); tf1.setConvertEmptyInputStringToNull(false); form.add(tf1); TextField tf2 = new TextField(text2, new PropertyModelString(this, test2)); tf2.setRequired(true); tf2.setConvertEmptyInputStringToNull(true); form.add(tf2); So, TextField.setRequired doesn't validate the syntactic meaning as well, instead it validates the semantic meaning, just as CheckBox.setRequired does. If that's consistently used throughout Wicket, I would expect CheckBox.setRequired to validate false unless the CheckBox is actually checked. Just my 2 cents, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: flexible authentication
Hi! We have the same situation in one of our web applications (profile pages may be hidden for everyone except the profile owner). Since I wasn't able to find a clean way to check such conditions from our page authorization strategy, I added that to the checks I already had in the page constructor method (other checks are to catch invalid indices etc.). If the validation fails I redirect the user to a friendly-written error page and call return to stop the method afterwards. Maybe it's possible to get the page parameters by accessing the request cycle directly from an authorization strategy? However, if there are more situations like that I would expect the authorization strategy to become big and cluttered very fast, so I don't think such checks should go there but instead be performed by the page class they are meant for. If the same checks are performed in different classes, they could go into a (static) method, maybe in a super class. If there's (yet) another good place to put such checks in, I would be interested in it as well. :) Bye, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
auto-linking to (shared) resources in a parent-relative path
Hi! I'm desperately trying to get a few static image files auto-linked (using wicket:link in my markup) to a parent-relative path. It works fine while using .. but I can't figure out how to get the correct src-URLs using any of the workarounds I could find that should appease Wicket so it stops logging the warning: --- Your path looks like: ../../images/system/icons/cancel.png For security reasons moving up '../' is disabled by default. Please see IResourceSettings.getParentFolderPlaceholder() and PackageResourceGuard for more details --- I tried many ways to work around that problem but nothing succeeds in automatically linking the markup, I always end up with the unchanged URL. I would be glad if someone could show me what I do wrong or could even provide me with a small working example (all I could find were one-line examples that don't work for me). Furthermore, I'm unsure what workaround I should use. The cleanest way would possibly be number 3 listed below. Anyway, all except number 2 break links when viewing the templates without a running Wicket application. Also, I don't really get the difference that workaround 1 makes from what I read. How does it help security if I'm just replacing .. by some arbitrary String like $up$? The application is built using Wicket 1.4.15, Maven and Jetty. It has two different frontends which led to a package structure like: com company project wicket frontend1 pages frontend2 pages Markup is stored directly in frontend1.pages and frontend2.pages. The image files have recently been moved from frontend2.pages to com.company.project.wicket so now I have to get two package levels higher. Markup is currently in src/main/java while images are in src/main/resources which shouldn't matter since they are copied to one directory on build/execution. I would like to show what I tried so far without any luck, so please excuse me if this gets a bit longer: Workaround 1: Setting the placeholder to $up$ in Application.init() Code: getResourceSettings().setParentFolderPlaceholder($up$); Markup: img src=$up$/$up$/images/system/icons/cancel.png alt=Cancel / Result in a browser: img src=$up$/$up$/images/system/icons/cancel.png alt=Cancel / Workaround 2: Mounting a shared resource I created an empty class CommonResources in com.company.project.wicket so the shared resource key returns com.company.project.wicket.CommonResources/images/system/icons/cancel.png Code: mountSharedResource(images/system/icons/cancel.png, new ResourceReference(CommonResources.class, images/system/icons/cancel.png).getSharedResourceKey()); Markup: img src=images/system/icons/cancel.png alt=Cancel / Result: (404) img src=images/system/icons/cancel.png alt=Cancel / Workaround 3: Trying to move the icons to a resource directory below the context path (WAR root level) I called the folder resourcesearch because resources is already handled by Wicket. Code: (either one of these two lines) getResourceSettings().addResourceFolder(resourcesearch); getResourceSettings().addResourceFolder(getServletContext().getRealPath(/resourcesearch)); Markup: (also tried without the root slash) img src=/resourcesearch/images/system/icons/cancel.png alt=Cancel / Result: (wrong path, it's actually deployed to /ProjectName-Version/) img src=/resourcesearch/images/system/icons/cancel.png alt=Cancel / Thanks, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
