looks like you are aborting the constructor to me.
-igor
On Thu, Aug 20, 2009 at 5:04 PM, Douglas
Ferguson<doug...@douglasferguson.us> wrote:
> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
