overriding isVisible bad?
Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
Can you explain why? We have done this all over the place. D/ On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: The recommended way since a few 1.4 releases is to override onConfigure() and call setVisible(true|false) depending on your conditions. On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: [vote] release wicket 1.4.5
+1 On Dec 16, 2009, at 6:15 PM, Igor Vaynberg wrote: this vote is to release wicket 1.4.5 this build fixes some critical problems with 1.4.4, namely WICKET-2613 and some modal-window related issues. branch: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.5/ artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.5/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=prioritypid=12310561fixfor=12314441 (and below) vote ends Saturday 5pm gmt-8 thank you. -igor Release Notes - Wicket - Version 1.4.5 ** Bug * [WICKET-2598] - Some components still escape non-ASCII symbols by default * [WICKET-2599] - Missing XML prolog in wicket-extensions panel htmls * [WICKET-2600] - Redirect to home page still does not work (regression) * [WICKET-2606] - Enclosure reports incorrect component id for missing components inside the enclosure * [WICKET-2609] - EnumChoiceRenderer misbehaves with anonymous enum classes * [WICKET-2613] - Content-Length Issue with 1.4.4 * [WICKET-2617] - ModalWindow can't be shown when it is rendered with ajax request * [WICKET-2621] - Ajax buttons inside ModalWindows don't submit properly ** Improvement * [WICKET-1888] - FormComponents (and subclasses) should be able to provide their own resource bundles * [WICKET-2247] - IndexedHybridUrlCodingStrategy constructor should accept a redirectOnBookmarkableRequest boolan * [WICKET-2428] - AbstractSingleSelectChoice: custom resource key for null option * [WICKET-2592] - Add support for arbitrary PageParameters values in QueryStringUrlCodingStrategy * [WICKET-2597] - The PagingNavigator.newNavigation method does not provide a markup id of the element to create an navigation for * [WICKET-2602] - Display upload progress bar only when a file is selected * [WICKET-2603] - javadoc update * [WICKET-2604] - Add another german Wicket book
wicket:enclosure quick start
I am trying to create a quick start to recreate my issue and I have been unsuccessful. I'm guess it has something to do with my environment. Anybody have any tips on how to reproduce a huge stack in a quick start? I created the entire inheritance tree and keep most of the same html, which was tedious and it works fine in the quickstart. D/
Re: wicket:enclosure quick start
Yeah.. ok.. but the problem when I upgrade. I was hoping to create to enable me to upgrade. D/ On Dec 9, 2009, at 10:25 AM, Jeremy Thomerson wrote: This happens many times - you suddenly discover that the bug is actually in your code or some other dependency and the complex ways they work together. If I were you, I'd start trying to debug directly in my project by setting breakpoints, etc, rather than continue with the quickstart. -- Jeremy Thomerson http://www.wickettraining.com On Wed, Dec 9, 2009 at 10:15 AM, Douglas Ferguson doug...@douglasferguson.us wrote: I am trying to create a quick start to recreate my issue and I have been unsuccessful. I'm guess it has something to do with my environment. Anybody have any tips on how to reproduce a huge stack in a quick start? I created the entire inheritance tree and keep most of the same html, which was tedious and it works fine in the quickstart. D/
Re: [vote] release wicket 1.4.4
My issue had to do with expecting enclosure to allow you to not add the fields when it is hidden, it seems to be working now that I've corrected this, although it does incorrectly report the missing fields. D/ On Dec 9, 2009, at 3:49 PM, Marcus Mattila wrote: [x] don't release 1.4.4 reason: aforementioned still existing wicket:enclosure problems, which have prevented upgrade for us now from 1.4.1 onwards -Marcus
Re: [vote] release wicket 1.4.4
+1 (i withdraw my no) On Dec 9, 2009, at 8:48 PM, Igor Vaynberg wrote: +1 -igor On Mon, Dec 7, 2009 at 11:13 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this vote is to release wicket 1.4.4 branch: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.4/ artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.4/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?fixfor=12314323 (and below) vote ends thursday 12pm gmt-8 thank you. -igor --- Release Notes - Wicket - Version 1.4.4 ** Bug * [WICKET-625] - Wicket doesn't clean up properly when hot-deploying; hangs onto Class references. * [WICKET-2080] - InjectorHolder is broken when wicket-ioc.jar is shared between multiple web applications * [WICKET-2317] - Deprecated JavaDoc for org.apache.wicket.behavior.HeaderContributor * [WICKET-2419] - AjaxEditableMultiLineLabel doesn't handle huge text properly * [WICKET-2491] - Ajax multipart broken on mounted pages * [WICKET-2518] - Application_bg.properties property file is incorrectly encoded * [WICKET-2519] - 1.4.2 enclosure problem * [WICKET-2534] - File Handle Leak in URLResourceStream * [WICKET-2545] - NullPointerException thrown from BaseWicketTester isComponent * [WICKET-2546] - DataTable does not generate thead tag * [WICKET-2548] - MetaDataKey does not meet hashCode() contract * [WICKET-2550] - DatePicker introduces a bug regarding the back button support of the browser. * [WICKET-2551] - Bug in WicketTester when submitting forms * [WICKET-2552] - CreditCardValidator accepts invalid inputs * [WICKET-2553] - Wicket-ajax.js: Javascript error on submitting of form with wicketSubmitFormById. * [WICKET-2554] - WebRequestCodingStrategy assumes that a shared resource URL should always be relative to the Wicket handler * [WICKET-2567] - Images and stylesheets leave open file handles * [WICKET-2568] - Unnecessary method calls in IDataProvider * [WICKET-2570] - Form submitting component is not checked for being enabled during submit * [WICKET-2580] - Javadoc of Component#setOutputMarkupPlaceholderTag is wrong * [WICKET-2582] - org.apache.wicket.markup.html.form.Check should call Component.isEnabledInHierarchy() * [WICKET-2583] - Warnings flood if incorrect credentials endered on SignInPage * [WICKET-2587] - UploadProgressBar producing warning log messages incorrectly * [WICKET-2589] - FeedbackPanel in FormComponentFeedbackBorder throws ConcurrentModificationException * [WICKET-2593] - wicket:message can cause infinite loop in render * [WICKET-2595] - Ajax multipart fails for inner forms added via ajax ** Improvement * [WICKET-12] - open Modal Window without AjaxRequestTarget * [WICKET-2326] - Text on BrowserInfoPage should be customizable * [WICKET-2364] - CLONE -Make LoadableDetachableModel writable * [WICKET-2531] - Open DropDownChoice null value internationalization key * [WICKET-2533] - Behavior for accepted locales should fit the HTTP Specification * [WICKET-2536] - Guice 2.0 and its maven2 repository groupId * [WICKET-2539] - PackageStringResourceLoader does not look up to superclasses * [WICKET-2540] - Date Validation - message formatting of the date * [WICKET-2564] - Modify wicket-devutils DebugBar so it emits valid XHTML * [WICKET-2573] - Allow applications to chose not to use CGLIB proxies for @SpringBean injections * [WICKET-2575] - RepeatingView's Javadoc to include newChildId() and add() * [WICKET-2578] - Polish resource files for wicket 1.4.3 * [WICKET-2581] - French translation of Wicket-auth resources * [WICKET-2590] - AjaxLazyLoadPanel callback script rendering ** New Feature * [WICKET-1157] - Generic internationalization for Enums * [WICKET-2572] - Add capability for SpringWebApplicationFactory to create its own application context
Re: [vote] release wicket 1.4.4
I can't make a quickstart that causes it to fail but it surely doesn't work in my app. I haven't been able to pin point what is specific to my app that causes it to fail. D/ On Dec 7, 2009, at 11:01 PM, Igor Vaynberg wrote: both quickstarts in the issue work. -igor On Mon, Dec 7, 2009 at 5:30 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Unless I did something wrong: svn co http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x/ wicket 1.4.x.SNAPSHOT cd 1.4.x.SNAPSHOT mvn -Dmaven.test.skip=true install I set my wicket version to 1.4-SNAPSHOT D/ On Dec 7, 2009, at 5:53 PM, Igor Vaynberg wrote: its not? its marked as fixed... -igor On Mon, Dec 7, 2009 at 1:58 PM, Douglas Ferguson doug...@douglasferguson.us wrote: No This is not fixed: * [WICKET-2519] - 1.4.2 enclosure problem On Dec 7, 2009, at 1:13 PM, Igor Vaynberg wrote: this vote is to release wicket 1.4.4 branch: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.4/ artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.4/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?fixfor=12314323 (and below) vote ends thursday 12pm gmt-8 thank you. -igor --- Release Notes - Wicket - Version 1.4.4 ** Bug * [WICKET-625] - Wicket doesn't clean up properly when hot-deploying; hangs onto Class references. * [WICKET-2080] - InjectorHolder is broken when wicket-ioc.jar is shared between multiple web applications * [WICKET-2317] - Deprecated JavaDoc for org.apache.wicket.behavior.HeaderContributor * [WICKET-2419] - AjaxEditableMultiLineLabel doesn't handle huge text properly * [WICKET-2491] - Ajax multipart broken on mounted pages * [WICKET-2518] - Application_bg.properties property file is incorrectly encoded * [WICKET-2519] - 1.4.2 enclosure problem * [WICKET-2534] - File Handle Leak in URLResourceStream * [WICKET-2545] - NullPointerException thrown from BaseWicketTester isComponent * [WICKET-2546] - DataTable does not generate thead tag * [WICKET-2548] - MetaDataKey does not meet hashCode() contract * [WICKET-2550] - DatePicker introduces a bug regarding the back button support of the browser. * [WICKET-2551] - Bug in WicketTester when submitting forms * [WICKET-2552] - CreditCardValidator accepts invalid inputs * [WICKET-2553] - Wicket-ajax.js: Javascript error on submitting of form with wicketSubmitFormById. * [WICKET-2554] - WebRequestCodingStrategy assumes that a shared resource URL should always be relative to the Wicket handler * [WICKET-2567] - Images and stylesheets leave open file handles * [WICKET-2568] - Unnecessary method calls in IDataProvider * [WICKET-2570] - Form submitting component is not checked for being enabled during submit * [WICKET-2580] - Javadoc of Component#setOutputMarkupPlaceholderTag is wrong * [WICKET-2582] - org.apache.wicket.markup.html.form.Check should call Component.isEnabledInHierarchy() * [WICKET-2583] - Warnings flood if incorrect credentials endered on SignInPage * [WICKET-2587] - UploadProgressBar producing warning log messages incorrectly * [WICKET-2589] - FeedbackPanel in FormComponentFeedbackBorder throws ConcurrentModificationException * [WICKET-2593] - wicket:message can cause infinite loop in render * [WICKET-2595] - Ajax multipart fails for inner forms added via ajax ** Improvement * [WICKET-12] - open Modal Window without AjaxRequestTarget * [WICKET-2326] - Text on BrowserInfoPage should be customizable * [WICKET-2364] - CLONE -Make LoadableDetachableModel writable * [WICKET-2531] - Open DropDownChoice null value internationalization key * [WICKET-2533] - Behavior for accepted locales should fit the HTTP Specification * [WICKET-2536] - Guice 2.0 and its maven2 repository groupId * [WICKET-2539] - PackageStringResourceLoader does not look up to superclasses * [WICKET-2540] - Date Validation - message formatting of the date * [WICKET-2564] - Modify wicket-devutils DebugBar so it emits valid XHTML * [WICKET-2573] - Allow applications to chose not to use CGLIB proxies for @SpringBean injections * [WICKET-2575] - RepeatingView's Javadoc to include newChildId() and add() * [WICKET-2578] - Polish resource files for wicket 1.4.3 * [WICKET-2581] - French translation of Wicket-auth resources * [WICKET-2590] - AjaxLazyLoadPanel callback script rendering ** New Feature * [WICKET-1157] - Generic internationalization for Enums * [WICKET-2572] - Add capability for SpringWebApplicationFactory to create its own application context
Re: [vote] release wicket 1.4.4
Unless I did something wrong: svn co http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x/ wicket 1.4.x.SNAPSHOT cd 1.4.x.SNAPSHOT mvn -Dmaven.test.skip=true install I set my wicket version to 1.4-SNAPSHOT D/ On Dec 7, 2009, at 5:53 PM, Igor Vaynberg wrote: its not? its marked as fixed... -igor On Mon, Dec 7, 2009 at 1:58 PM, Douglas Ferguson doug...@douglasferguson.us wrote: No This is not fixed: * [WICKET-2519] - 1.4.2 enclosure problem On Dec 7, 2009, at 1:13 PM, Igor Vaynberg wrote: this vote is to release wicket 1.4.4 branch: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.4/ artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.4/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?fixfor=12314323 (and below) vote ends thursday 12pm gmt-8 thank you. -igor --- Release Notes - Wicket - Version 1.4.4 ** Bug * [WICKET-625] - Wicket doesn't clean up properly when hot-deploying; hangs onto Class references. * [WICKET-2080] - InjectorHolder is broken when wicket-ioc.jar is shared between multiple web applications * [WICKET-2317] - Deprecated JavaDoc for org.apache.wicket.behavior.HeaderContributor * [WICKET-2419] - AjaxEditableMultiLineLabel doesn't handle huge text properly * [WICKET-2491] - Ajax multipart broken on mounted pages * [WICKET-2518] - Application_bg.properties property file is incorrectly encoded * [WICKET-2519] - 1.4.2 enclosure problem * [WICKET-2534] - File Handle Leak in URLResourceStream * [WICKET-2545] - NullPointerException thrown from BaseWicketTester isComponent * [WICKET-2546] - DataTable does not generate thead tag * [WICKET-2548] - MetaDataKey does not meet hashCode() contract * [WICKET-2550] - DatePicker introduces a bug regarding the back button support of the browser. * [WICKET-2551] - Bug in WicketTester when submitting forms * [WICKET-2552] - CreditCardValidator accepts invalid inputs * [WICKET-2553] - Wicket-ajax.js: Javascript error on submitting of form with wicketSubmitFormById. * [WICKET-2554] - WebRequestCodingStrategy assumes that a shared resource URL should always be relative to the Wicket handler * [WICKET-2567] - Images and stylesheets leave open file handles * [WICKET-2568] - Unnecessary method calls in IDataProvider * [WICKET-2570] - Form submitting component is not checked for being enabled during submit * [WICKET-2580] - Javadoc of Component#setOutputMarkupPlaceholderTag is wrong * [WICKET-2582] - org.apache.wicket.markup.html.form.Check should call Component.isEnabledInHierarchy() * [WICKET-2583] - Warnings flood if incorrect credentials endered on SignInPage * [WICKET-2587] - UploadProgressBar producing warning log messages incorrectly * [WICKET-2589] - FeedbackPanel in FormComponentFeedbackBorder throws ConcurrentModificationException * [WICKET-2593] - wicket:message can cause infinite loop in render * [WICKET-2595] - Ajax multipart fails for inner forms added via ajax ** Improvement * [WICKET-12] - open Modal Window without AjaxRequestTarget * [WICKET-2326] - Text on BrowserInfoPage should be customizable * [WICKET-2364] - CLONE -Make LoadableDetachableModel writable * [WICKET-2531] - Open DropDownChoice null value internationalization key * [WICKET-2533] - Behavior for accepted locales should fit the HTTP Specification * [WICKET-2536] - Guice 2.0 and its maven2 repository groupId * [WICKET-2539] - PackageStringResourceLoader does not look up to superclasses * [WICKET-2540] - Date Validation - message formatting of the date * [WICKET-2564] - Modify wicket-devutils DebugBar so it emits valid XHTML * [WICKET-2573] - Allow applications to chose not to use CGLIB proxies for @SpringBean injections * [WICKET-2575] - RepeatingView's Javadoc to include newChildId() and add() * [WICKET-2578] - Polish resource files for wicket 1.4.3 * [WICKET-2581] - French translation of Wicket-auth resources * [WICKET-2590] - AjaxLazyLoadPanel callback script rendering ** New Feature * [WICKET-1157] - Generic internationalization for Enums * [WICKET-2572] - Add capability for SpringWebApplicationFactory to create its own application context
Re: [announce] wicket 1.4.x branched
I agree that this area could benefit from a redesign. I specifically found it difficult when writing a RequestHandler that would redirect request from ssl to non-ssl depending no the page type. I.E. Login is redirected to HTTPS, then regular page redirects you back to HTTP D/ On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the intention is to drastically simply the process of going from a url to a page. right now we have the filter-requestcycle-processor-coding strategy-target-page. everything between the filter and the page is very complicated. we would like to clean it up and simplify it. our url handling is a mess. it is spread all over the aforementioned objects - encoding, decoding, parameter resolving, relative path calculations, context path calculations, etc, etc. we would like to create a value object to represent the url, and centralize all that logic inside. we also intend to make it simpler to create custom coding strategies, as well as mount non-page-related handlers onto urls. further, a stretch goal would be to unify the handling of resources with this scheme. currently resources are handled via SharedResources and are completely separate from the normal process. its more stuff to learn and to understand for users, hopefully we can rebuild resources to work via the same process as everything else - thus the non-page-related handlers mentioned above. these are all rough ideas, we havent really talked much about them but prototyped some code to see what this can potentially look like. -igor On Thu, Aug 20, 2009 at 1:33 PM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: It would be nice to get some guidance towards the goals, and architecture of your new design before we commit to it. Just looking at the code doesn't reveal intention or the bigger picture. Martijn On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote: Hi, actually the changes in 1.5 might be quite drastic as far as wicket internals are concerned. I've already rewritten the request cycle, url processing and page management. I'm not sure how much of it will actually get to trunk though. You can take a look at the code here if you are interested: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ Note that this is pretty much a prototype. While the request cycle, url processing and page management work, the rest of wicket is more or less mocked. Also right now it only covers regular request processing. I don't know enough about portlets to build in portlet support. I'm not even sure the architecture is flexible enough to allow seamless portlet integration. That said, it would be much probably lot easier and cleaner to refactor this code than to add add portlets to existing wicket trunk - which always feel like a hack to me. -Matej On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbsantony.stu...@gmail.com wrote: There us already a working patch since early this year. I just need to update it to trunk which shouldn't be a big deal. Regards, Antony Stubbs website: sharca.com On 20/08/2009, at 7:58 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: come up with a proposal we can discuss. when we hash out the idea then come up with a patch. proposal==patch is fine as far as you dont mind refactoring as we iterate. -igor On Thu, Aug 20, 2009 at 9:51 AM, Antony Stubbsantony.stu...@gmail.com wrote: Apologies if this is known, but is there anywhere noted the plan for 1.5? Also, I'd like to look back at the portal events work I did, and try and get that into 1.5. What would be the process for doing so? In terms of making a branch, or just re-patching, or do I just need to get the final OK from Ate? Cheers, Antony Stubbs, sharca.com On 20/08/2009, at 5:10 PM, Igor Vaynberg wrote: Wicket 1.4.x has been branched and now lives in https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x Trunk is now what will become 1.5.0. Trunk may be broken in the early days of development and contain a lot of API breaks, so if you are following bleeding edge you may want to do so on the 1.4.x branch for a while. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
Re: [announce] wicket 1.4.x branched
No.. I just finally set our pom to 1.4 and dealing with the 4,000 warnings! I'm wondering what other folks are doing for thinks like Link(s) or simple components that don't make use of a model. In some cases I've just added String to make eclipse stop complaining... I'll look into @RequireHttps, but now that I have it working, I'm not sure I'll touch it. Are there good docs on it anywhere? D/ On 8/20/09 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: have you seen @RequireHttps in 1.4? it is a pita, but its doable. -igor On Thu, Aug 20, 2009 at 1:53 PM, Douglas Fergusondoug...@douglasferguson.us wrote: I agree that this area could benefit from a redesign. I specifically found it difficult when writing a RequestHandler that would redirect request from ssl to non-ssl depending no the page type. I.E. Login is redirected to HTTPS, then regular page redirects you back to HTTP D/ On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the intention is to drastically simply the process of going from a url to a page. right now we have the filter-requestcycle-processor-coding strategy-target-page. everything between the filter and the page is very complicated. we would like to clean it up and simplify it. our url handling is a mess. it is spread all over the aforementioned objects - encoding, decoding, parameter resolving, relative path calculations, context path calculations, etc, etc. we would like to create a value object to represent the url, and centralize all that logic inside. we also intend to make it simpler to create custom coding strategies, as well as mount non-page-related handlers onto urls. further, a stretch goal would be to unify the handling of resources with this scheme. currently resources are handled via SharedResources and are completely separate from the normal process. its more stuff to learn and to understand for users, hopefully we can rebuild resources to work via the same process as everything else - thus the non-page-related handlers mentioned above. these are all rough ideas, we havent really talked much about them but prototyped some code to see what this can potentially look like. -igor On Thu, Aug 20, 2009 at 1:33 PM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: It would be nice to get some guidance towards the goals, and architecture of your new design before we commit to it. Just looking at the code doesn't reveal intention or the bigger picture. Martijn On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote: Hi, actually the changes in 1.5 might be quite drastic as far as wicket internals are concerned. I've already rewritten the request cycle, url processing and page management. I'm not sure how much of it will actually get to trunk though. You can take a look at the code here if you are interested: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ Note that this is pretty much a prototype. While the request cycle, url processing and page management work, the rest of wicket is more or less mocked. Also right now it only covers regular request processing. I don't know enough about portlets to build in portlet support. I'm not even sure the architecture is flexible enough to allow seamless portlet integration. That said, it would be much probably lot easier and cleaner to refactor this code than to add add portlets to existing wicket trunk - which always feel like a hack to me. -Matej On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbsantony.stu...@gmail.com wrote: There us already a working patch since early this year. I just need to update it to trunk which shouldn't be a big deal. Regards, Antony Stubbs website: sharca.com On 20/08/2009, at 7:58 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: come up with a proposal we can discuss. when we hash out the idea then come up with a patch. proposal==patch is fine as far as you dont mind refactoring as we iterate. -igor On Thu, Aug 20, 2009 at 9:51 AM, Antony Stubbsantony.stu...@gmail.com wrote: Apologies if this is known, but is there anywhere noted the plan for 1.5? Also, I'd like to look back at the portal events work I did, and try and get that into 1.5. What would be the process for doing so? In terms of making a branch, or just re-patching, or do I just need to get the final OK from Ate? Cheers, Antony Stubbs, sharca.com On 20/08/2009, at 5:10 PM, Igor Vaynberg wrote: Wicket 1.4.x has been branched and now lives in https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x Trunk is now what will become 1.5.0. Trunk may be broken in the early days of development and contain a lot of API breaks, so if you are following bleeding edge you may want to do so on the 1.4.x branch for a while. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For
Re: [announce] wicket 1.4.x branched
Something that I've encounter that I found frustrating that might be worth considering in the new design: Construct a page... Realize you need to forward to another page, Call setResponsePage(...) If the constructor short circuits when it realizes that the request is getting forwarded, Wicket will blow up if you haven't added all the components because it wants to finish building everything before the response is Fowarded. D/ On 8/20/09 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: have you seen @RequireHttps in 1.4? it is a pita, but its doable. -igor On Thu, Aug 20, 2009 at 1:53 PM, Douglas Fergusondoug...@douglasferguson.us wrote: I agree that this area could benefit from a redesign. I specifically found it difficult when writing a RequestHandler that would redirect request from ssl to non-ssl depending no the page type. I.E. Login is redirected to HTTPS, then regular page redirects you back to HTTP D/ On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the intention is to drastically simply the process of going from a url to a page. right now we have the filter-requestcycle-processor-coding strategy-target-page. everything between the filter and the page is very complicated. we would like to clean it up and simplify it. our url handling is a mess. it is spread all over the aforementioned objects - encoding, decoding, parameter resolving, relative path calculations, context path calculations, etc, etc. we would like to create a value object to represent the url, and centralize all that logic inside. we also intend to make it simpler to create custom coding strategies, as well as mount non-page-related handlers onto urls. further, a stretch goal would be to unify the handling of resources with this scheme. currently resources are handled via SharedResources and are completely separate from the normal process. its more stuff to learn and to understand for users, hopefully we can rebuild resources to work via the same process as everything else - thus the non-page-related handlers mentioned above. these are all rough ideas, we havent really talked much about them but prototyped some code to see what this can potentially look like. -igor On Thu, Aug 20, 2009 at 1:33 PM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: It would be nice to get some guidance towards the goals, and architecture of your new design before we commit to it. Just looking at the code doesn't reveal intention or the bigger picture. Martijn On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote: Hi, actually the changes in 1.5 might be quite drastic as far as wicket internals are concerned. I've already rewritten the request cycle, url processing and page management. I'm not sure how much of it will actually get to trunk though. You can take a look at the code here if you are interested: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ Note that this is pretty much a prototype. While the request cycle, url processing and page management work, the rest of wicket is more or less mocked. Also right now it only covers regular request processing. I don't know enough about portlets to build in portlet support. I'm not even sure the architecture is flexible enough to allow seamless portlet integration. That said, it would be much probably lot easier and cleaner to refactor this code than to add add portlets to existing wicket trunk - which always feel like a hack to me. -Matej On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbsantony.stu...@gmail.com wrote: There us already a working patch since early this year. I just need to update it to trunk which shouldn't be a big deal. Regards, Antony Stubbs website: sharca.com On 20/08/2009, at 7:58 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: come up with a proposal we can discuss. when we hash out the idea then come up with a patch. proposal==patch is fine as far as you dont mind refactoring as we iterate. -igor On Thu, Aug 20, 2009 at 9:51 AM, Antony Stubbsantony.stu...@gmail.com wrote: Apologies if this is known, but is there anywhere noted the plan for 1.5? Also, I'd like to look back at the portal events work I did, and try and get that into 1.5. What would be the process for doing so? In terms of making a branch, or just re-patching, or do I just need to get the final OK from Ate? Cheers, Antony Stubbs, sharca.com On 20/08/2009, at 5:10 PM, Igor Vaynberg wrote: Wicket 1.4.x has been branched and now lives in https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x Trunk is now what will become 1.5.0. Trunk may be broken in the early days of development and contain a lot of API breaks, so if you are following bleeding edge you may want to do so on the 1.4.x branch for a while. -igor - To unsubscribe, e-mail:
Re: [announce] wicket 1.4.x branched
Wow.. Cool.. Thanks! Another one that I had trouble with was ModelListMyPojo I'm guessing cuz the compiler/ide doesn't see List as Serializable. D/ On 8/20/09 5:57 PM, Matej Knopp matej.kn...@gmail.com wrote: If your component does not use model you can use Void. -Matej On Fri, Aug 21, 2009 at 12:54 AM, Douglas Fergusondoug...@douglasferguson.us wrote: No.. I just finally set our pom to 1.4 and dealing with the 4,000 warnings! I'm wondering what other folks are doing for thinks like Link(s) or simple components that don't make use of a model. In some cases I've just added String to make eclipse stop complaining... I'll look into @RequireHttps, but now that I have it working, I'm not sure I'll touch it. Are there good docs on it anywhere? D/ On 8/20/09 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: have you seen @RequireHttps in 1.4? it is a pita, but its doable. -igor On Thu, Aug 20, 2009 at 1:53 PM, Douglas Fergusondoug...@douglasferguson.us wrote: I agree that this area could benefit from a redesign. I specifically found it difficult when writing a RequestHandler that would redirect request from ssl to non-ssl depending no the page type. I.E. Login is redirected to HTTPS, then regular page redirects you back to HTTP D/ On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the intention is to drastically simply the process of going from a url to a page. right now we have the filter-requestcycle-processor-coding strategy-target-page. everything between the filter and the page is very complicated. we would like to clean it up and simplify it. our url handling is a mess. it is spread all over the aforementioned objects - encoding, decoding, parameter resolving, relative path calculations, context path calculations, etc, etc. we would like to create a value object to represent the url, and centralize all that logic inside. we also intend to make it simpler to create custom coding strategies, as well as mount non-page-related handlers onto urls. further, a stretch goal would be to unify the handling of resources with this scheme. currently resources are handled via SharedResources and are completely separate from the normal process. its more stuff to learn and to understand for users, hopefully we can rebuild resources to work via the same process as everything else - thus the non-page-related handlers mentioned above. these are all rough ideas, we havent really talked much about them but prototyped some code to see what this can potentially look like. -igor On Thu, Aug 20, 2009 at 1:33 PM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: It would be nice to get some guidance towards the goals, and architecture of your new design before we commit to it. Just looking at the code doesn't reveal intention or the bigger picture. Martijn On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote: Hi, actually the changes in 1.5 might be quite drastic as far as wicket internals are concerned. I've already rewritten the request cycle, url processing and page management. I'm not sure how much of it will actually get to trunk though. You can take a look at the code here if you are interested: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ Note that this is pretty much a prototype. While the request cycle, url processing and page management work, the rest of wicket is more or less mocked. Also right now it only covers regular request processing. I don't know enough about portlets to build in portlet support. I'm not even sure the architecture is flexible enough to allow seamless portlet integration. That said, it would be much probably lot easier and cleaner to refactor this code than to add add portlets to existing wicket trunk - which always feel like a hack to me. -Matej On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbsantony.stu...@gmail.com wrote: There us already a working patch since early this year. I just need to update it to trunk which shouldn't be a big deal. Regards, Antony Stubbs website: sharca.com On 20/08/2009, at 7:58 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: come up with a proposal we can discuss. when we hash out the idea then come up with a patch. proposal==patch is fine as far as you dont mind refactoring as we iterate. -igor On Thu, Aug 20, 2009 at 9:51 AM, Antony Stubbsantony.stu...@gmail.com wrote: Apologies if this is known, but is there anywhere noted the plan for 1.5? Also, I'd like to look back at the portal events work I did, and try and get that into 1.5. What would be the process for doing so? In terms of making a branch, or just re-patching, or do I just need to get the final OK from Ate? Cheers, Antony Stubbs, sharca.com On 20/08/2009, at 5:10 PM, Igor Vaynberg wrote: Wicket 1.4.x has been branched and now lives in
Re: [announce] wicket 1.4.x branched
Sorry.. I know.. Didn't mean for it to go there. On 8/20/09 6:05 PM, Matej Knopp matej.kn...@gmail.com wrote: This really isn't the right thread... -Matej On Fri, Aug 21, 2009 at 1:03 AM, Douglas Fergusondoug...@douglasferguson.us wrote: Wow.. Cool.. Thanks! Another one that I had trouble with was ModelListMyPojo I'm guessing cuz the compiler/ide doesn't see List as Serializable. D/ On 8/20/09 5:57 PM, Matej Knopp matej.kn...@gmail.com wrote: If your component does not use model you can use Void. -Matej On Fri, Aug 21, 2009 at 12:54 AM, Douglas Fergusondoug...@douglasferguson.us wrote: No.. I just finally set our pom to 1.4 and dealing with the 4,000 warnings! I'm wondering what other folks are doing for thinks like Link(s) or simple components that don't make use of a model. In some cases I've just added String to make eclipse stop complaining... I'll look into @RequireHttps, but now that I have it working, I'm not sure I'll touch it. Are there good docs on it anywhere? D/ On 8/20/09 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: have you seen @RequireHttps in 1.4? it is a pita, but its doable. -igor On Thu, Aug 20, 2009 at 1:53 PM, Douglas Fergusondoug...@douglasferguson.us wrote: I agree that this area could benefit from a redesign. I specifically found it difficult when writing a RequestHandler that would redirect request from ssl to non-ssl depending no the page type. I.E. Login is redirected to HTTPS, then regular page redirects you back to HTTP D/ On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the intention is to drastically simply the process of going from a url to a page. right now we have the filter-requestcycle-processor-coding strategy-target-page. everything between the filter and the page is very complicated. we would like to clean it up and simplify it. our url handling is a mess. it is spread all over the aforementioned objects - encoding, decoding, parameter resolving, relative path calculations, context path calculations, etc, etc. we would like to create a value object to represent the url, and centralize all that logic inside. we also intend to make it simpler to create custom coding strategies, as well as mount non-page-related handlers onto urls. further, a stretch goal would be to unify the handling of resources with this scheme. currently resources are handled via SharedResources and are completely separate from the normal process. its more stuff to learn and to understand for users, hopefully we can rebuild resources to work via the same process as everything else - thus the non-page-related handlers mentioned above. these are all rough ideas, we havent really talked much about them but prototyped some code to see what this can potentially look like. -igor On Thu, Aug 20, 2009 at 1:33 PM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: It would be nice to get some guidance towards the goals, and architecture of your new design before we commit to it. Just looking at the code doesn't reveal intention or the bigger picture. Martijn On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote: Hi, actually the changes in 1.5 might be quite drastic as far as wicket internals are concerned. I've already rewritten the request cycle, url processing and page management. I'm not sure how much of it will actually get to trunk though. You can take a look at the code here if you are interested: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ Note that this is pretty much a prototype. While the request cycle, url processing and page management work, the rest of wicket is more or less mocked. Also right now it only covers regular request processing. I don't know enough about portlets to build in portlet support. I'm not even sure the architecture is flexible enough to allow seamless portlet integration. That said, it would be much probably lot easier and cleaner to refactor this code than to add add portlets to existing wicket trunk - which always feel like a hack to me. -Matej On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbsantony.stu...@gmail.com wrote: There us already a working patch since early this year. I just need to update it to trunk which shouldn't be a big deal. Regards, Antony Stubbs website: sharca.com On 20/08/2009, at 7:58 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: come up with a proposal we can discuss. when we hash out the idea then come up with a patch. proposal==patch is fine as far as you dont mind refactoring as we iterate. -igor On Thu, Aug 20, 2009 at 9:51 AM, Antony Stubbsantony.stu...@gmail.com wrote: Apologies if this is known, but is there anywhere noted the plan for 1.5? Also, I'd like to look back at the portal events work I did, and try and get that into 1.5. What would be the process for doing so? In terms of making a branch, or just
Re: [announce] wicket 1.4.x branched
It seems odd to throw an exception to control flow in a non error state, that's why I was suggesting that you consider a different approach in 1.5 D/ On 8/20/09 6:03 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: thats why we have RestartResponseException(page) -igor On Thu, Aug 20, 2009 at 4:01 PM, Douglas Fergusondoug...@douglasferguson.us wrote: Something that I've encounter that I found frustrating that might be worth considering in the new design: Construct a page... Realize you need to forward to another page, Call setResponsePage(...) If the constructor short circuits when it realizes that the request is getting forwarded, Wicket will blow up if you haven't added all the components because it wants to finish building everything before the response is Fowarded. D/ On 8/20/09 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: have you seen @RequireHttps in 1.4? it is a pita, but its doable. -igor On Thu, Aug 20, 2009 at 1:53 PM, Douglas Fergusondoug...@douglasferguson.us wrote: I agree that this area could benefit from a redesign. I specifically found it difficult when writing a RequestHandler that would redirect request from ssl to non-ssl depending no the page type. I.E. Login is redirected to HTTPS, then regular page redirects you back to HTTP D/ On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the intention is to drastically simply the process of going from a url to a page. right now we have the filter-requestcycle-processor-coding strategy-target-page. everything between the filter and the page is very complicated. we would like to clean it up and simplify it. our url handling is a mess. it is spread all over the aforementioned objects - encoding, decoding, parameter resolving, relative path calculations, context path calculations, etc, etc. we would like to create a value object to represent the url, and centralize all that logic inside. we also intend to make it simpler to create custom coding strategies, as well as mount non-page-related handlers onto urls. further, a stretch goal would be to unify the handling of resources with this scheme. currently resources are handled via SharedResources and are completely separate from the normal process. its more stuff to learn and to understand for users, hopefully we can rebuild resources to work via the same process as everything else - thus the non-page-related handlers mentioned above. these are all rough ideas, we havent really talked much about them but prototyped some code to see what this can potentially look like. -igor On Thu, Aug 20, 2009 at 1:33 PM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: It would be nice to get some guidance towards the goals, and architecture of your new design before we commit to it. Just looking at the code doesn't reveal intention or the bigger picture. Martijn On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote: Hi, actually the changes in 1.5 might be quite drastic as far as wicket internals are concerned. I've already rewritten the request cycle, url processing and page management. I'm not sure how much of it will actually get to trunk though. You can take a look at the code here if you are interested: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ Note that this is pretty much a prototype. While the request cycle, url processing and page management work, the rest of wicket is more or less mocked. Also right now it only covers regular request processing. I don't know enough about portlets to build in portlet support. I'm not even sure the architecture is flexible enough to allow seamless portlet integration. That said, it would be much probably lot easier and cleaner to refactor this code than to add add portlets to existing wicket trunk - which always feel like a hack to me. -Matej On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbsantony.stu...@gmail.com wrote: There us already a working patch since early this year. I just need to update it to trunk which shouldn't be a big deal. Regards, Antony Stubbs website: sharca.com On 20/08/2009, at 7:58 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: come up with a proposal we can discuss. when we hash out the idea then come up with a patch. proposal==patch is fine as far as you dont mind refactoring as we iterate. -igor On Thu, Aug 20, 2009 at 9:51 AM, Antony Stubbsantony.stu...@gmail.com wrote: Apologies if this is known, but is there anywhere noted the plan for 1.5? Also, I'd like to look back at the portal events work I did, and try and get that into 1.5. What would be the process for doing so? In terms of making a branch, or just re-patching, or do I just need to get the final OK from Ate? Cheers, Antony Stubbs, sharca.com On 20/08/2009, at 5:10 PM, Igor Vaynberg wrote: Wicket 1.4.x has been branched and now lives in
Re: [announce] wicket 1.4.x branched
It isn't my constructor I'm trying to abort. It is the wicket code that expects me to add certain objects to the page. If I've already told it that I want to forward to another page, why should it care that I didn't add X component to the page or the heirarchy doesn't match D/ On 8/20/09 6:14 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: doesnt seem that weird if you want to abort the creation of an object - that is what you want here dont you? if you know of another construct in java that will let us do that i am all ears. -igor On Thu, Aug 20, 2009 at 4:10 PM, Douglas Fergusondoug...@douglasferguson.us wrote: It seems odd to throw an exception to control flow in a non error state, that's why I was suggesting that you consider a different approach in 1.5 D/ On 8/20/09 6:03 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: thats why we have RestartResponseException(page) -igor On Thu, Aug 20, 2009 at 4:01 PM, Douglas Fergusondoug...@douglasferguson.us wrote: Something that I've encounter that I found frustrating that might be worth considering in the new design: Construct a page... Realize you need to forward to another page, Call setResponsePage(...) If the constructor short circuits when it realizes that the request is getting forwarded, Wicket will blow up if you haven't added all the components because it wants to finish building everything before the response is Fowarded. D/ On 8/20/09 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: have you seen @RequireHttps in 1.4? it is a pita, but its doable. -igor On Thu, Aug 20, 2009 at 1:53 PM, Douglas Fergusondoug...@douglasferguson.us wrote: I agree that this area could benefit from a redesign. I specifically found it difficult when writing a RequestHandler that would redirect request from ssl to non-ssl depending no the page type. I.E. Login is redirected to HTTPS, then regular page redirects you back to HTTP D/ On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the intention is to drastically simply the process of going from a url to a page. right now we have the filter-requestcycle-processor-coding strategy-target-page. everything between the filter and the page is very complicated. we would like to clean it up and simplify it. our url handling is a mess. it is spread all over the aforementioned objects - encoding, decoding, parameter resolving, relative path calculations, context path calculations, etc, etc. we would like to create a value object to represent the url, and centralize all that logic inside. we also intend to make it simpler to create custom coding strategies, as well as mount non-page-related handlers onto urls. further, a stretch goal would be to unify the handling of resources with this scheme. currently resources are handled via SharedResources and are completely separate from the normal process. its more stuff to learn and to understand for users, hopefully we can rebuild resources to work via the same process as everything else - thus the non-page-related handlers mentioned above. these are all rough ideas, we havent really talked much about them but prototyped some code to see what this can potentially look like. -igor On Thu, Aug 20, 2009 at 1:33 PM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: It would be nice to get some guidance towards the goals, and architecture of your new design before we commit to it. Just looking at the code doesn't reveal intention or the bigger picture. Martijn On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote: Hi, actually the changes in 1.5 might be quite drastic as far as wicket internals are concerned. I've already rewritten the request cycle, url processing and page management. I'm not sure how much of it will actually get to trunk though. You can take a look at the code here if you are interested: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ Note that this is pretty much a prototype. While the request cycle, url processing and page management work, the rest of wicket is more or less mocked. Also right now it only covers regular request processing. I don't know enough about portlets to build in portlet support. I'm not even sure the architecture is flexible enough to allow seamless portlet integration. That said, it would be much probably lot easier and cleaner to refactor this code than to add add portlets to existing wicket trunk - which always feel like a hack to me. -Matej On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbsantony.stu...@gmail.com wrote: There us already a working patch since early this year. I just need to update it to trunk which shouldn't be a big deal. Regards, Antony Stubbs website: sharca.com On 20/08/2009, at 7:58 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: come up with a proposal we can discuss. when we hash out the idea then come up with a patch.
Re: [announce] wicket 1.4.x branched
This is what I tried to do that would error out.
Page(){
if(condition){
setResponsePage()
}else{
//add components
}
}
On 8/20/09 6:26 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
On Thu, Aug 20, 2009 at 4:19 PM, Douglas
Fergusondoug...@douglasferguson.us wrote:
It isn't my constructor I'm trying to abort.
no? so you let it finish running after setresponsepage()?
-igor
It is the wicket code that expects me to add certain objects to the page.
If I've already told it that I want to forward to another page, why should it
care that I didn't add X component to the page or the heirarchy doesn't
match
D/
On 8/20/09 6:14 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
doesnt seem that weird if you want to abort the creation of an object
- that is what you want here dont you? if you know of another
construct in java that will let us do that i am all ears.
-igor
On Thu, Aug 20, 2009 at 4:10 PM, Douglas
Fergusondoug...@douglasferguson.us wrote:
It seems odd to throw an exception to control flow in a non error state,
that's why I was suggesting that you consider a different approach in 1.5
D/
On 8/20/09 6:03 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
thats why we have RestartResponseException(page)
-igor
On Thu, Aug 20, 2009 at 4:01 PM, Douglas
Fergusondoug...@douglasferguson.us wrote:
Something that I've encounter that I found frustrating that might be worth
considering in the new design:
Construct a page...
Realize you need to forward to another page,
Call setResponsePage(...)
If the constructor short circuits when it realizes that the request is
getting forwarded,
Wicket will blow up if you haven't added all the components because it
wants to finish building everything before the response is Fowarded.
D/
On 8/20/09 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
have you seen @RequireHttps in 1.4? it is a pita, but its doable.
-igor
On Thu, Aug 20, 2009 at 1:53 PM, Douglas
Fergusondoug...@douglasferguson.us wrote:
I agree that this area could benefit from a redesign.
I specifically found it difficult when writing a RequestHandler that would
redirect request from ssl to non-ssl depending no the page type.
I.E. Login is redirected to HTTPS, then regular page redirects you back to
HTTP
D/
On 8/20/09 3:46 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
the intention is to drastically simply the process of going from a url
to a page.
right now we have the filter-requestcycle-processor-coding
strategy-target-page. everything between the filter and the page is
very complicated. we would like to clean it up and simplify it.
our url handling is a mess. it is spread all over the aforementioned
objects - encoding, decoding, parameter resolving, relative path
calculations, context path calculations, etc, etc. we would like to
create a value object to represent the url, and centralize all that
logic inside.
we also intend to make it simpler to create custom coding strategies,
as well as mount non-page-related handlers onto urls.
further, a stretch goal would be to unify the handling of resources
with this scheme. currently resources are handled via SharedResources
and are completely separate from the normal process. its more stuff to
learn and to understand for users, hopefully we can rebuild resources
to work via the same process as everything else - thus the
non-page-related handlers mentioned above.
these are all rough ideas, we havent really talked much about them but
prototyped some code to see what this can potentially look like.
-igor
On Thu, Aug 20, 2009 at 1:33 PM, Martijn
Dashorstmartijn.dasho...@gmail.com wrote:
It would be nice to get some guidance towards the goals, and
architecture of your new design before we commit to it. Just looking
at the code doesn't reveal intention or the bigger picture.
Martijn
On Thu, Aug 20, 2009 at 8:09 PM, Matej Knoppmatej.kn...@gmail.com wrote:
Hi,
actually the changes in 1.5 might be quite drastic as far as wicket
internals are concerned. I've already rewritten the request cycle, url
processing and page management. I'm not sure how much of it will
actually get to trunk though. You can take a look at the code here if
you are interested:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/
Note that this is pretty much a prototype. While the request cycle,
url processing and page management work, the rest of wicket is more or
less mocked.
Also right now it only covers regular request processing. I don't know
enough about portlets to build in portlet support. I'm not even sure
the architecture is flexible enough to allow seamless portlet
integration. That said, it would be much probably lot easier and
cleaner to refactor this code than to add add portlets to existing
wicket trunk - which always feel like a hack to me.
-Matej
On Thu, Aug 20, 2009 at 8:03 PM, Antony
