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 Ferguson<doug...@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 > Dashorst<martijn.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 Knopp<matej.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 Stubbs<antony.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 Stubbs<antony.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 >> > >
