core devs cannot close PRs on github?

2015-03-12 Thread Thibault Kruse
Hi,

I notice that the core devs have to ask PR submitters to close their
PRs on github:
https://github.com/apache/wicket/pull/101

I am curious: Why is that so?

Looking here:
https://help.github.com/articles/permission-levels-for-an-organization-repository/

I assume the wicket core devs are only part of a read access team,
not a write access team within the github apache organisation. But
why would Apache do it like that, given teams can be granted
permissions on a per-repository basis?


regards,
  Thibault

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Plans for further wicket classes with generics

2015-02-02 Thread Thibault Kruse
Hi,

Already in Wicket there is GenericPanel, GenericWebPage,
GenericFragment, IGenericComponent, and IModel of course is already
generic.

But there is still IBehavior without Generics and several standard
components which do not implement IGenericComponent such a Label.

Are there plans to further promote APIs with generics, also maybe
deprecating the APIs which do not use generics (classes Panel, Page,
etc.)?

Or is there a good reason not to use Generics?

regards,
  Thibault

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Plans for further wicket classes with generics

2015-02-02 Thread Thibault Kruse
I see, I guess this was summarized here:
https://cwiki.apache.org/confluence/display/WICKET/generics


On Mon, Feb 2, 2015 at 2:27 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi,

 There is a discussion about this since Wicket 1.4 (the first version of
 Wicket built against JDK 1.5).
 The main stopper is that using generics makes the code even more verbose.
 And many people don't like this.
 So there are few Generic*** versions of the most used components.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Mon, Feb 2, 2015 at 3:21 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Hi,

 Already in Wicket there is GenericPanel, GenericWebPage,
 GenericFragment, IGenericComponent, and IModel of course is already
 generic.

 But there is still IBehavior without Generics and several standard
 components which do not implement IGenericComponent such a Label.

 Are there plans to further promote APIs with generics, also maybe
 deprecating the APIs which do not use generics (classes Panel, Page,
 etc.)?

 Or is there a good reason not to use Generics?

 regards,
   Thibault

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Component error handler

2014-11-18 Thread Thibault Kruse
Hi,

we have a page with several components (after logging in, the user
sees a dashboard page with panels offering information from diverse
sources).
We would like to achieve that if one of the component fails to render,
this does not take down the whole page.
So the failing component should handle exceptions locally(render an
error message), allowing the other components to render normally.

I see this was asked on StackOverflow here:
http://stackoverflow.com/questions/12456302/how-to-handle-exceptions-thrown-in-wicket-custom-model

I wonder whether there is by now a better way than in those answers.

regards,
  Thibault

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: respond with 404 page while keeping original URL

2014-09-26 Thread Thibault Kruse
As a follow-up: How can the Http Error code then be checked using WicketTester?
Currently, after your suggested change, the browser shows my 404 page
and status is 404, but in WicketTester, I get

In MyPage.java:

@Override
protected void onInitialize() {
super.onInitialize();
throw new
AbortWithHttpErrorCodeException(HttpServletResponse.SC_NOT_FOUND);
}

In Test:

TESTER_SCOPE.getTester().startPage(MyPage.class);

assertThat(TESTER_SCOPE.getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);

org.junit.ComparisonFailure:
Expected :404
Actual   :200

The Exception is thrown by the Page class in the test (as I see in the
debugger).

On Wed, Sep 10, 2014 at 3:09 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Just throw AbortWithHttpErrorCodeException.
 The url will remain the same.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Wed, Sep 10, 2014 at 3:43 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Hi,

 we have a page for some resource mounted at /resource/id
 When users enter an invalid ID, we want to render a 404 page.
 However, we would like the resulting page not have the original url
 with the invalid id (but http status 404).

 Is there any obvious easy way to achieve this? Because it seems the
 general way in wicket tutorials on 404 pages seem to rely on
 redirecting to a mounted 404 resource, which means the browser will
 not display the original invalid URL.

 cheers,
   Thibault

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: respond with 404 page while keeping original URL

2014-09-26 Thread Thibault Kruse
Hm, so the Error Page itself is does not render during the test
(debugger does not enter constructor at all).

My Error Page has:
   @Override
protected void configureResponse(WebResponse response) {
super.configureResponse(response);
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
}

When the exception is thrown, the thread returns to
RequestCycle.HandlerExecutor.execute(), then runs into the catch
clause of RequestHandlerStack.execute(), upcasting the
AborthWithHttpStatusException to a ReplaceHandlerException, yielding
an ErrorCodeRequestHandler for 404. Then this replacementHandler is
executed using RequestCycle.respond(), ending up in:
ErrorCodeRequestHandler.respond(final IRequestCycle requestCycle) {
WebResponse webResponse = (WebResponse)requestCycle.getResponse();
webResponse.sendError(errorCode, message);
}

This comes to MockHttpServletResponse.sendError, where status is set to 404.

Then the thread continues with WicketTester.setupNextRequestCycle(),
creating a new MockHttpServletResponse() with status 200, but then
does not render any page at all.
This assert passes:
assertThat(TESTER_SCOPE.getTester().getLastRenderedPage()).isNull();

So I guess I can do a
assertThat(TESTER_SCOPE.
getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);

Not sure whether that's ideal, but it's not too bad.

On Fri, Sep 26, 2014 at 1:32 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi,

 I think it is 200 because this is the status code of the error page - it is
 rendered successfully.
 You
 need org.apache.wicket.util.tester.BaseWicketTester#setFollowRedirects(false)
 if you want to assert the response for MyPage.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Fri, Sep 26, 2014 at 1:29 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 As a follow-up: How can the Http Error code then be checked using
 WicketTester?
 Currently, after your suggested change, the browser shows my 404 page
 and status is 404, but in WicketTester, I get

 In MyPage.java:

 @Override
 protected void onInitialize() {
 super.onInitialize();
 throw new
 AbortWithHttpErrorCodeException(HttpServletResponse.SC_NOT_FOUND);
 }

 In Test:

 TESTER_SCOPE.getTester().startPage(MyPage.class);

 assertThat(TESTER_SCOPE.getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);

 org.junit.ComparisonFailure:
 Expected :404
 Actual   :200

 The Exception is thrown by the Page class in the test (as I see in the
 debugger).

 On Wed, Sep 10, 2014 at 3:09 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Just throw AbortWithHttpErrorCodeException.
  The url will remain the same.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Wed, Sep 10, 2014 at 3:43 PM, Thibault Kruse 
 tibokr...@googlemail.com
  wrote:
 
  Hi,
 
  we have a page for some resource mounted at /resource/id
  When users enter an invalid ID, we want to render a 404 page.
  However, we would like the resulting page not have the original url
  with the invalid id (but http status 404).
 
  Is there any obvious easy way to achieve this? Because it seems the
  general way in wicket tutorials on 404 pages seem to rely on
  redirecting to a mounted 404 resource, which means the browser will
  not display the original invalid URL.
 
  cheers,
Thibault
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: respond with 404 page while keeping original URL

2014-09-26 Thread Thibault Kruse
Sorry I just realized I pasted something wrong in my last message. My
current workaround would be:

assertThat(TESTER_SCOPE.getTester().getPreviousResponses().get(0).getStatus())
.isEqualTo(HttpServletResponse.SC_NOT_FOUND);

But that is a bit annoying for us when we reuse a tester a bit,
because wicketTester.getPreviousResponses().get(0) returns the oldest,
but we need the most recent one, so something like
testert.getPreviousResponses().get(testert.getPreviousResponses().size()
-1).getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);

which is unwieldy. Or alternatively invoking
TESTER_SCOPE.getTester().getPreviousResponses().clear();
before a new rendering attempt. I will probably go for that in those places.

On Fri, Sep 26, 2014 at 1:57 PM, Martin Grigorov mgrigo...@apache.org wrote:
 OK. Right.
 ErrorCodeRequestHandler returns a response with code 404 and then the web
 container uses the definition in web.xml to get the url for 404 ...
 There is no web.xml with WicketTester and thus no redirect to /404.html.
 Your code is good!

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Fri, Sep 26, 2014 at 1:53 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Hm, so the Error Page itself is does not render during the test
 (debugger does not enter constructor at all).

 My Error Page has:
