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