On Aug 23, bernard01 commented
(https://gist.github.com/dashorst/6308833/#comment-892525):
I find it very clean and extremely easy to deal with
PageParameters.
I disagree. I find PageParameters a cumbersome and leaky abstraction.
I find it tedious to have to handcraft the parameters each time,
I have moved the RFC to a github repository so that it can be tracked
more easily, and that you can comment inline into the document. If you
wish to help out by writing parts, I can add you as a committer to the
repository.
Also, the document has been expanded with query parameters (4.3) and
bean
I see that
1.1.3 How Other Web Technologies Work
explains how type safety can work with a single complex parameters
container @BeanParam.
@BeanParam functions both as the converter that I have been referring
to and as a PageParameters replacement.
My concern is multiple parameters where the
Am 23.08.13 00:16, schrieb Martijn Dashorst:
On Thu, Aug 22, 2013 at 11:42 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
On Thu, Aug 22, 2013 at 2:04 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
still need
pageparameters to carry those params forward in bookmarkablelink, etc.
Not
no magic (or the option of no magic) +1
On Mon, Aug 26, 2013 at 3:41 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 23.08.13 00:16, schrieb Martijn Dashorst:
On Thu, Aug 22, 2013 at 11:42 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
On Thu, Aug 22, 2013 at 2:04 PM, Martijn
Hi,
As I said in the gist comments my main concern is that this RFC doesn't
solve a real problem.
There are no issues with the PageParameters now. There are no complains in
users@ about them...
But I also know that the volunteer work on Open Source projects is driven
by interest - either company
Hi Martin,
On Fri, Aug 23, 2013 at 10:51 AM, Martin Grigorov mgrigo...@apache.org wrote:
As I said in the gist comments my main concern is that this RFC doesn't
solve a real problem.
There are no issues with the PageParameters now. There are no complains in
users@ about them...
Well, we
Hi Martijn,
On Thu, Aug 22, 2013 at 5:55 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
So we started to write an RFC for Wicket, trying to document exactly what
we want to change and how it should behave. It is quite a work in progress,
but I like the first baby steps.
Nice work.
I haven't had time to read the proposal in its entirety yet, so I just
skimmed it. My first impression is pretty good. There are of course
some things still missing, such as programmatically changing page
parameters to update the displayed URL in the browser, and centralized
mounting.
I'm not
Cedric Gatay commented: https://gist.github.com/dashorst/6308833/#comment-891946
There is nothing regarding the use of optional parameters. How
should we handle this use case, should we use multiple constructors
[1] or should we use a @DefaultValue annotation [2] to stay on par
with Jax-RS API
Andrea del Bene commented:
https://gist.github.com/dashorst/6308833/#comment-892169
I have to finish yet to read the complete rfc document. I agree
that sometimes PageParameters can generate a little bit of
confusion when we use them with page constructor or links. I also
agree that the code
Martin Grigorov commented:
https://gist.github.com/dashorst/6308833/#comment-892137
7.1.3 setResponsePage(Class?, PageParameters) removed
What will be the new way to make a redirect with path and/or query parameters
?
It says TODO in the RFC for a reason.
I'm inclined to propose something
Martin Grigorov commented:
https://gist.github.com/dashorst/6308833/#comment-892138
org.apache.wicket.request.resource.IResource#respond
At the moment one could have:
- a stateless resource - the mounted resource reference create a new
IResource for each request
- a stateful resource -
On Fri, Aug 23, 2013 at 4:19 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
Martin Grigorov commented:
https://gist.github.com/dashorst/6308833/#comment-892138
org.apache.wicket.request.resource.IResource#respond
At the moment one could have:
- a stateless resource - the
On Fri, Aug 23, 2013 at 3:28 PM, Martin Grigorov mgrigo...@apache.org wrote:
I'd like to extend to pages as well: have stateful pages be able to
respond to updated request parameters.
See https://issues.apache.org/jira/browse/WICKET-4441
I know of 3 users complained with this problem. Don't
About changing parameters on stateful pages, one comment: one thing that
makes Wicket secure by default is exactly the fact that you get the
parameters when you create a page, and everything after is made by
interacting with components (which don't process values if disabled,
invisible, or
In the previous thread where I spin this message from it was mentioned by
Emond that he and I were discussing request parameters and how Wicket
handles them.
It occurred to me that the PageParameters construct is still with us from
2004 and that it hasn't changed much since. In fact I'd posit
By deprecate I hope you don't mean remove. This change would break almost
every single wicket application ever written.
On Thu, Aug 22, 2013 at 9:55 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
In the previous thread where I spin this message from it was mentioned by
Emond that he
On Thu, Aug 22, 2013 at 6:24 PM, Ben Tilford bentilf...@gmail.com wrote:
By deprecate I hope you don't mean remove. This change would break
almost every single wicket application ever written.
Yes I do mean remove. And yes that will break a lot of
applications, and that is why we have semantic
On Thu, Aug 22, 2013 at 6:30 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i added a bunch of comments in the gist. not sure why we couldnt just do
it
here in place
We can sure discuss it here, like I told you on ##wicket. I just
don't think posting a 200+ line document that still needs
Ronaldtm commented: https://gist.github.com/dashorst/6308833/#comment-891818
What if you have many pages that receive the same parameters, and
those have to be converted to a TO?
For that one can use the @BeanParam, which I intend to model similar
to the JAX-RS implementation. Basically it is a
I have updated the RFC with a section concerning legacy code and the
migration scenarios. See section 7 of the RFC, to be found at the same
location as the previous one: https://gist.github.com/dashorst/6308833
Nice feature of the gists is that you can see the diffs of each edit.
Martijn
On
There really isn't a good reason to remove them even if parameter injection
is added. If they have to be removed at least deprecate and remove in v 8.
On Thu, Aug 22, 2013 at 12:26 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
On Thu, Aug 22, 2013 at 6:24 PM, Ben Tilford
On Thu, Aug 22, 2013 at 10:09 PM, Ben Tilford bentilf...@gmail.com wrote:
There really isn't a good reason to remove them even if parameter injection
is added.
Yes there is:
- removing maintenance burden
- removing confusion
- making the implementation of the new API feasible.
Removing
On Thu, Aug 22, 2013 at 11:42 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
On Thu, Aug 22, 2013 at 2:04 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
On Thu, Aug 22, 2013 at 10:09 PM, Ben Tilford bentilf...@gmail.com wrote:
There really isn't a good reason to remove them even
25 matches
Mail list logo