@Override
 protected void configureResponse(WebResponse response) {
 super.configureResponse(response);
 response.setStatus(HttpServletResponse.SC_NOT_FOUND);
 }

 When the exception is thrown, the thread returns to
 RequestCycle.HandlerExecutor.execute(), then runs into the catch
 clause of RequestHandlerStack.execute(), upcasting the
 AborthWithHttpStatusException to a ReplaceHandlerException, yielding
 an ErrorCodeRequestHandler for 404. Then this replacementHandler is
 executed using RequestCycle.respond(), ending up in:
 ErrorCodeRequestHandler.respond(final IRequestCycle requestCycle) {
 WebResponse webResponse = (WebResponse)requestCycle.getResponse();
 webResponse.sendError(errorCode, message);
 }

 This comes to MockHttpServletResponse.sendError, where status is set to
 404.

 Then the thread continues with WicketTester.setupNextRequestCycle(),
 creating a new MockHttpServletResponse() with status 200, but then
 does not render any page at all.
 This assert passes:
 assertThat(TESTER_SCOPE.getTester().getLastRenderedPage()).isNull();

 So I guess I can do a
 assertThat(TESTER_SCOPE.

 getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);

 Not sure whether that's ideal, but it's not too bad.

 On Fri, Sep 26, 2014 at 1:32 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  I think it is 200 because this is the status code of the error page - it
 is
  rendered successfully.
  You
  need
 org.apache.wicket.util.tester.BaseWicketTester#setFollowRedirects(false)
  if you want to assert the response for MyPage.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Fri, Sep 26, 2014 at 1:29 PM, Thibault Kruse 
 tibokr...@googlemail.com
  wrote:
 
  As a follow-up: How can the Http Error code then be checked using
  WicketTester?
  Currently, after your suggested change, the browser shows my 404 page
  and status is 404, but in WicketTester, I get
 
  In MyPage.java:
 
  @Override
  protected void onInitialize() {
  super.onInitialize();
  throw new
  AbortWithHttpErrorCodeException(HttpServletResponse.SC_NOT_FOUND);
  }
 
  In Test:
 
  TESTER_SCOPE.getTester().startPage(MyPage.class);
 
 
 assertThat(TESTER_SCOPE.getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);
 
  org.junit.ComparisonFailure:
  Expected :404
  Actual   :200
 
  The Exception is thrown by the Page class in the test (as I see in the
  debugger).
 
  On Wed, Sep 10, 2014 at 3:09 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
   Just throw AbortWithHttpErrorCodeException.
   The url will remain the same.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Wed, Sep 10, 2014 at 3:43 PM, Thibault Kruse 
  tibokr...@googlemail.com
   wrote:
  
   Hi,
  
   we have a page for some resource mounted at /resource/id
   When users enter an invalid ID, we want to render a 404 page.
   However, we would like the resulting page not have the original url
   with the invalid id (but http status 404).
  
   Is there any obvious easy way to achieve this? Because it seems the
   general way in wicket tutorials on 404 pages seem to rely on
   redirecting to a mounted 404 resource, which means the browser will
   not display the original invalid URL.
  
   cheers,
 Thibault
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h

Re: respond with 404 page while keeping original URL

2014-09-26 Thread Thibault Kruse
duh, sorry, could have seen that myself.

It is still a bit confusing that the WicketTester ends up in a state
with a new request and response which are undefined. Somehow I think
if the web.xml for testing did not define a response for 404, there
should not be any new request. But that's not bad enough to make a
change to wicket breaking existing test code, I guess.

On Fri, Sep 26, 2014 at 2:07 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Use getLastResponse().

 getRequest() and getResponse() return the ones which will be used for the
 next interaction.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Fri, Sep 26, 2014 at 2:04 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Sorry I just realized I pasted something wrong in my last message. My
 current workaround would be:


 assertThat(TESTER_SCOPE.getTester().getPreviousResponses().get(0).getStatus())
 .isEqualTo(HttpServletResponse.SC_NOT_FOUND);

 But that is a bit annoying for us when we reuse a tester a bit,
 because wicketTester.getPreviousResponses().get(0) returns the oldest,
 but we need the most recent one, so something like
 testert.getPreviousResponses().get(testert.getPreviousResponses().size()
 -1).getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);

 which is unwieldy. Or alternatively invoking
 TESTER_SCOPE.getTester().getPreviousResponses().clear();
 before a new rendering attempt. I will probably go for that in those
 places.

 On Fri, Sep 26, 2014 at 1:57 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  OK. Right.
  ErrorCodeRequestHandler returns a response with code 404 and then the web
  container uses the definition in web.xml to get the url for 404 ...
  There is no web.xml with WicketTester and thus no redirect to /404.html.
  Your code is good!
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Fri, Sep 26, 2014 at 1:53 PM, Thibault Kruse 
 tibokr...@googlemail.com
  wrote:
 
  Hm, so the Error Page itself is does not render during the test
  (debugger does not enter constructor at all).
 
  My Error Page has:
 @Override
  protected void configureResponse(WebResponse response) {
  super.configureResponse(response);
  response.setStatus(HttpServletResponse.SC_NOT_FOUND);
  }
 
  When the exception is thrown, the thread returns to
  RequestCycle.HandlerExecutor.execute(), then runs into the catch
  clause of RequestHandlerStack.execute(), upcasting the
  AborthWithHttpStatusException to a ReplaceHandlerException, yielding
  an ErrorCodeRequestHandler for 404. Then this replacementHandler is
  executed using RequestCycle.respond(), ending up in:
  ErrorCodeRequestHandler.respond(final IRequestCycle requestCycle) {
  WebResponse webResponse =
 (WebResponse)requestCycle.getResponse();
  webResponse.sendError(errorCode, message);
  }
 
  This comes to MockHttpServletResponse.sendError, where status is set to
  404.
 
  Then the thread continues with WicketTester.setupNextRequestCycle(),
  creating a new MockHttpServletResponse() with status 200, but then
  does not render any page at all.
  This assert passes:
  assertThat(TESTER_SCOPE.getTester().getLastRenderedPage()).isNull();
 
  So I guess I can do a
  assertThat(TESTER_SCOPE.
 
 
 getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);
 
  Not sure whether that's ideal, but it's not too bad.
 
  On Fri, Sep 26, 2014 at 1:32 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
   Hi,
  
   I think it is 200 because this is the status code of the error page -
 it
  is
   rendered successfully.
   You
   need
  org.apache.wicket.util.tester.BaseWicketTester#setFollowRedirects(false)
   if you want to assert the response for MyPage.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Fri, Sep 26, 2014 at 1:29 PM, Thibault Kruse 
  tibokr...@googlemail.com
   wrote:
  
   As a follow-up: How can the Http Error code then be checked using
   WicketTester?
   Currently, after your suggested change, the browser shows my 404 page
   and status is 404, but in WicketTester, I get
  
   In MyPage.java:
  
   @Override
   protected void onInitialize() {
   super.onInitialize();
   throw new
   AbortWithHttpErrorCodeException(HttpServletResponse.SC_NOT_FOUND);
   }
  
   In Test:
  
   TESTER_SCOPE.getTester().startPage(MyPage.class);
  
  
 
 assertThat(TESTER_SCOPE.getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);
  
   org.junit.ComparisonFailure:
   Expected :404
   Actual   :200
  
   The Exception is thrown by the Page class in the test (as I see in
 the
   debugger).
  
   On Wed, Sep 10, 2014 at 3:09 PM, Martin Grigorov 
 mgrigo...@apache.org
   wrote:
Just throw AbortWithHttpErrorCodeException.
The url will remain the same.
   
Martin Grigorov
Wicket Training

Re: turning off page versioning

