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 Ferguson<doug...@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 > Ferguson<doug...@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 >> 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 >>>> >>> >>> >> >> > >
