Re: git commit: Revert WICKET-5647 missing generic cast causes compile error on OS X / jdk 8 since clirr plugin breaks with the change
Hi Peter,
I'm glad to see you again here!
Are you sure that Clirr has problems ?
BuildBot has failed with the JS tests because we use hardcoded value of the
port where NodeJS's connect server binds to.
master branch acquired the port and wicket-6.x failed to bind it.
I think your change is OK but I'll test it right away here.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Jul 17, 2014 at 1:45 PM, p...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/wicket-6.x 00cde3486 - 49782ae6b
Revert WICKET-5647 missing generic cast causes compile error on OS X /
jdk 8 since clirr plugin breaks with the change
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/49782ae6
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/49782ae6
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/49782ae6
Branch: refs/heads/wicket-6.x
Commit: 49782ae6b04b19276d821364cda98eb8565d65fb
Parents: 00cde34
Author: Peter Ertl p...@apache.org
Authored: Thu Jul 17 12:45:08 2014 +0200
Committer: Peter Ertl p...@apache.org
Committed: Thu Jul 17 12:45:08 2014 +0200
--
.../src/main/java/org/apache/wicket/util/value/ValueMap.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/49782ae6/wicket-util/src/main/java/org/apache/wicket/util/value/ValueMap.java
--
diff --git
a/wicket-util/src/main/java/org/apache/wicket/util/value/ValueMap.java
b/wicket-util/src/main/java/org/apache/wicket/util/value/ValueMap.java
index 2592c56..acba07f 100755
--- a/wicket-util/src/main/java/org/apache/wicket/util/value/ValueMap.java
+++ b/wicket-util/src/main/java/org/apache/wicket/util/value/ValueMap.java
@@ -789,7 +789,7 @@ public class ValueMap extends LinkedHashMapString,
Object implements IValueMap
@Override
public T extends EnumT T getAsEnum(final String key, final
ClassT eClass)
{
- return getEnumImpl(key, eClass, (T)null);
+ return getEnumImpl(key, eClass, null);
}
/**
Re: avoiding hard-coding HTML names
Hi, The main problem I see with this is that we cannot cover all possible names. 1) It is possible to create custom HTML elements in JavaScript. So the list of names should be easy to extend 2) with Web Components standard custom names are used even more often 3) and yes, some users use Wicket to generate XML/SVG/... where case sensitivity is important I remember some users wanted to have a list of JS events. The main problem with this before that we had to have both click and onclick before 6.0. Now we don't need the onXYZ version. But again it should be easy to extend because using custom JS event names is also very common in development. Are there that many occurrences of such hardcoded HTML element and event names ? I don't remember having any problems with them for the last 4 years. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Jul 12, 2014 at 11:53 PM, Garret Wilson gar...@globalmentor.com wrote: Hi, all. I notice that throughout the code HTML element and attribute names are hard-coded. Does Wicket have a list of HTML name and attribute constants that we could reference? I would find that a lot safer, and perhaps even more readable. Not only that, it would allow us to quickly find all the places that use the e.g. HTML.Element.EM element. Secondly, in the same vein, I see lots of code like this: if(tag.getName().equalsIgnoreCase(a))... That's also tedious and error-prone---I can't trust myself not to forget to do a case-insensitive comparison. Perhaps there could be a ComponentTag.hasName() method that does this for me? So the above would be: if(tag.hasName(HTML.Element.EM))... On the other hand, perhaps Wicket is wanting to support other contexts such as general XML, in which case case-sensitive matching is necessary. (I would imagine that the entire codebase plays loosely with whether or not matching is case-sensitive, though. More research is necessary on my part.) What do you think at least about having HTML element/attribute constants? That my be an area I can contribute to in the short term. Garret
Re: git commit: Code beautifying: method WebPageRenderer.respond
Hi Andrea,
On Wed, Jul 16, 2014 at 8:33 PM, adelb...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/master c24d830cd - bb9c1044e
Code beautifying: method WebPageRenderer.respond
What exactly beautifying means ?
It is a bit hard to see what is the actual change. It doesn't look like
applying Wicket's code format.
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/bb9c1044
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/bb9c1044
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/bb9c1044
Branch: refs/heads/master
Commit: bb9c1044e5f1ba8902aa69073ef9fb236802d277
Parents: c24d830
Author: andrea del bene adelb...@apache.org
Authored: Wed Jul 16 19:33:16 2014 +0200
Committer: andrea del bene adelb...@apache.org
Committed: Wed Jul 16 19:33:16 2014 +0200
--
.../request/handler/render/WebPageRenderer.java | 169 +--
1 file changed, 82 insertions(+), 87 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/bb9c1044/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
b/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
index 0b5dee4..af9dbee 100644
---
a/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
+++
b/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
@@ -198,99 +198,94 @@ public class WebPageRenderer extends PageRenderer
// if there is saved response for this URL render
it
bufferedResponse.writeTo((WebResponse)requestCycle.getResponse());
}
+ else if (shouldRenderPageAndWriteResponse(requestCycle,
currentUrl, targetUrl))
+ {
+ BufferedWebResponse response =
renderPage(currentUrl, requestCycle);
+ if (response != null)
+ {
+
response.writeTo((WebResponse)requestCycle.getResponse());
+ }
+ }
+ else if (shouldRedirectToTargetUrl(requestCycle,
currentUrl, targetUrl))
+ {
+
+ redirectTo(targetUrl, requestCycle);
+
+ // note: if we had session here we would render
the page to buffer and then
+ // redirect to URL generated *after* page has been
rendered (the statelessness
+ // may change during render). this would save one
redirect because now we have
+ // to render to URL generated *before* page is
rendered, render the page, get
+ // URL after render and if the URL is different
(meaning page is not stateless),
+ // save the buffer and redirect again (which is
pretty much what the next step
+ // does)
+ }
else
{
- if (shouldRenderPageAndWriteResponse(requestCycle,
currentUrl, targetUrl)) //
+ if (isRedirectToBuffer() == false
logger.isDebugEnabled())
+ {
+ String details = String
+ .format(
+ redirect strategy: '%s',
isAjax: '%s', redirect policy: '%s',
+ + current url:
'%s', target url: '%s', is new: '%s', is stateless: '%s', is temporary:
'%s',
+
Application.get().getRequestCycleSettings().getRenderStrategy(),
+ isAjax(requestCycle),
getRedirectPolicy(), currentUrl, targetUrl,
+ isNewPageInstance(),
isPageStateless(), isSessionTemporary());
+ logger
+ .debug(Falling back to
Redirect_To_Buffer render strategy because none of the conditions
+ + matched. Details: +
details);
+ }
+
+ // force creation of possible stateful page to get
the final target url
+ getPage();
+
+ Url beforeRenderUrl =
requestCycle.mapUrlFor(getRenderPageRequestHandler());
+
+ // redirect to buffer
+ BufferedWebResponse response =
renderPage(beforeRenderUrl, requestCycle);
+
+ if (response == null)
+ {
+
Re: avoiding hard-coding HTML names
Not a Java or Wicket article, but interesting nonetheless:
http://inessential.com/2014/07/14/string_constants
I'm not a big fan of putting everything in constants in a central
location. We won't be changing an anchor tag from a to anchor across
all code in Wicket, ever.
There has to be a benefit to making a constant (string). For example,
what is more clear:
public class SomeAbstractLink {
protected void checkTag(Tag t) {
assert t.getName().equals(HtmlTags.ANCHOR);
}
}
or
public class SomeAbstractLink {
protected void checkTag(Tag t) {
assert t.getName().equalsIgnoreCase(a);
}
}
or possibly:
public class SomeAbstractLink {
protected void checkTag(Tag t) {
TagAsserts.tagNameValid(t, a);
}
}
Martijn
On Sat, Jul 12, 2014 at 10:53 PM, Garret Wilson gar...@globalmentor.com wrote:
Hi, all. I notice that throughout the code HTML element and attribute names
are hard-coded. Does Wicket have a list of HTML name and attribute constants
that we could reference? I would find that a lot safer, and perhaps even
more readable. Not only that, it would allow us to quickly find all the
places that use the e.g. HTML.Element.EM element.
Secondly, in the same vein, I see lots of code like this:
if(tag.getName().equalsIgnoreCase(a))...
That's also tedious and error-prone---I can't trust myself not to forget to
do a case-insensitive comparison. Perhaps there could be a
ComponentTag.hasName() method that does this for me? So the above would be:
if(tag.hasName(HTML.Element.EM))...
On the other hand, perhaps Wicket is wanting to support other contexts such
as general XML, in which case case-sensitive matching is necessary. (I would
imagine that the entire codebase plays loosely with whether or not matching
is case-sensitive, though. More research is necessary on my part.)
What do you think at least about having HTML element/attribute constants?
That my be an area I can contribute to in the short term.
Garret
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: git commit: Code beautifying: method WebPageRenderer.respond
Method respond had high level of if...else nesting, a couple of them
useless. in which way the new code doesn't respect Wicket's code format?
Maybe my IDE did something wrong.
Hi Andrea,
On Wed, Jul 16, 2014 at 8:33 PM, adelb...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/master c24d830cd - bb9c1044e
Code beautifying: method WebPageRenderer.respond
What exactly beautifying means ?
It is a bit hard to see what is the actual change. It doesn't look like
applying Wicket's code format.
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/bb9c1044
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/bb9c1044
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/bb9c1044
Branch: refs/heads/master
Commit: bb9c1044e5f1ba8902aa69073ef9fb236802d277
Parents: c24d830
Author: andrea del bene adelb...@apache.org
Authored: Wed Jul 16 19:33:16 2014 +0200
Committer: andrea del bene adelb...@apache.org
Committed: Wed Jul 16 19:33:16 2014 +0200
--
.../request/handler/render/WebPageRenderer.java | 169 +--
1 file changed, 82 insertions(+), 87 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/bb9c1044/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
b/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
index 0b5dee4..af9dbee 100644
---
a/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
+++
b/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java
@@ -198,99 +198,94 @@ public class WebPageRenderer extends PageRenderer
// if there is saved response for this URL render
it
bufferedResponse.writeTo((WebResponse)requestCycle.getResponse());
}
+ else if (shouldRenderPageAndWriteResponse(requestCycle,
currentUrl, targetUrl))
+ {
+ BufferedWebResponse response =
renderPage(currentUrl, requestCycle);
+ if (response != null)
+ {
+
response.writeTo((WebResponse)requestCycle.getResponse());
+ }
+ }
+ else if (shouldRedirectToTargetUrl(requestCycle,
currentUrl, targetUrl))
+ {
+
+ redirectTo(targetUrl, requestCycle);
+
+ // note: if we had session here we would render
the page to buffer and then
+ // redirect to URL generated *after* page has been
rendered (the statelessness
+ // may change during render). this would save one
redirect because now we have
+ // to render to URL generated *before* page is
rendered, render the page, get
+ // URL after render and if the URL is different
(meaning page is not stateless),
+ // save the buffer and redirect again (which is
pretty much what the next step
+ // does)
+ }
else
{
- if (shouldRenderPageAndWriteResponse(requestCycle,
currentUrl, targetUrl)) //
+ if (isRedirectToBuffer() == false
logger.isDebugEnabled())
+ {
+ String details = String
+ .format(
+ redirect strategy: '%s',
isAjax: '%s', redirect policy: '%s',
+ + current url:
'%s', target url: '%s', is new: '%s', is stateless: '%s', is temporary:
'%s',
+
Application.get().getRequestCycleSettings().getRenderStrategy(),
+ isAjax(requestCycle),
getRedirectPolicy(), currentUrl, targetUrl,
+ isNewPageInstance(),
isPageStateless(), isSessionTemporary());
+ logger
+ .debug(Falling back to
Redirect_To_Buffer render strategy because none of the conditions
+ + matched. Details: +
details);
+ }
+
+ // force creation of possible stateful page to get
the final target url
+ getPage();
+
+ Url beforeRenderUrl =
requestCycle.mapUrlFor(getRenderPageRequestHandler());
+
+ // redirect to buffer
+ BufferedWebResponse response =
renderPage(beforeRenderUrl, requestCycle);
+
+
Re: git commit: Code beautifying: method WebPageRenderer.respond
what is/was useless ?
now I am even more confused what your beautification did with this really
important and fragile part of Wicket code :-)
I'm not saying that the new code is badly formatted. I was asking whether
beautification really means code formatting
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Jul 17, 2014 at 5:10 PM, Andrea Del Bene an.delb...@gmail.com
wrote:
Method respond had high level of if...else nesting, a couple of them
useless. in which way the new code doesn't respect Wicket's code format?
Maybe my IDE did something wrong.
Hi Andrea,
On Wed, Jul 16, 2014 at 8:33 PM, adelb...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/master c24d830cd - bb9c1044e
Code beautifying: method WebPageRenderer.respond
What exactly beautifying means ?
It is a bit hard to see what is the actual change. It doesn't look like
applying Wicket's code format.
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/bb9c1044
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/bb9c1044
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/bb9c1044
Branch: refs/heads/master
Commit: bb9c1044e5f1ba8902aa69073ef9fb236802d277
Parents: c24d830
Author: andrea del bene adelb...@apache.org
Authored: Wed Jul 16 19:33:16 2014 +0200
Committer: andrea del bene adelb...@apache.org
Committed: Wed Jul 16 19:33:16 2014 +0200
--
.../request/handler/render/WebPageRenderer.java | 169
+--
1 file changed, 82 insertions(+), 87 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/
bb9c1044/wicket-core/src/main/java/org/apache/wicket/
request/handler/render/WebPageRenderer.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/request/handler/render/
WebPageRenderer.java
b/wicket-core/src/main/java/org/apache/wicket/request/handler/render/
WebPageRenderer.java
index 0b5dee4..af9dbee 100644
---
a/wicket-core/src/main/java/org/apache/wicket/request/handler/render/
WebPageRenderer.java
+++
b/wicket-core/src/main/java/org/apache/wicket/request/handler/render/
WebPageRenderer.java
@@ -198,99 +198,94 @@ public class WebPageRenderer extends PageRenderer
// if there is saved response for this URL
render
it
bufferedResponse.writeTo((WebResponse)requestCycle.getResponse());
}
+ else if (shouldRenderPageAndWriteResponse(requestCycle,
currentUrl, targetUrl))
+ {
+ BufferedWebResponse response =
renderPage(currentUrl, requestCycle);
+ if (response != null)
+ {
+
response.writeTo((WebResponse)requestCycle.getResponse());
+ }
+ }
+ else if (shouldRedirectToTargetUrl(requestCycle,
currentUrl, targetUrl))
+ {
+
+ redirectTo(targetUrl, requestCycle);
+
+ // note: if we had session here we would render
the page to buffer and then
+ // redirect to URL generated *after* page has
been
rendered (the statelessness
+ // may change during render). this would save one
redirect because now we have
+ // to render to URL generated *before* page is
rendered, render the page, get
+ // URL after render and if the URL is different
(meaning page is not stateless),
+ // save the buffer and redirect again (which is
pretty much what the next step
+ // does)
+ }
else
{
- if (shouldRenderPageAndWriteRespon
se(requestCycle,
currentUrl, targetUrl)) //
+ if (isRedirectToBuffer() == false
logger.isDebugEnabled())
+ {
+ String details = String
+ .format(
+ redirect strategy: '%s',
isAjax: '%s', redirect policy: '%s',
+ + current url:
'%s', target url: '%s', is new: '%s', is stateless: '%s', is temporary:
'%s',
+
Application.get().getRequestCycleSettings().getRenderStrategy(),
+ isAjax(requestCycle),
getRedirectPolicy(), currentUrl, targetUrl,
+ isNewPageInstance(),
isPageStateless(), isSessionTemporary());
+ logger
+ .debug(Falling back to
Redirect_To_Buffer render strategy
Re: git commit: Code beautifying: method WebPageRenderer.respond
OK. Thanks!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Jul 17, 2014 at 5:53 PM, Andrea Del Bene an.delb...@gmail.com
wrote:
I admit I've changed a very sensible part of the code :), however after
working with it I realized that we could reduce its complexity removing a
couple of nesting levels merging them in the outer if...else block. I
think this improve code quality and its readability. Let me explain you
what I did. The code was:
if (bufferedResponse != null)
{
logger
.warn(The Buffered response should be handled by
BufferedResponseRequestHandler);
// if there is saved response for this URL render it
bufferedResponse.writeTo((WebResponse)requestCycle.getResponse());
}
else
{
if (shouldRenderPageAndWriteResponse(requestCycle,
currentUrl, targetUrl)) //
{
BufferedWebResponse response = renderPage(currentUrl,
requestCycle);
if (response != null)
{
response.writeTo((WebResponse)requestCycle.getResponse());
}
}
else
{
if (shouldRedirectToTargetUrl(requestCycle, currentUrl,
targetUrl))
{
redirectTo(targetUrl, requestCycle);
// note: if we had session here we would render the
page to buffer and then
// redirect to URL generated *after* page has been
rendered (the statelessness
// may change during render). this would save one
redirect because now we have
// to render to URL generated *before* page is
rendered, render the page, get
// URL after render and if the URL is different
(meaning page is not stateless),
// save the buffer and redirect again (which is pretty
much what the next step
// does)
}
else
..etc.
now is
if (bufferedResponse != null)
{
logger
.warn(The Buffered response should be handled by
BufferedResponseRequestHandler);
// if there is saved response for this URL render it
bufferedResponse.writeTo((WebResponse)requestCycle.getResponse());
}
else if (shouldRenderPageAndWriteResponse(requestCycle,
currentUrl, targetUrl))
{
BufferedWebResponse response = renderPage(currentUrl,
requestCycle);
if (response != null)
{
response.writeTo((WebResponse)requestCycle.getResponse());
}
}
else if (shouldRedirectToTargetUrl(requestCycle, currentUrl,
targetUrl))
{
redirectTo(targetUrl, requestCycle);
// note: if we had session here we would render the page to
buffer and then
// redirect to URL generated *after* page has been rendered
(the statelessness
// may change during render). this would save one redirect
because now we have
// to render to URL generated *before* page is rendered,
render the page, get
// URL after render and if the URL is different (meaning page
is not stateless),
// save the buffer and redirect again (which is pretty much
what the next step
// does)
}
else
{
two of the 'if' statements next to an 'else' have been merged with this
one.
On 17/07/2014 16:26, Martin Grigorov wrote:
what is/was useless ?
now I am even more confused what your beautification did with this
really
important and fragile part of Wicket code :-)
I'm not saying that the new code is badly formatted. I was asking whether
beautification really means code formatting
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Jul 17, 2014 at 5:10 PM, Andrea Del Bene an.delb...@gmail.com
wrote:
Method respond had high level of if...else nesting, a couple of them
useless. in which way the new code doesn't respect Wicket's code format?
Maybe my IDE did something wrong.
Hi Andrea,
On Wed, Jul 16, 2014 at 8:33 PM, adelb...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/master c24d830cd - bb9c1044e
Code beautifying: method WebPageRenderer.respond
What exactly beautifying means ?
It is a bit hard to see what is the actual change. It doesn't look like
applying Wicket's code format.
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/bb9c1044
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/bb9c1044
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/bb9c1044
Branch: refs/heads/master
Commit: bb9c1044e5f1ba8902aa69073ef9fb236802d277
Parents: c24d830
Author: andrea del bene adelb...@apache.org
Re: git commit: Code beautifying: method WebPageRenderer.respond
You spotted me :)! I could also use pmd rules to make it clear from the
start:
http://pmd.sourceforge.net/pmd-4.3/rules/design.html#AvoidDeeplyNestedIfStmts
You just removed two pairs of curly braces (to turn 'else { if {} }'
into 'else if {}') and re-indented the code?
“The truth is rarely pure and never simple.” ― Oscar Wilde
On Thu, Jul 17, 2014 at 11:53 AM, Andrea Del Bene an.delb...@gmail.com wrote:
I admit I've changed a very sensible part of the code :), however after
working with it I realized that we could reduce its complexity removing a
couple of nesting levels merging them in the outer if...else block. I
think this improve code quality and its readability. Let me explain you what
I did. The code was:
if (bufferedResponse != null)
{
logger
.warn(The Buffered response should be handled by
BufferedResponseRequestHandler);
// if there is saved response for this URL render it
bufferedResponse.writeTo((WebResponse)requestCycle.getResponse());
}
else
{
if (shouldRenderPageAndWriteResponse(requestCycle, currentUrl,
targetUrl)) //
{
BufferedWebResponse response = renderPage(currentUrl,
requestCycle);
if (response != null)
{
response.writeTo((WebResponse)requestCycle.getResponse());
}
}
else
{
if (shouldRedirectToTargetUrl(requestCycle, currentUrl,
targetUrl))
{
redirectTo(targetUrl, requestCycle);
// note: if we had session here we would render the page
to buffer and then
// redirect to URL generated *after* page has been
rendered (the statelessness
// may change during render). this would save one
redirect because now we have
// to render to URL generated *before* page is rendered,
render the page, get
// URL after render and if the URL is different (meaning
page is not stateless),
// save the buffer and redirect again (which is pretty
much what the next step
// does)
}
else
..etc.
now is
if (bufferedResponse != null)
{
logger
.warn(The Buffered response should be handled by
BufferedResponseRequestHandler);
// if there is saved response for this URL render it
bufferedResponse.writeTo((WebResponse)requestCycle.getResponse());
}
else if (shouldRenderPageAndWriteResponse(requestCycle, currentUrl,
targetUrl))
{
BufferedWebResponse response = renderPage(currentUrl,
requestCycle);
if (response != null)
{
response.writeTo((WebResponse)requestCycle.getResponse());
}
}
else if (shouldRedirectToTargetUrl(requestCycle, currentUrl,
targetUrl))
{
redirectTo(targetUrl, requestCycle);
// note: if we had session here we would render the page to
buffer and then
// redirect to URL generated *after* page has been rendered (the
statelessness
// may change during render). this would save one redirect
because now we have
// to render to URL generated *before* page is rendered, render
the page, get
// URL after render and if the URL is different (meaning page is
not stateless),
// save the buffer and redirect again (which is pretty much what
the next step
// does)
}
else
{
two of the 'if' statements next to an 'else' have been merged with this one.
On 17/07/2014 16:26, Martin Grigorov wrote:
what is/was useless ?
now I am even more confused what your beautification did with this
really
important and fragile part of Wicket code :-)
I'm not saying that the new code is badly formatted. I was asking whether
beautification really means code formatting
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Jul 17, 2014 at 5:10 PM, Andrea Del Bene an.delb...@gmail.com
wrote:
Method respond had high level of if...else nesting, a couple of them
useless. in which way the new code doesn't respect Wicket's code format?
Maybe my IDE did something wrong.
Hi Andrea,
On Wed, Jul 16, 2014 at 8:33 PM, adelb...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/master c24d830cd - bb9c1044e
Code beautifying: method WebPageRenderer.respond
What exactly beautifying means ?
It is a bit hard to see what is the actual change. It doesn't look like
applying Wicket's code format.
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/bb9c1044
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/bb9c1044
Diff:
Re: proposal: behavior bundles
On Thu, Jul 17, 2014 at 9:08 AM, Garret Wilson gar...@globalmentor.com wrote: On 7/17/2014 8:25 AM, Martin Grigorov wrote: ... For some reason this feature doesn't seem that usable to me... Could you be more specific about why you don't find this feature doesn't seem useful? None of your comments below were about the feature itself---they were about ancillary implementation details, such as whether the assert keyword should be used. This feature proposal is based upon the following assumptions: * Many developers will want to use the Wicket framework with third-party frameworks that require certain attributes and/or CSS classes in certain circumstances. * Adding third-party library support shouldn't require subclasses a lot of components. (Otherwise, I'd have a PureCSSButton, and I'd have to instantiate PureCSSButtons throughout the code... until I changed frameworks, at which point I'd have to change them all to BootStrapButtons.) * Third-party library support should be isolated from main UI code and from business logic. That is, I shouldn't have have to go add PureCSSAttributeBehaviors to all my buttons throughout the code, intermingled with my CSS framework-agnostic code. If one of those assumptions are invalid, let me know. Otherwise, do you have an alternative approach for me to easily add Pure CSS support for all my buttons (for example) in one locations without going through all my UI code, and then tomorrow to switch to using the Bootstrap framework (with its different required attributes for buttons and such) without changing all my code? If there is an alternative, great. But I don't see how you can say there is no need for such a feature. there is no need for the wrapper you provide. everything you want is already possible using IComponentInstantiationListener - which you already use. there are a few issues with the convenience wrapper: * you are forcing developers to share the behavior instance across multiple components this may be undesirable in some cases and inconvenient because it forces the behavior design to be stateless or store data using metadata instead of fields. while ok for simple things like appending a class it makes developing more complex behaviors difficult. * the mapping is not flexible enough suppose you want a link that opts out of this behavior for whatever reason. maybe you do it by implementing some interface on the link. now all methods in the behavior have to check for this interface. much easier to check for the interface and just not add the behavior. * the wrapper doesnt provide any real value its just a convenience and one that doesnt work for the 90% case. how many lines of code does it save? not many. we dont add such wrappers because they blow up the api surface area. -igor Garret
ApacheCon EU 2014: (at least) 3 wicket presentations
All, I was just notified that my 3 proposals for presentations about Wicket were accepted. Apparently I have some work to do... My proposals are below. Hope to see you there! Martijn Apache Wicket: 10 years and beyond With the Tenth Anniversary of Wicket behind us, Wicket is still one of the thriving survivors of the Great Web Framework Wars of the mid 00's. Is there a future for server-side frameworks? In this presentation Martijn Dashorst provides a brief history of Wicket. With a State of the Wicket, Martijn will look at who is currently using Wicket, the community and current release plans. The majority of this session will be dedicated to the future of Wicket: does a component oriented, Java web framework have a future in the era of native clients and client side JavaScript frameworks? Martijn will layout the plans of making Wicket more productive for current users, on integrating better with JavaEE technologies and much more. Wicket and Java EE sitting in a tree Apache Wicket strives to enable developers to be very productive and craft maintainable web applications. Java EE also enables developers to achieve high productivity. So what happens when you combine both technologies? In this session Martijn Dashorst shows how to leverage the available Java EE technologies such as CDI, JPA, Bean Validation and JAX-RS in your Wicket applications. Wicket Puzzlers Apache Wicket is a web framework that enables you to write maintainable web applications. However there are a lot of different ways in which you can shoot yourself in your own foot, or write code that seems it should work but doesn't, or has odd side effects. In this presentation, Martijn Dashorst will present several puzzlers in the same format as the acclaimed Java Puzzlers presentation. He will present the case, offer several choices and then present the correct answer. -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: ApacheCon EU 2014: (at least) 3 wicket presentations
Sweet! I hope you share your slides (and maybe even recorded video?) with the world! On Thu, Jul 17, 2014 at 4:53 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: All, I was just notified that my 3 proposals for presentations about Wicket were accepted. Apparently I have some work to do... My proposals are below. Hope to see you there! Martijn Apache Wicket: 10 years and beyond With the Tenth Anniversary of Wicket behind us, Wicket is still one of the thriving survivors of the Great Web Framework Wars of the mid 00's. Is there a future for server-side frameworks? In this presentation Martijn Dashorst provides a brief history of Wicket. With a State of the Wicket, Martijn will look at who is currently using Wicket, the community and current release plans. The majority of this session will be dedicated to the future of Wicket: does a component oriented, Java web framework have a future in the era of native clients and client side JavaScript frameworks? Martijn will layout the plans of making Wicket more productive for current users, on integrating better with JavaEE technologies and much more. Wicket and Java EE sitting in a tree Apache Wicket strives to enable developers to be very productive and craft maintainable web applications. Java EE also enables developers to achieve high productivity. So what happens when you combine both technologies? In this session Martijn Dashorst shows how to leverage the available Java EE technologies such as CDI, JPA, Bean Validation and JAX-RS in your Wicket applications. Wicket Puzzlers Apache Wicket is a web framework that enables you to write maintainable web applications. However there are a lot of different ways in which you can shoot yourself in your own foot, or write code that seems it should work but doesn't, or has odd side effects. In this presentation, Martijn Dashorst will present several puzzlers in the same format as the acclaimed Java Puzzlers presentation. He will present the case, offer several choices and then present the correct answer. -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Jeremy Thomerson http://wickettraining.com
Re: proposal: behavior bundles
On 17 July 2014 17:43, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Thu, Jul 17, 2014 at 9:08 AM, Garret Wilson gar...@globalmentor.com wrote: On 7/17/2014 8:25 AM, Martin Grigorov wrote: ... For some reason this feature doesn't seem that usable to me... Could you be more specific about why you don't find this feature doesn't seem useful? None of your comments below were about the feature itself---they were about ancillary implementation details, such as whether the assert keyword should be used. This feature proposal is based upon the following assumptions: * Many developers will want to use the Wicket framework with third-party frameworks that require certain attributes and/or CSS classes in certain circumstances. * Adding third-party library support shouldn't require subclasses a lot of components. (Otherwise, I'd have a PureCSSButton, and I'd have to instantiate PureCSSButtons throughout the code... until I changed frameworks, at which point I'd have to change them all to BootStrapButtons.) * Third-party library support should be isolated from main UI code and from business logic. That is, I shouldn't have have to go add PureCSSAttributeBehaviors to all my buttons throughout the code, intermingled with my CSS framework-agnostic code. If one of those assumptions are invalid, let me know. Otherwise, do you have an alternative approach for me to easily add Pure CSS support for all my buttons (for example) in one locations without going through all my UI code, and then tomorrow to switch to using the Bootstrap framework (with its different required attributes for buttons and such) without changing all my code? If there is an alternative, great. But I don't see how you can say there is no need for such a feature. there is no need for the wrapper you provide. everything you want is already possible using IComponentInstantiationListener - which you already use. there are a few issues with the convenience wrapper: * you are forcing developers to share the behavior instance across multiple components this may be undesirable in some cases and inconvenient because it forces the behavior design to be stateless or store data using metadata instead of fields. while ok for simple things like appending a class it makes developing more complex behaviors difficult. * the mapping is not flexible enough suppose you want a link that opts out of this behavior for whatever reason. maybe you do it by implementing some interface on the link. now all methods in the behavior have to check for this interface. much easier to check for the interface and just not add the behavior. * the wrapper doesnt provide any real value its just a convenience and one that doesnt work for the 90% case. how many lines of code does it save? not many. we dont add such wrappers because they blow up the api surface area. -igor Garret From a user who lurks on the dev list, I feel it's worth adding my 0.02 BTC. (or is this where I reveal I've been using Wicket all wrong *-) I view raw markup input type=? ... the same way as I view (from another recent dev post) hard coded string constants assert t.getName().equalsIgnoreCase(a); They are both typed as far as the compiler is concerned. But to an application they are untyped. Is the:- * string: really a user name, email, url, password, part reference, supplier name... * number: really a sale price, height, duration, stock quantity ... In my application I've abstracted (almost)all fields, away from raw inputs and instead use a meaningful class to handle a specific input type. For example I use stock quantity fields in many places. A (simple view of) stock quantity consists of a numeric amount and some unit of measure. [ 50] Kg [230] Each All the user of such a field has to supply is code someForm.add(new StockQtyField(id, model, )) markup wicket:container wicket:id=saleQty/ along with the appropriate model for the value in question. This is repeated for currency amounts, business specific reference fields, common drop downs and various string fields etc. It means that if I need to change from say Bootstrap to 'latest trendy css framework' I reimplement the ~40 or so field classes (and markup), and the thousands of places which use them are automatically correct. Of course each of the business input fields is free to use fancy behaviours to wrap input fields. TL;DR So back to the topic of this thread. From my POV, I see little use in being able to bundle behaviour with an untyped input field in order to make some css framework happy. -- Peter Henderson