2014-09-24 Thread Thibault Kruse
On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson gar...@globalmentor.com wrote:
 I'm not denying that versioned pages may be a useful concept for some use
 cases (even though I can't think of any offhand). I'm just saying it's not
 my use case, and I had assumed throughout development on our project that I
 could just turn it off by calling setVersioned(false).

Maybe that is the biggest problem with page versioning in a wicket
project. As a symptom it is annoying to understand and circumvent, and
it seems like just a minor configuration thing, so projects advance
leaving the undesired page version as something to be fixed later
using the full set of features and component relying on page
versioning. Then much later in the project, they find out that it's
not easy to get rid of page versioning without paying a hefty price.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: turning off page versioning

2014-09-24 Thread Thibault Kruse
No, I believe what Wicket currently does is okay, but in web projects
with wicket, when page versioning is a problem (e.g. because of the
number apearing in the url, or any other issue with it), then it is
commonly dealt with much too late.

Too late means that application pages will already be filled with
components and navigation logic that require page versioning, so that
there cannot be an easy off-switch for page versioning that does not
also break functionality. Replacing the mechanisms then one by one
means an unnecessary additional development effort compared to having
considered what pages should not be versioned from the start.

I have not enough insight to have an opinion about what wicket could
do to help with situations where projects have gone on for some time
without care for page versioning, and at that point the requirement to
not have page numbers (and not needs prior versions of pages) becomes
relevant.


On Wed, Sep 24, 2014 at 11:34 AM, Martin Grigorov mgrigo...@apache.org wrote:
 Thibault,

 On Wed, Sep 24, 2014 at 11:23 AM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson gar...@globalmentor.com
 wrote:
  I'm not denying that versioned pages may be a useful concept for some use
  cases (even though I can't think of any offhand). I'm just saying it's
 not
  my use case, and I had assumed throughout development on our project
 that I
  could just turn it off by calling setVersioned(false).

 Maybe that is the biggest problem with page versioning in a wicket
 project. As a symptom it is annoying to understand and circumvent, and
 it seems like just a minor configuration thing, so projects advance
 leaving the undesired page version as something to be fixed later
 using the full set of features and component relying on page
 versioning. Then much later in the project, they find out that it's
 not easy to get rid of page versioning without paying a hefty price.


 Do you say that Wicket should store only one page instance per user session
 ? (As Garret's usecase)
 Or that it should not create separate versions for interactions like link
 click ? (PageSettings#setVersionPagesByDefault(false))
 Or just that the ?pageId in the url is something that should be possible to
 be removed if the application developer says it is OK ?



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: turning off page versioning

2014-09-24 Thread Thibault Kruse
You could generally tune down on telling the world about your
emotional state on technical mailing lists, your emotional state is of
no significant interest to the people who registered to this mailing
list, at least no in the amount you provide. We got it the first time.

And e.g. your phrasing Yeah, I definitely want to turn that off.
seems to imply that you'd be stupid not to turn that off, which seems
to imply anyone who does not turn it off is stupid. This is just one
example.

Your usage of exclamation marks, exaggerations and repetitions can
also be perceived as condescending, because it implies the audience is
unable to see the truth as you do, unless you shout or emphasize it
for the audience.

So avoiding sarcasm and needless emphasis can help prevent
misunderstandings, and helps everybody to focus on the technical issue
at hand.



On Wed, Sep 24, 2014 at 4:49 PM, Garret Wilson gar...@globalmentor.com wrote:
 On 9/24/2014 11:18 AM, Martijn Dashorst wrote:

 ...
 And ranting about how stupid we are for having page versions doesn't
 help either.


 Hey, wait a minute. Where did that come from? That sort of hurts my
 feelings. I brought up this topic, and I've said throughout this discussion
 that versioning may have its use cases, but it's just not what I need at the
 moment, and I simply asked for a way to turn it off.

 That was sort of a cheap shot as we say, Martijn. I never said anyone was
 stupid. I asked a simple, honest developer question about how to turn off a
 feature. I was very disappointed to learn that it couldn't be turned off.
 But I tried to make clear I wasn't angry at anyone specifically nor was I
 questioning anybody's competence.

 I think that comment was totally unfair.

 Garret


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: turning off page versioning

2014-09-23 Thread Thibault Kruse
It is an interesting question whether other web frameworks (also
outside JVM world) use any similar page versioning scheme to wicket. I
am not aware of any.

In any case I guess most projects using wicket would have to make
design decisions based on whether the page version is acceptable in
the URL or not. There is no simple way of reasonably switching it
off once an application has been created without giving this some
thought.

I don't think every web-framework should strive to be the best choice
for facebook or similar, different frameworks may have different
strengths and weaknesses (performance, memory-consumption,
learning-curve, maintenance-costs, prototyping-speed, etc.)


On Tue, Sep 23, 2014 at 3:44 PM, Garret Wilson gar...@globalmentor.com wrote:
 OMG. What a sad email to wake up to. :(

 Let me let all that digest for a while. I never would have imagined a
 situation this dire. Imagine if every time you went to Facebook, it
 generated a new https://www.facebook.com/jdoe?124154451 version! So
 basically Facebook could never use Wicket without rewriting the whole page
 caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't
 even think of a single site that functions like Wicket, incrementing some
 page version counter every time you interact with the page, so that you
 can go back to other versions. (Users don't want to go back to other
 versions! They may want to go back to other /pages/ at different URLs, but
 they realize that interacting with a single pages changes the state of that
 page---they don't expect that other versions are kept around somewhere.)

 Continuing my scenario I outlined earlier, I have an HTML page called
 MenuPage, which has wicket:linka href=StagingPage.html..., the target
 page of which functions as I explained below. Every time the user goes to
 the MenuPage and clicks on the link, you're saying that Wicket will generate
 a new version of StagingPage in the cache, even with setVersioned(false)? It
 will generate a new ...StagingPage.html?23423414 URL? There is no way to
 turn that off... without essentially rewriting the whole Wicket page request
 and caching mechanism??

 This is not good news. I'm not ranting, I'm crying.

 Garret


 On 9/23/2014 8:24 AM, Martin Grigorov wrote:

 Hi,

 In short, to accomplish all this you will need several custom impls of
 Wicket interfaces.
 1) custom IRequestMapper that just ignores PageInfo when generating the
 url
 for IPageRequestHandler. Search in the archives for
 NoVersionRequestMapper
 2) a completely new IPageManager (interface!) that works with ClassPage
 instead of with Integer (pageId)
 So everytime a url is mapped to a page class you should use it to load the
 Page instance for this class

 In details:
 By design only stateless pages do not have the pageId in the url! If a
 request without pageId comes then a completely new page instance is
 created.
 By using something like NoVersionRequestMapper (not supported officially!)
 only the url for the browser address bar will miss the pageId (see
 PageAndComponentInfo class), but the pageId is in all link/form urls so
 clicking/submitting still works. But if the user refreshes the page (F5)
 then the state is lost!

 About Page#setVersioned(boolean)
 This tells Wicket to not increment the pageId after an interaction with
 the
 page. A pageId is associated with the page when it is instantiated, but
 any
 link click, form submit, etc. won't create a new version of the page. The
 final result is that every interaction (i.e. state change) with the page
 will lead to overriding the old one in the page stores.
 Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
 pageId, byte[] serializedPage). At the end of every request cycle all
 rendered stateful pages are stored. If the pageId doesn't change then some
 old serializedPage would be overriden.

 For your requirements you will need an API like: put(String sessionId,
 ClassPage pageClass, byte[] serializedPage) and byte [] get(String
 sessionId, ClassPage pageClass).
 You can create a IPageManager wrapper that maps sessionId+pageId to
 pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
 impls. (Just an idea out of my mind.)


 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson gar...@globalmentor.com
 wrote:

 Can someone explain to me exactly how page versioning works, and how to
 turn it off?

 I have a page StagingPage that contains a file uploader. This page is
 interesting in that when you upload some files with Button1, the page
 lists
 the files on the page and keeps them in a collection until you hit
 Button2,
 at which point the pages does Some Other Really Interesting Thing with
 the
 files. In other words, the page acts like a staging area for files,
 allowing you to 1) upload files and then 2) do something with them.

 I get this number on the end of the URLs which, from the page 

Re: MarkupContainer rendering without children

2014-09-19 Thread Thibault Kruse
bump, any opinion? Should I open a JIRA?

On Tue, Sep 16, 2014 at 4:02 PM, Thibault Kruse
tibokr...@googlemail.com wrote:
 Hi,

 is it intentional that if a class directly extends MarkupContainer,
 but does not have any children, then its associated markup is not
 rendered?

 When using

 public class FooMarkupContainer extends MarkupContainer implements
 IMarkupCacheKeyProvider {
 public FooMarkupContainer(String id) {super(id);}

 @Override public String getCacheKey(MarkupContainer container,
 Class? containerClass) {return null;}
 }

 with markup

 divFoo works!/div

 or anything, nothing appears on the page.

 It seems the javadoc of MarkupContainer is not entirely clear on this:
 http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/MarkupContainer.html

 Markup Rendering - A MarkupContainer also holds/references associated
 markup which is used to render the container. As the markup stream for
 a container is rendered, component references in the markup are
 resolved by using the container to look up Components in the
 container's component map by id. Each component referenced by the
 markup stream is given an opportunity to render itself using the
 markup stream. 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Programmatic Markup with fallback

2014-09-16 Thread Thibault Kruse
Regarding the markupException, the example I posted was flawed, must
be: return Markup.of(wicket:panelit works/wicket:panel);
But that is not relevant to my report. The example on github had this fixed.

Any other ideas / somewhat clean workaround? SHould I open a JIRA
issue on this, or two?

On Mon, Sep 15, 2014 at 8:01 PM, Thibault Kruse
tibokr...@googlemail.com wrote:
 Sorry, this was wicket 1.6.16 and 1.6.17.
 Here is a quickstart, to reproduce both cases some comments have to be 
 switched:
 https://github.com/tkruse/custommarkup

 On Mon, Sep 15, 2014 at 7:50 PM, Sven Meier s...@meiers.net wrote:
 Hi,

 which Wicket version?

 The first approach leads to a MarkupException here with Wicket 1.6.x.

 Regards
 Sven


 On 09/15/2014 07:37 PM, Thibault Kruse wrote:

 Hi,

 I am trying to create a wicket panel that renders markup from some
 remote source, but if fetching fails, renders some fallback markup. I
 want to achieve this with minimal code.

 I tried two approaches one based on overriding getMarkup(), one based
 on http://wicket.apache.org/guide/guide/advanced.html#advanced_5, both
 fail:

 /**
   * attempts to use custom markup by overriding getMarkup()... but html is
 used
   */
 public class CustomMarkupFallback1Panel extends GenericPanelString {
  @Override
  public IMarkupFragment getMarkup() {
  return Markup.of(it works);
  }
 }

 CustomMarkupFallback1Panel.html:
 wicket:panel
  Fail!
 /wicket:panel


 This first one overrides getMarkup() as suggested in the javadoc of
 IMarkupResourceStreamProvider, but what gets rendered is instead the
 static html (even though the debugger walks through getMarkup().


 The second approach fails using IMarkupResourceStreamProvider works
 for the intended markup, but not for the fallback markup
 public class CustomMarkupFallback2Panel extends GenericPanelString
  IMarkupResourceStreamProvider {

  @Override
  public IResourceStream getMarkupResourceStream(MarkupContainer
 container, Class? containerClass) {
  if (getModelObject() == null) {
  // thows Exception, see below. html file exists
  return getMarkup().getMarkupResourceStream();
  } else {
  // works
  return new StringResourceStream(getModelObject());
  }
  }
 }


 At least the first failure seems like a bug to me, not sure whether
 the second approach is supposed to work, or how else to load markup
 the wicket way.

 Is there maybe a completely different approach to achieve what I try to
 do?

 cheers,
Thibault



 java.io.IOException: Stream closed
   at
 java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:325)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
   at
 org.apache.wicket.util.io.BOMInputStream.getBOM(BOMInputStream.java:217)
   at
 org.apache.wicket.util.io.BOMInputStream.readFirstBytes(BOMInputStream.java:261)
   at
 org.apache.wicket.util.io.BOMInputStream.read(BOMInputStream.java:312)
   at
 org.apache.wicket.util.io.XmlReader.getXmlDeclaration(XmlReader.java:183)
   at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:106)
   at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:81)
   at
 org.apache.wicket.markup.parser.XmlPullParser.parse(XmlPullParser.java:605)
   at
 org.apache.wicket.markup.AbstractMarkupParser.parse(AbstractMarkupParser.java:178)
   at
 org.apache.wicket.markup.loader.SimpleMarkupLoader.loadMarkup(SimpleMarkupLoader.java:51)
   at
 org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:57)
   at
 org.apache.wicket.markup.loader.DefaultMarkupLoader.loadMarkup(DefaultMarkupLoader.java:52)
   at
 org.apache.wicket.markup.MarkupFactory.loadMarkup(MarkupFactory.java:412)
   at
 org.apache.wicket.markup.MarkupCache.loadMarkup(MarkupCache.java:448)
   at
 org.apache.wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(MarkupCache.java:544)
   at
 org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:305)
   at
 org.apache.wicket.markup.MarkupFactory.getMarkup(MarkupFactory.java:236)
   at
 org.apache.wicket.markup.MarkupFactory.getMarkup(MarkupFactory.java:194)
   at
 org.apache.wicket.MarkupContainer.getAssociatedMarkup(MarkupContainer.java:405)
   at
 org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContainer.java:372)
   at
 org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:244)
   at
 org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:220)
   at org.apache.wicket.Component.renderHead(Component.java:2652

Re: Programmatic Markup with fallback

2014-09-16 Thread Thibault Kruse
So debugging a bit, I find that I get hit by the
PanelMarkupSourcingStrategy. It seems it throws away the body markup
in favcor of the associated Markup. So I could advance one step by
extending WebMarkupContainer instead of Panel.

I notice that when extending Panel, getMarkup() is being called 3
times in my example, before the result is being discarded.

That seems like design smell. If users override getMarkup() with some
expensive operation, they should be able to rely on this being called
just once, and this only if the result is actually being used.

On Tue, Sep 16, 2014 at 11:24 AM, Thibault Kruse
tibokr...@googlemail.com wrote:
 Regarding the markupException, the example I posted was flawed, must
 be: return Markup.of(wicket:panelit works/wicket:panel);
 But that is not relevant to my report. The example on github had this fixed.

 Any other ideas / somewhat clean workaround? SHould I open a JIRA
 issue on this, or two?

 On Mon, Sep 15, 2014 at 8:01 PM, Thibault Kruse
 tibokr...@googlemail.com wrote:
 Sorry, this was wicket 1.6.16 and 1.6.17.
 Here is a quickstart, to reproduce both cases some comments have to be 
 switched:
 https://github.com/tkruse/custommarkup

 On Mon, Sep 15, 2014 at 7:50 PM, Sven Meier s...@meiers.net wrote:
 Hi,

 which Wicket version?

 The first approach leads to a MarkupException here with Wicket 1.6.x.

 Regards
 Sven


 On 09/15/2014 07:37 PM, Thibault Kruse wrote:

 Hi,

 I am trying to create a wicket panel that renders markup from some
 remote source, but if fetching fails, renders some fallback markup. I
 want to achieve this with minimal code.

 I tried two approaches one based on overriding getMarkup(), one based
 on http://wicket.apache.org/guide/guide/advanced.html#advanced_5, both
 fail:

 /**
   * attempts to use custom markup by overriding getMarkup()... but html is
 used
   */
 public class CustomMarkupFallback1Panel extends GenericPanelString {
  @Override
  public IMarkupFragment getMarkup() {
  return Markup.of(it works);
  }
 }

 CustomMarkupFallback1Panel.html:
 wicket:panel
  Fail!
 /wicket:panel


 This first one overrides getMarkup() as suggested in the javadoc of
 IMarkupResourceStreamProvider, but what gets rendered is instead the
 static html (even though the debugger walks through getMarkup().


 The second approach fails using IMarkupResourceStreamProvider works
 for the intended markup, but not for the fallback markup
 public class CustomMarkupFallback2Panel extends GenericPanelString
  IMarkupResourceStreamProvider {

  @Override
  public IResourceStream getMarkupResourceStream(MarkupContainer
 container, Class? containerClass) {
  if (getModelObject() == null) {
  // thows Exception, see below. html file exists
  return getMarkup().getMarkupResourceStream();
  } else {
  // works
  return new StringResourceStream(getModelObject());
  }
  }
 }


 At least the first failure seems like a bug to me, not sure whether
 the second approach is supposed to work, or how else to load markup
 the wicket way.

 Is there maybe a completely different approach to achieve what I try to
 do?

 cheers,
Thibault



 java.io.IOException: Stream closed
   at
 java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:325)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
   at
 org.apache.wicket.util.io.BOMInputStream.getBOM(BOMInputStream.java:217)
   at
 org.apache.wicket.util.io.BOMInputStream.readFirstBytes(BOMInputStream.java:261)
   at
 org.apache.wicket.util.io.BOMInputStream.read(BOMInputStream.java:312)
   at
 org.apache.wicket.util.io.XmlReader.getXmlDeclaration(XmlReader.java:183)
   at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:106)
   at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:81)
   at
 org.apache.wicket.markup.parser.XmlPullParser.parse(XmlPullParser.java:605)
   at
 org.apache.wicket.markup.AbstractMarkupParser.parse(AbstractMarkupParser.java:178)
   at
 org.apache.wicket.markup.loader.SimpleMarkupLoader.loadMarkup(SimpleMarkupLoader.java:51)
   at
 org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:57)
   at
 org.apache.wicket.markup.loader.DefaultMarkupLoader.loadMarkup(DefaultMarkupLoader.java:52)
   at
 org.apache.wicket.markup.MarkupFactory.loadMarkup(MarkupFactory.java:412)
   at
 org.apache.wicket.markup.MarkupCache.loadMarkup(MarkupCache.java:448)
   at
 org.apache.wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(MarkupCache.java:544)
   at
 org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:305)
   at
 org.apache.wicket.markup.MarkupFactory.getMarkup(MarkupFactory.java:236

Re: Programmatic Markup with fallback

2014-09-16 Thread Thibault Kruse
So, I have a working solution like this:

public class CustomMarkupFallbackMarkupContainer extends
WebMarkupContainer implements IMarkupCacheKeyProvider {
public CustomMarkupFallbackMarkupContainer(String id,
IModelString model) {super(id, model);}

@Override
public IMarkupFragment getMarkup() {
String markupString = (String) getDefaultModelObject();
if (markupString == null) {
return getAssociatedMarkup();
} else {
return Markup.of(markupString);
}
}

@Override public String getCacheKey(MarkupContainer container,
Class? containerClass) {return null;}
}

Regarding the multiple invocations of getMarkup(), they also occur
when caching, and indeed they occur on every request (caching happens
only for the associated markup, I assume). The calls all happen inside
the same call to Component.internalRender()

Invocations are:
1: Component.internalRender():2309 // creating a MarkupStream only
used inside if block

2:
Component.internalRenderComponent():2472 // some duplicate code with
internalRender()
MarkupContainer.onRender(): 1496
Component.internalRender():2344

3:
Component.renderComponentTag():3961
Component.internalRenderComponent():2505
MarkupContainer.onRender(): 1496
Component.internalRender():2344

4:
Component.renderComponentTag():3961
AssociatedMarkupSourcingStrategy.renderAssociatedMarkup()
AssociatedMarkupSourcingStrategy.renderAssociatedMarkup()
PanelMarkupSourcingStrategy.onComponentTagBody():112
Component.internalRenderComponent():2514
MarkupContainer.onRender(): 1496
Component.internalRender():2344



Regarding usage of onComponentTagBody(), that seems also valid, but
much deeper into the Wicket API than I would want to go, in particular
given there are recommended solutions in
http://wicket.apache.org/guide/guide/advanced.html#advanced_5 and the
javadoc.

On Tue, Sep 16, 2014 at 12:00 PM, Andrea Del Bene an.delb...@gmail.com wrote:
 Hi,

 I didn't dig to much into the code, but keep in mind that you are disabling
 markup caching in your example. This might explain why getMarkup is called
 three times.
 Anyway, in your specific case it might be better not to implement
 IMarkupCacheKeyProvider and IMarkupResourceStreamProvider, but simply
 override onComponentTagBody like this:

 @Override
 public void onComponentTagBody(MarkupStream markupStream, ComponentTag
 openTag) {
 if (getDefaultModelObject() == null) {
 super.onComponentTagBody(markupStream, openTag);
 }
 else {

 replaceComponentTagBody(markupStream, openTag, wicket:panelit
 works/wicket:panel);
 }
 }

 So debugging a bit, I find that I get hit by the
 PanelMarkupSourcingStrategy. It seems it throws away the body markup
 in favcor of the associated Markup. So I could advance one step by
 extending WebMarkupContainer instead of Panel.

 I notice that when extending Panel, getMarkup() is being called 3
 times in my example, before the result is being discarded.

 That seems like design smell. If users override getMarkup() with some
 expensive operation, they should be able to rely on this being called
 just once, and this only if the result is actually being used.

 On Tue, Sep 16, 2014 at 11:24 AM, Thibault Kruse
 tibokr...@googlemail.com wrote:



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Programmatic Markup with fallback

2014-09-16 Thread Thibault Kruse
I forgot to mention, for my solution to work, the associated markup
file must not have tags outside the wicket:panel tags:
wicket:panel
Fallback works!
/wicket:panel

as opposed to

?xml version=1.0 encoding=UTF-8?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:wicket=http://wicket.apache.org;
body
wicket:panel
Fallback works!
/wicket:panel
/body
/html

So I guess I am still doing something wrong here.

On Tue, Sep 16, 2014 at 12:28 PM, Thibault Kruse
tibokr...@googlemail.com wrote:
 So, I have a working solution like this:

 public class CustomMarkupFallbackMarkupContainer extends
 WebMarkupContainer implements IMarkupCacheKeyProvider {
 public CustomMarkupFallbackMarkupContainer(String id,
 IModelString model) {super(id, model);}

 @Override
 public IMarkupFragment getMarkup() {
 String markupString = (String) getDefaultModelObject();
 if (markupString == null) {
 return getAssociatedMarkup();
 } else {
 return Markup.of(markupString);
 }
 }

 @Override public String getCacheKey(MarkupContainer container,
 Class? containerClass) {return null;}
 }

 Regarding the multiple invocations of getMarkup(), they also occur
 when caching, and indeed they occur on every request (caching happens
 only for the associated markup, I assume). The calls all happen inside
 the same call to Component.internalRender()

 Invocations are:
 1: Component.internalRender():2309 // creating a MarkupStream only
 used inside if block

 2:
 Component.internalRenderComponent():2472 // some duplicate code with
 internalRender()
 MarkupContainer.onRender(): 1496
 Component.internalRender():2344

 3:
 Component.renderComponentTag():3961
 Component.internalRenderComponent():2505
 MarkupContainer.onRender(): 1496
 Component.internalRender():2344

 4:
 Component.renderComponentTag():3961
 AssociatedMarkupSourcingStrategy.renderAssociatedMarkup()
 AssociatedMarkupSourcingStrategy.renderAssociatedMarkup()
 PanelMarkupSourcingStrategy.onComponentTagBody():112
 Component.internalRenderComponent():2514
 MarkupContainer.onRender(): 1496
 Component.internalRender():2344



 Regarding usage of onComponentTagBody(), that seems also valid, but
 much deeper into the Wicket API than I would want to go, in particular
 given there are recommended solutions in
 http://wicket.apache.org/guide/guide/advanced.html#advanced_5 and the
 javadoc.

 On Tue, Sep 16, 2014 at 12:00 PM, Andrea Del Bene an.delb...@gmail.com 
 wrote:
 Hi,

 I didn't dig to much into the code, but keep in mind that you are disabling
 markup caching in your example. This might explain why getMarkup is called
 three times.
 Anyway, in your specific case it might be better not to implement
 IMarkupCacheKeyProvider and IMarkupResourceStreamProvider, but simply
 override onComponentTagBody like this:

 @Override
 public void onComponentTagBody(MarkupStream markupStream, ComponentTag
 openTag) {
 if (getDefaultModelObject() == null) {
 super.onComponentTagBody(markupStream, openTag);
 }
 else {

 replaceComponentTagBody(markupStream, openTag, wicket:panelit
 works/wicket:panel);
 }
 }

 So debugging a bit, I find that I get hit by the
 PanelMarkupSourcingStrategy. It seems it throws away the body markup
 in favcor of the associated Markup. So I could advance one step by
 extending WebMarkupContainer instead of Panel.

 I notice that when extending Panel, getMarkup() is being called 3
 times in my example, before the result is being discarded.

 That seems like design smell. If users override getMarkup() with some
 expensive operation, they should be able to rely on this being called
 just once, and this only if the result is actually being used.

 On Tue, Sep 16, 2014 at 11:24 AM, Thibault Kruse
 tibokr...@googlemail.com wrote:



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Programmatic Markup with fallback

2014-09-16 Thread Thibault Kruse
I realize now using the wicket:panel tag only works with panels, so
maybe the wicket way to go would be to have a raw markup file
without the xmlns declaration. I don't know. In any case, I preferred
to use a panel with a complete html file like for any other panel,
so I had to circumvent the PanelMarkupSourcingStrategy from overruling
getMarkup().

In the implementation below I also preferred to use setMarkup() over
overriding getMarkup(). It seems to me getMarkup() is not suitable to
be overwritten, as the rest of the code with Component seems to assume
it is an accessor to a field (hence multiple invocations are assumed
cheap. The last invocation I listed was just used to get a handle to
the MarkupStream). I would recommend making getMarkup() final, and
maybe change the javadoc comment in IMarkupResourceStreamProvider.

I tried to get a IMarkupResourceStreamProvider solution to work, but I
fail to see an obvious way to get the associated Markup of a panel
class implementing IMarkupResourceStreamProvider, all approaches I
tried ended up using the provided getMarkupResourceStream() method.


public class CustomMarkupFallback2MarkupContainer extends
GenericPanelString implements IMarkupCacheKeyProvider {
private boolean overrideMarkup = false;
public CustomMarkupFallback2MarkupContainer(String id, String
markupString) {
super(id);
if (markupString != null) {
setMarkup(Markup.of(markupString));
overrideMarkup = true;
}
}

/**
 * For panels, the strategy by Panel.newMarkupSourcingStrategy()
overrules markup, reads associated markup in the end
 * @return
 */
protected IMarkupSourcingStrategy newMarkupSourcingStrategy()
{
if (overrideMarkup) {
return DefaultMarkupSourcingStrategy.get();
}
return super.newMarkupSourcingStrategy();
}

/**
 * Do not cache markup by wicket, null means no caching. must
implement IMarkupCacheKeyProvider
 */
@Override
public String getCacheKey(MarkupContainer container, Class?
containerClass) {
return null;
}
}

On Tue, Sep 16, 2014 at 2:28 PM, Thibault Kruse
tibokr...@googlemail.com wrote:
 I forgot to mention, for my solution to work, the associated markup
 file must not have tags outside the wicket:panel tags:
 wicket:panel
 Fallback works!
 /wicket:panel

 as opposed to

 ?xml version=1.0 encoding=UTF-8?
 html xmlns=http://www.w3.org/1999/xhtml;
 xmlns:wicket=http://wicket.apache.org;
 body
 wicket:panel
 Fallback works!
 /wicket:panel
 /body
 /html

 So I guess I am still doing something wrong here.

 On Tue, Sep 16, 2014 at 12:28 PM, Thibault Kruse
 tibokr...@googlemail.com wrote:
 So, I have a working solution like this:

 public class CustomMarkupFallbackMarkupContainer extends
 WebMarkupContainer implements IMarkupCacheKeyProvider {
 public CustomMarkupFallbackMarkupContainer(String id,
 IModelString model) {super(id, model);}

 @Override
 public IMarkupFragment getMarkup() {
 String markupString = (String) getDefaultModelObject();
 if (markupString == null) {
 return getAssociatedMarkup();
 } else {
 return Markup.of(markupString);
 }
 }

 @Override public String getCacheKey(MarkupContainer container,
 Class? containerClass) {return null;}
 }

 Regarding the multiple invocations of getMarkup(), they also occur
 when caching, and indeed they occur on every request (caching happens
 only for the associated markup, I assume). The calls all happen inside
 the same call to Component.internalRender()

 Invocations are:
 1: Component.internalRender():2309 // creating a MarkupStream only
 used inside if block

 2:
 Component.internalRenderComponent():2472 // some duplicate code with
 internalRender()
 MarkupContainer.onRender(): 1496
 Component.internalRender():2344

 3:
 Component.renderComponentTag():3961
 Component.internalRenderComponent():2505
 MarkupContainer.onRender(): 1496
 Component.internalRender():2344

 4:
 Component.renderComponentTag():3961
 AssociatedMarkupSourcingStrategy.renderAssociatedMarkup()
 AssociatedMarkupSourcingStrategy.renderAssociatedMarkup()
 PanelMarkupSourcingStrategy.onComponentTagBody():112
 Component.internalRenderComponent():2514
 MarkupContainer.onRender(): 1496
 Component.internalRender():2344



 Regarding usage of onComponentTagBody(), that seems also valid, but
 much deeper into the Wicket API than I would want to go, in particular
 given there are recommended solutions in
 http://wicket.apache.org/guide/guide/advanced.html#advanced_5 and the
 javadoc.

 On Tue, Sep 16, 2014 at 12:00 PM, Andrea Del Bene an.delb...@gmail.com 
 wrote:
 Hi,

 I didn't dig to much into the code, but keep in mind that you are disabling
 markup caching in your example. This might explain why getMarkup is called
 three times.
 Anyway, in your specific case it might be better not to implement
 IMarkupCacheKeyProvider

MarkupContainer rendering without children

2014-09-16 Thread Thibault Kruse
Hi,

is it intentional that if a class directly extends MarkupContainer,
but does not have any children, then its associated markup is not
rendered?

When using

public class FooMarkupContainer extends MarkupContainer implements
IMarkupCacheKeyProvider {
public FooMarkupContainer(String id) {super(id);}

@Override public String getCacheKey(MarkupContainer container,
Class? containerClass) {return null;}
}

with markup

divFoo works!/div

or anything, nothing appears on the page.

It seems the javadoc of MarkupContainer is not entirely clear on this:
http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/MarkupContainer.html

Markup Rendering - A MarkupContainer also holds/references associated
markup which is used to render the container. As the markup stream for
a container is rendered, component references in the markup are
resolved by using the container to look up Components in the
container's component map by id. Each component referenced by the
markup stream is given an opportunity to render itself using the
markup stream. 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Programmatic Markup with fallback

2014-09-15 Thread Thibault Kruse
Hi,

I am trying to create a wicket panel that renders markup from some
remote source, but if fetching fails, renders some fallback markup. I
want to achieve this with minimal code.

I tried two approaches one based on overriding getMarkup(), one based
on http://wicket.apache.org/guide/guide/advanced.html#advanced_5, both
fail:

/**
 * attempts to use custom markup by overriding getMarkup()... but html is used
 */
public class CustomMarkupFallback1Panel extends GenericPanelString {
@Override
public IMarkupFragment getMarkup() {
return Markup.of(it works);
}
}

CustomMarkupFallback1Panel.html:
wicket:panel
Fail!
/wicket:panel


This first one overrides getMarkup() as suggested in the javadoc of
IMarkupResourceStreamProvider, but what gets rendered is instead the
static html (even though the debugger walks through getMarkup().


The second approach fails using IMarkupResourceStreamProvider works
for the intended markup, but not for the fallback markup
public class CustomMarkupFallback2Panel extends GenericPanelString
IMarkupResourceStreamProvider {

@Override
public IResourceStream getMarkupResourceStream(MarkupContainer
container, Class? containerClass) {
if (getModelObject() == null) {
// thows Exception, see below. html file exists
return getMarkup().getMarkupResourceStream();
} else {
// works
return new StringResourceStream(getModelObject());
}
}
}


At least the first failure seems like a bug to me, not sure whether
the second approach is supposed to work, or how else to load markup
the wicket way.

Is there maybe a completely different approach to achieve what I try to do?

cheers,
  Thibault



java.io.IOException: Stream closed
 at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:325)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
 at org.apache.wicket.util.io.BOMInputStream.getBOM(BOMInputStream.java:217)
 at 
org.apache.wicket.util.io.BOMInputStream.readFirstBytes(BOMInputStream.java:261)
 at org.apache.wicket.util.io.BOMInputStream.read(BOMInputStream.java:312)
 at 
org.apache.wicket.util.io.XmlReader.getXmlDeclaration(XmlReader.java:183)
 at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:106)
 at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:81)
 at 
