[announce] wicket 1.4.x branched

[igor.vaynberg]

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

[Antony Stubbs]

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-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

[jthomerson]

On Thu, Aug 20, 2009 at 11:51 AM, Antony Stubbs<antony.stubbs@...> wrote:
> Apologies if this is known, but is there anywhere noted the plan for 1.5?

http://www.google.com/search?q=wicket+1.5
http://cwiki.apache.org/WICKET/wicket-15-wish-list.html

> 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-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>

[Antony Stubbs]

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.vaynberg@...>  
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.stubbs@...> 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-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>>

[Matej Knopp]

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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>> 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-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>>
>

[Martijn Dashorst]

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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>> 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-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>>
>>
>

--
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

[igor.vaynberg]

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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>> 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-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>>
>>>
>>
>
>
>
> --
> 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
>

[jthomerson]

+100

as a side note, I work for an audio and web conferencing company, so
if at some point it would be beneficial for the developers to actually
*talk* about this over phone, or collaborate online, let me know and I
can setup an account for this.  we have or can obtain numbers in quite
a few countries, so it is possible that most of the devs could call in
locally.

the company is: genericconf.com

--
Jeremy Thomerson
http://www.wickettraining.com




On Thu, Aug 20, 2009 at 3:46 PM, Igor Vaynberg<igor.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>> 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-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> 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
>>
>

[Douglas Ferguson-2]

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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>> 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-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>>
>>>
>>
>
>
>
> --
> 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
>

[igor.vaynberg]

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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>> 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-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> 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
>>
>
>

[Matej Knopp]

I'll try to find some time to write an overview of the experimental
branch. But the code is an order of magnitude simpler than current
Wicket codes and about the same amount less tangled. It also does lot
less though :) (some of that is intentional).

I have basically rewritten the most messy parts of Wicket (request
cycle, url processing, page management). Some of it is done, some
still needs work. It is however not a drop in replacement for current
wicket internals. It will require substantial effort to integrate. So
before I even consider doing that I'd really like for some people to
take a look at it.

Also I'm not sure if the architecture is flexible enough to support
portlets without having to do various hacks like in current wicket. So
it would be really nice if someone who has experience with building
support for portlets took a look and told me what needs to be
improved.

-Matej

On Thu, Aug 20, 2009 at 10:33 PM, Martijn
Dashorst<martijn.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>> 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-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>>
>>>
>>
>
>
>
> --
> 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
>

[Douglas Ferguson-2]

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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>> 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-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> 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
>>
>
>

[Matej Knopp]

If your component does not use model you can use <Void>.

-Matej

On Fri, Aug 21, 2009 at 12:54 AM, Douglas
Ferguson<douglas@...> 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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>>> 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-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
>

[Douglas Ferguson-2]

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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>> 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-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> 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
>>
>
>

[igor.vaynberg]

thats why we have RestartResponseException(page)

-igor

On Thu, Aug 20, 2009 at 4:01 PM, Douglas
Ferguson<douglas@...> 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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>>> 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-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
>

[Douglas Ferguson-2]

Wow.. Cool.. Thanks!

Another one that I had trouble with was Model<List<MyPojo>>
I'm guessing cuz the compiler/ide doesn't see List as Serializable.

D/


On 8/20/09 5:57 PM, "Matej Knopp" <matej.knopp@...> wrote:

If your component does not use model you can use <Void>.

-Matej

On Fri, Aug 21, 2009 at 12:54 AM, Douglas
Ferguson<douglas@...> 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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>>> 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-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
>

[Matej Knopp]

This really isn't the right thread...

-Matej

On Fri, Aug 21, 2009 at 1:03 AM, Douglas
Ferguson<douglas@...> wrote:

> Wow.. Cool.. Thanks!
>
> Another one that I had trouble with was Model<List<MyPojo>>
> I'm guessing cuz the compiler/ide doesn't see List as Serializable.
>
> D/
>
>
> On 8/20/09 5:57 PM, "Matej Knopp" <matej.knopp@...> wrote:
>
> If your component does not use model you can use <Void>.
>
> -Matej
>
> On Fri, Aug 21, 2009 at 12:54 AM, Douglas
> Ferguson<douglas@...> 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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>>>> 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-unsubscribe@...
>>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>
>>
>
>

[Douglas Ferguson-2]

Sorry.. I know.. Didn't mean for it to go there.


On 8/20/09 6:05 PM, "Matej Knopp" <matej.knopp@...> wrote:

This really isn't the right thread...

-Matej

On Fri, Aug 21, 2009 at 1:03 AM, Douglas
Ferguson<douglas@...> wrote:

> Wow.. Cool.. Thanks!
>
> Another one that I had trouble with was Model<List<MyPojo>>
> I'm guessing cuz the compiler/ide doesn't see List as Serializable.
>
> D/
>
>
> On 8/20/09 5:57 PM, "Matej Knopp" <matej.knopp@...> wrote:
>
> If your component does not use model you can use <Void>.
>
> -Matej
>
> On Fri, Aug 21, 2009 at 12:54 AM, Douglas
> Ferguson<douglas@...> 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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>>>> 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-unsubscribe@...
>>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>
>>
>
>

[Douglas Ferguson-2]

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.vaynberg@...> wrote:

thats why we have RestartResponseException(page)

-igor

On Thu, Aug 20, 2009 at 4:01 PM, Douglas
Ferguson<douglas@...> 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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>>> 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-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
>

[igor.vaynberg]

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<douglas@...> 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.vaynberg@...> wrote:
>
> thats why we have RestartResponseException(page)
>
> -igor
>
> On Thu, Aug 20, 2009 at 4:01 PM, Douglas
> Ferguson<douglas@...> 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.vaynberg@...> 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<douglas@...> 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.vaynberg@...> 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.dashorst@...> 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.knopp@...> 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.stubbs@...> 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.vaynberg@...> 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.stubbs@...>
>>>>>>> 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-unsubscribe@...
>>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>
>>
>
>