Re: readering strategy of the 'head' section
Hi Dan, Thanks for the example. On Mar 24, 2013, at 7:26 PM, Dan Retzlaff dretzl...@gmail.com wrote: Re: duplicate/conflicting contributions, Wicket automatically de-dups header contributions. See HeaderItem#getRenderTokens(). Since Wicket itself pulls in JQuery, your app's use of it should be configured through IJavaScriptLibrarySettings as shown here. Is that still the case when you have components that use different versions of jQuery, because the components come from different libraries? Guess not, but will give it a try. Harrie hhazewin...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: readering strategy of the 'head' section
Hallo, I understand that potentially things could be overridden at a lower child. Although, you can have the same in the opposite direction. Same counts for bugs, but the beauty would be the flexibility I would say. On top of that, I am wondering how others use it than in combination with jQuery. Typically, jQuery has some element specific javascript and css, but rely on the common jQuery (file jqeury-min.js). If now all is driven from the lower childs you cannot place the common jQuery in the toplevel page from which all pages inherit and if a lower child adds the common jQuery you may end up with multiple (potentailly even different versions as well). Therefore, I am curious how most people use it with jQuery as I would say adding a single line in the html from which pages inherit from is way easier then putting a this in Java code. I understand the point of view that you may try to avoid a ParentFHRS, but disagree that core-developers make such a choice for others. So deprecating it sounds not the way to go for me, it reduces maybe the burden of maintaining it by core developers, but for sure also reduces the flexibility of using Wicket. Harrie hhazewin...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
readering strategy of the 'head' section
Hello, I recently upgraded from wicket 1.5 to 6. This is mostly not a real problem. However, I believe that the complete change of the header render strategy is not compatible. This is also mentioned in various places. Wicket 1.5 may not have been consistent in for the header rendering, but why not trying to maintain some easy compatibility? As Wicket 1.5 used a parent first render strategy, I can find still ways that Wicket 6 can support this. Why not supporting this in the applications settings either? It eases upgrades of big projects and overcomes a way that there is a lot of code to be added in Java. Wondering if more people believe a better support for the ParentFirstHeaderRenderStrategy is wished for instaed of adding renderHead code all over. Or do I miss something? Harrie hhazewin...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: readering strategy of the 'head' section
Hello, After the upgrade to 6.x I found that the order of the headers were reverse compared to 1.5. This caused the com.googlecode.wicket.jquery.ui.form.datepicker.DatePicker to fail as it did not wanted to display the popup to pick the date in a panel. The problem was that it depended on common jquery that was added in a parent page. Then by using the ParentFirstHeaderRenderStrategy this worked again and NO other code changes were needed. But speaking of a general usecase, I see that you can then simply follow the page structure and panel structure as how also the page inheritance goes and the panel inheritance as well. Common things go in the parent page or panel and only specifics go into the page or panel itself. Also what I found was that html header elements like 'title' were not place in the beginning of the header anymore (which I believe is nicer to have it before javascript includes). A title element I mostly added in the base page of my application of which all other pages inherited from. Although, I do not understand why wicket developers (and I assume you mean the core developers and not those developers using the framework) do not like a parent first strategy, I simply would say…. Wicket is modular and pluggable in many ways. Why would wicket developers force this to there users by not allowing it? Given the framework supports this almost already, leave this as a choice to the users to select it as what would be the best for them. Of course, a default implementation can be the preferred way of the wicket developers, but allowing users there own choice. Harrie On Mar 21, 2013, at 9:20 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, The change to use ChildFirstHeaderRenderStrategy by default was introduced in 1.5.0. The usage of a system property to switch the strategy was intentional - to make it harder. Wicket developers believe that ParentFirstHeaderRenderStrategy should not be used. But there was a bug that wicket:head didn't followed the rules. In 6.0 both Java and HTML contributions became more consistent. Additionally now the application developer can promote the HeaderItems by wrapping them in PriorityHeaderItem. Yet another way is to use custom org.apache.wicket.settings.IResourceSettings#setHeaderItemComparator. What is your usecase to prefer ParentFirstHeaderRenderStrategy ? On Thu, Mar 21, 2013 at 9:55 AM, Harrie Hazewinkel hhazewin...@gmail.comwrote: Hello, I recently upgraded from wicket 1.5 to 6. This is mostly not a real problem. However, I believe that the complete change of the header render strategy is not compatible. This is also mentioned in various places. Wicket 1.5 may not have been consistent in for the header rendering, but why not trying to maintain some easy compatibility? As Wicket 1.5 used a parent first render strategy, I can find still ways that Wicket 6 can support this. Why not supporting this in the applications settings either? It eases upgrades of big projects and overcomes a way that there is a lot of code to be added in Java. Wondering if more people believe a better support for the ParentFirstHeaderRenderStrategy is wished for instaed of adding renderHead code all over. Or do I miss something? Harrie hhazewin...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ Harrie hhazewin...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
setting number of pages in the session
Hello, Ik would like to reduce the amount of pages maintained in the session to 1 in order to disable the back button. How can I set this in wicket 1.5RC2? With this I would like to avoid the possibility that after a logout, the user can come back to the previous logged in page via the back button. I already search the Internet archives, but found nothing useful (some hints seemed not for wicket 1.5RC2) Any help appreciated, Met hartelijke groet, Harrie Hazewinkel Software Architect - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ConversionException and onSubmit is not called
HI Cemil, I had to modify the setObject rather different, but it gave me the clue on where the conversion went wrong. Thanks for your sample code! regards, Harrie - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ConversionException and onSubmit is not called
On 21 aug 2009, at 15:36, Jonas wrote: Have you tried removing setType(Region.class); from your code? I don't think that's necessary for a DropDownChoice - and probably the cause why an IConverter is used (which is probably the source of the ConversionException you mentioned). Actually, by accident I deleted the line and found out that without the line it all works. thanks, Harrie - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: EmailAddressValidator does not conform RFC'
HI, Thanks! Any chance that, for instance', the allowed '+' sign in the localpart of the email address becomes allowed in the standard EmailAddressValidator? Some services, like gmail with the '+', sign use that to enable multiple mailboxes for the same account. regards, Harrie On 14 jun 2009, at 22:58, Igor Vaynberg wrote: see org .apache .wicket .extensions.validation.validator.RfcCompliantEmailAddressValidator -igor On Sun, Jun 14, 2009 at 1:54 PM, Harrie Hazewinkelhar...@tipspot.com wrote: Hi all, The EmailAddressValidator is not conform RFC' and commonly used forms. The RFC' to look at are 5322 and 3696 (this RFC explains the details in a readable way). Has anyone else experienced this as well? regards, Harrie - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
EmailAddressValidator does not conform RFC'
Hi all, The EmailAddressValidator is not conform RFC' and commonly used forms. The RFC' to look at are 5322 and 3696 (this RFC explains the details in a readable way). Has anyone else experienced this as well? regards, Harrie - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