org.apache.wicket.markup.parser.XmlPullParser.parse(XmlPullParser.java:605)
 at 
org.apache.wicket.markup.AbstractMarkupParser.parse(AbstractMarkupParser.java:178)
 at 
org.apache.wicket.markup.loader.SimpleMarkupLoader.loadMarkup(SimpleMarkupLoader.java:51)
 at 
org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:57)
 at 
org.apache.wicket.markup.loader.DefaultMarkupLoader.loadMarkup(DefaultMarkupLoader.java:52)
 at 
org.apache.wicket.markup.MarkupFactory.loadMarkup(MarkupFactory.java:412)
 at org.apache.wicket.markup.MarkupCache.loadMarkup(MarkupCache.java:448)
 at 
org.apache.wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(MarkupCache.java:544)
 at org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:305)
 at org.apache.wicket.markup.MarkupFactory.getMarkup(MarkupFactory.java:236)
 at org.apache.wicket.markup.MarkupFactory.getMarkup(MarkupFactory.java:194)
 at 
org.apache.wicket.MarkupContainer.getAssociatedMarkup(MarkupContainer.java:405)
 at 
org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContainer.java:372)
 at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:244)
 at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:220)
 at org.apache.wicket.Component.renderHead(Component.java:2652)
 at 
org.apache.wicket.markup.renderStrategy.ChildFirstHeaderRenderStrategy$1.component(ChildFirstHeaderRenderStrategy.java:85)
 at 
org.apache.wicket.markup.renderStrategy.DeepChildFirstVisitor.visit(DeepChildFirstVisitor.java:96)
 at 
org.apache.wicket.markup.renderStrategy.DeepChildFirstVisitor.visit(DeepChildFirstVisitor.java:87)
 at 
org.apache.wicket.markup.renderStrategy.DeepChildFirstVisitor.visit(DeepChildFirstVisitor.java:51)
 at 
org.apache.wicket.markup.renderStrategy.ChildFirstHeaderRenderStrategy.renderChildHeaders(ChildFirstHeaderRenderStrategy.java:78)
 at 
org.apache.wicket.markup.renderStrategy.ChildFirstHeaderRenderStrategy.renderHeader(ChildFirstHeaderRenderStrategy.java:57)
 at 
org.apache.wicket.markup.html.internal.HtmlHeaderContainer.onComponentTagBody(HtmlHeaderContainer.java:170)
 at 

Re: Programmatic Markup with fallback

2014-09-15 Thread Thibault Kruse
Sorry, this was wicket 1.6.16 and 1.6.17.
Here is a quickstart, to reproduce both cases some comments have to be switched:
https://github.com/tkruse/custommarkup

On Mon, Sep 15, 2014 at 7:50 PM, Sven Meier s...@meiers.net wrote:
 Hi,

 which Wicket version?

 The first approach leads to a MarkupException here with Wicket 1.6.x.

 Regards
 Sven


 On 09/15/2014 07:37 PM, Thibault Kruse wrote:

 Hi,

 I am trying to create a wicket panel that renders markup from some
 remote source, but if fetching fails, renders some fallback markup. I
 want to achieve this with minimal code.

 I tried two approaches one based on overriding getMarkup(), one based
 on http://wicket.apache.org/guide/guide/advanced.html#advanced_5, both
 fail:

 /**
   * attempts to use custom markup by overriding getMarkup()... but html is
 used
   */
 public class CustomMarkupFallback1Panel extends GenericPanelString {
  @Override
  public IMarkupFragment getMarkup() {
  return Markup.of(it works);
  }
 }

 CustomMarkupFallback1Panel.html:
 wicket:panel
  Fail!
 /wicket:panel


 This first one overrides getMarkup() as suggested in the javadoc of
 IMarkupResourceStreamProvider, but what gets rendered is instead the
 static html (even though the debugger walks through getMarkup().


 The second approach fails using IMarkupResourceStreamProvider works
 for the intended markup, but not for the fallback markup
 public class CustomMarkupFallback2Panel extends GenericPanelString
  IMarkupResourceStreamProvider {

  @Override
  public IResourceStream getMarkupResourceStream(MarkupContainer
 container, Class? containerClass) {
  if (getModelObject() == null) {
  // thows Exception, see below. html file exists
  return getMarkup().getMarkupResourceStream();
  } else {
  // works
  return new StringResourceStream(getModelObject());
  }
  }
 }


 At least the first failure seems like a bug to me, not sure whether
 the second approach is supposed to work, or how else to load markup
 the wicket way.

 Is there maybe a completely different approach to achieve what I try to
 do?

 cheers,
Thibault



 java.io.IOException: Stream closed
   at
 java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:325)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
   at
 org.apache.wicket.util.io.BOMInputStream.getBOM(BOMInputStream.java:217)
   at
 org.apache.wicket.util.io.BOMInputStream.readFirstBytes(BOMInputStream.java:261)
   at
 org.apache.wicket.util.io.BOMInputStream.read(BOMInputStream.java:312)
   at
 org.apache.wicket.util.io.XmlReader.getXmlDeclaration(XmlReader.java:183)
   at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:106)
   at org.apache.wicket.util.io.XmlReader.init(XmlReader.java:81)
   at
 org.apache.wicket.markup.parser.XmlPullParser.parse(XmlPullParser.java:605)
   at
 org.apache.wicket.markup.AbstractMarkupParser.parse(AbstractMarkupParser.java:178)
   at
 org.apache.wicket.markup.loader.SimpleMarkupLoader.loadMarkup(SimpleMarkupLoader.java:51)
   at
 org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:57)
   at
 org.apache.wicket.markup.loader.DefaultMarkupLoader.loadMarkup(DefaultMarkupLoader.java:52)
   at
 org.apache.wicket.markup.MarkupFactory.loadMarkup(MarkupFactory.java:412)
   at
 org.apache.wicket.markup.MarkupCache.loadMarkup(MarkupCache.java:448)
   at
 org.apache.wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(MarkupCache.java:544)
   at
 org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:305)
   at
 org.apache.wicket.markup.MarkupFactory.getMarkup(MarkupFactory.java:236)
   at
 org.apache.wicket.markup.MarkupFactory.getMarkup(MarkupFactory.java:194)
   at
 org.apache.wicket.MarkupContainer.getAssociatedMarkup(MarkupContainer.java:405)
   at
 org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContainer.java:372)
   at
 org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:244)
   at
 org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:220)
   at org.apache.wicket.Component.renderHead(Component.java:2652)
   at
 org.apache.wicket.markup.renderStrategy.ChildFirstHeaderRenderStrategy$1.component(ChildFirstHeaderRenderStrategy.java:85)
   at
 org.apache.wicket.markup.renderStrategy.DeepChildFirstVisitor.visit(DeepChildFirstVisitor.java:96)
   at
 org.apache.wicket.markup.renderStrategy.DeepChildFirstVisitor.visit(DeepChildFirstVisitor.java:87

respond with 404 page while keeping original URL

2014-09-10 Thread Thibault Kruse
Hi,

we have a page for some resource mounted at /resource/id
When users enter an invalid ID, we want to render a 404 page.
However, we would like the resulting page not have the original url
with the invalid id (but http status 404).

Is there any obvious easy way to achieve this? Because it seems the
general way in wicket tutorials on 404 pages seem to rely on
redirecting to a mounted 404 resource, which means the browser will
not display the original invalid URL.

cheers,
  Thibault

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Variant Change Behavior

2014-09-09 Thread Thibault Kruse
The API looks good. I don't have time to test it right now.

On Tue, Sep 9, 2014 at 9:44 AM, Martin Grigorov mgrigo...@apache.org wrote:
 https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commit;h=702bf45a

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Tue, Sep 9, 2014 at 10:42 AM, Martin Grigorov mgrigo...@apache.org
 wrote:

 Please check that the solution provided with
 https://issues.apache.org/jira/browse/WICKET-5694 will do the job.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Mon, Sep 8, 2014 at 10:45 AM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Hm, thinking some more, the general solution would be to fail if a
 variant is requested, and it is among a set of whitelisted variants,
 and the markup is not found. For other variants, using the default
 would probably be fine. This is more general than our current usecase,
 but still significant I believe. I trust that Wicket fails at runtime
 when the markup has an error, and I want to be able to express in
 wicket that for a given component, a set of variants is expected to
 exist, and wicket should fail if the markup is missing for any variant
 in the set.

 On Mon, Sep 8, 2014 at 9:41 AM, Thibault Kruse tibokr...@googlemail.com
 wrote:
  Both solutions are not ideal, since we do not want our tests to become
  brittle. We want to functionally test components in multiple variants,
  but where the variants vary in mere layout (css classes), we do not
  want to have tests break just because the layout changes (as long as
  the component still functions).
 
  Another solution for us would be to have components without variant
  loading fallback behavior. So in general it is obviously good if a
  component falls back to default markup, because we might have a
  component tree where only a subset of involved components have a
  variant markup. But for those component are supposed to have it, it
  would be good if they fail when it is not found (e.g. due to typos).
  However, I guess we cannot implement that logic inside getVariant(),
  as the child components will invoke it. Is there another hook we could
  use to fail for specific components when their variant was not found?
 
  On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  There is nothing specific for this.
  But you can use
  various org.apache.wicket.util.tester.WicketTester#executeTest()
 methods to
  check the response against a valid response pre-saved in a file.
  Or you can use
 org.apache.wicket.util.tester.WicketTester#assertContains()
  to check that a specific String (actually a Regex) is in the response.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
 
  On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse 
 tibokr...@googlemail.com
  wrote:
 
  Thanks Martin,
 
  that works for us. I missed that Variants are inherited from parents.
 
  Is there also a good way that I can assure in our unit tests that the
  variant markup for certain components exists and was found? Else a
  typo would go unnoticed in the unit tests.
 
  cheers,
Thibault
 
  On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov 
 mgrigo...@apache.org
  wrote:
   Hi,
  
   The behaviors are not used for variations.
   For such use cases you should
   override org.apache.wicket.Component#getVariation() on the (base)
 page.
   This way all components will know the correct variation.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
  
   On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse 
 tibokr...@googlemail.com
  
   wrote:
  
   Hi,
  
   playing around with Variants for Components, I am wondering whether
   there is an elegant way to steer Variant markup loading via a
   Behavior.
  
   In our case we want to use a different markup layout based on the
   width of the container the component is going to be used in,
 visually.
  
   So if we imagine a Browser window with desktop size, we might want
 to
   use a component on the full width, on a third of the width, or a
   quarter of the width.
  
   For each such container width, we need different responsive design
   markup. Since this may affect many of our components which inherit
   from different wicket components, I'd like to just add another html
   markup file for the variant, and add a Behavior to the component
 that
   decides the Variant.
  
   cheers,
 Thibault
  
  
 -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org

Re: Variant Change Behavior

2014-09-08 Thread Thibault Kruse
Both solutions are not ideal, since we do not want our tests to become
brittle. We want to functionally test components in multiple variants,
but where the variants vary in mere layout (css classes), we do not
want to have tests break just because the layout changes (as long as
the component still functions).

Another solution for us would be to have components without variant
loading fallback behavior. So in general it is obviously good if a
component falls back to default markup, because we might have a
component tree where only a subset of involved components have a
variant markup. But for those component are supposed to have it, it
would be good if they fail when it is not found (e.g. due to typos).
However, I guess we cannot implement that logic inside getVariant(),
as the child components will invoke it. Is there another hook we could
use to fail for specific components when their variant was not found?

On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi,

 There is nothing specific for this.
 But you can use
 various org.apache.wicket.util.tester.WicketTester#executeTest() methods to
 check the response against a valid response pre-saved in a file.
 Or you can use org.apache.wicket.util.tester.WicketTester#assertContains()
 to check that a specific String (actually a Regex) is in the response.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Thanks Martin,

 that works for us. I missed that Variants are inherited from parents.

 Is there also a good way that I can assure in our unit tests that the
 variant markup for certain components exists and was found? Else a
 typo would go unnoticed in the unit tests.

 cheers,
   Thibault

 On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  The behaviors are not used for variations.
  For such use cases you should
  override org.apache.wicket.Component#getVariation() on the (base) page.
  This way all components will know the correct variation.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
 
  On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse tibokr...@googlemail.com
 
  wrote:
 
  Hi,
 
  playing around with Variants for Components, I am wondering whether
  there is an elegant way to steer Variant markup loading via a
  Behavior.
 
  In our case we want to use a different markup layout based on the
  width of the container the component is going to be used in, visually.
 
  So if we imagine a Browser window with desktop size, we might want to
  use a component on the full width, on a third of the width, or a
  quarter of the width.
 
  For each such container width, we need different responsive design
  markup. Since this may affect many of our components which inherit
  from different wicket components, I'd like to just add another html
  markup file for the variant, and add a Behavior to the component that
  decides the Variant.
 
  cheers,
Thibault
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Variant Change Behavior

2014-09-08 Thread Thibault Kruse
Hm, thinking some more, the general solution would be to fail if a
variant is requested, and it is among a set of whitelisted variants,
and the markup is not found. For other variants, using the default
would probably be fine. This is more general than our current usecase,
but still significant I believe. I trust that Wicket fails at runtime
when the markup has an error, and I want to be able to express in
wicket that for a given component, a set of variants is expected to
exist, and wicket should fail if the markup is missing for any variant
in the set.

On Mon, Sep 8, 2014 at 9:41 AM, Thibault Kruse tibokr...@googlemail.com wrote:
 Both solutions are not ideal, since we do not want our tests to become
 brittle. We want to functionally test components in multiple variants,
 but where the variants vary in mere layout (css classes), we do not
 want to have tests break just because the layout changes (as long as
 the component still functions).

 Another solution for us would be to have components without variant
 loading fallback behavior. So in general it is obviously good if a
 component falls back to default markup, because we might have a
 component tree where only a subset of involved components have a
 variant markup. But for those component are supposed to have it, it
 would be good if they fail when it is not found (e.g. due to typos).
 However, I guess we cannot implement that logic inside getVariant(),
 as the child components will invoke it. Is there another hook we could
 use to fail for specific components when their variant was not found?

 On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi,

 There is nothing specific for this.
 But you can use
 various org.apache.wicket.util.tester.WicketTester#executeTest() methods to
 check the response against a valid response pre-saved in a file.
 Or you can use org.apache.wicket.util.tester.WicketTester#assertContains()
 to check that a specific String (actually a Regex) is in the response.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Thanks Martin,

 that works for us. I missed that Variants are inherited from parents.

 Is there also a good way that I can assure in our unit tests that the
 variant markup for certain components exists and was found? Else a
 typo would go unnoticed in the unit tests.

 cheers,
   Thibault

 On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  The behaviors are not used for variations.
  For such use cases you should
  override org.apache.wicket.Component#getVariation() on the (base) page.
  This way all components will know the correct variation.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
 
  On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse tibokr...@googlemail.com
 
  wrote:
 
  Hi,
 
  playing around with Variants for Components, I am wondering whether
  there is an elegant way to steer Variant markup loading via a
  Behavior.
 
  In our case we want to use a different markup layout based on the
  width of the container the component is going to be used in, visually.
 
  So if we imagine a Browser window with desktop size, we might want to
  use a component on the full width, on a third of the width, or a
  quarter of the width.
 
  For each such container width, we need different responsive design
  markup. Since this may affect many of our components which inherit
  from different wicket components, I'd like to just add another html
  markup file for the variant, and add a Behavior to the component that
  decides the Variant.
 
  cheers,
Thibault
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Variant Change Behavior

2014-09-05 Thread Thibault Kruse
Thanks Martin,

that works for us. I missed that Variants are inherited from parents.

Is there also a good way that I can assure in our unit tests that the
variant markup for certain components exists and was found? Else a
typo would go unnoticed in the unit tests.

cheers,
  Thibault

On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi,

 The behaviors are not used for variations.
 For such use cases you should
 override org.apache.wicket.Component#getVariation() on the (base) page.
 This way all components will know the correct variation.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse tibokr...@googlemail.com
 wrote:

 Hi,

 playing around with Variants for Components, I am wondering whether
 there is an elegant way to steer Variant markup loading via a
 Behavior.

 In our case we want to use a different markup layout based on the
 width of the container the component is going to be used in, visually.

 So if we imagine a Browser window with desktop size, we might want to
 use a component on the full width, on a third of the width, or a
 quarter of the width.

 For each such container width, we need different responsive design
 markup. Since this may affect many of our components which inherit
 from different wicket components, I'd like to just add another html
 markup file for the variant, and add a Behavior to the component that
 decides the Variant.

 cheers,
   Thibault

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Variant Change Behavior

2014-09-03 Thread Thibault Kruse
Hi,

playing around with Variants for Components, I am wondering whether
there is an elegant way to steer Variant markup loading via a
Behavior.

In our case we want to use a different markup layout based on the
width of the container the component is going to be used in, visually.

So if we imagine a Browser window with desktop size, we might want to
use a component on the full width, on a third of the width, or a
quarter of the width.

For each such container width, we need different responsive design
markup. Since this may affect many of our components which inherit
from different wicket components, I'd like to just add another html
markup file for the variant, and add a Behavior to the component that
decides the Variant.

cheers,
  Thibault

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



wicketstuff shiro

2014-08-08 Thread Thibault Kruse
Hi all,

I suggest a breaking change to wicketstuff-shiro here:
https://github.com/wicketstuff/core/issues/328

In brief: wicketstuffshiro allows to use @ShiroSecurityConstraint or
@ShiroSecurityConstraints (with s at the end) annotations on Component
classes to trigger security checks at different phases like
initialization and on rendering. Currently subclass annotations
*discard* superclass annotations, and I suggest all annotation
constraints should be *merged* instead, as default.


A Component may have it's own @ShiroSecurityConstraint, but may also
have a superclass declaring security constraints using
@ShiroSecurityConstraint. Where it uses the same annotation as the
superclass, the superclass annotation is *discarded*.

As an example, the superclass might make sure that an abstract
wicketpage requires Authentication, and a the page subclass might
require a permission product:details:view. In that case, the current
semantics would be that the subclass does not require authentication
anymore, because the parent annotation was overwritten.

I believe the current semantics cause surprise and may cause security
gaps due to bad assumptions by developers. I suggest making a breaking
change such that all superclass constraints are also checked by
default.

Martin Grigorov suggests to also allow overriding parent constraints,
just in order not to restrict developers. I somehow believe that would
be very bad security practice (a page showing security-sensible
details having a constraint, a subpage showing the same details having
less constraints), but still someone might find a good usecase for
this.

As a sidenote, the current semantics are also inconsistent because an
@ShiroSecurityConstraint annotation in a subclass will be merged with
an @ShiroSecurityConstraints (plural) in a parent class. So I believe
the current semantics have to be changed anyways.

Opinions?

cheers,
  Thibault

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org