core devs cannot close PRs on github?
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
Re: Plans for further wicket classes with generics
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 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 > 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
Plans for further wicket classes with generics
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
Component error handler
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
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 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
> 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
>> 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
>> >> 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.
>> >> >
>> >> > Marti
Re: respond with 404 page while keeping original URL
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 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
> 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
>> 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
>> >> wrote:
>> >> &g
Re: respond with 404 page while keeping original URL
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 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
> 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
>> 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/
>> >> 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
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 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
> wrote:
>
>> Hi,
>>
>> we have a page for some resource mounted at /resource/
>> 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: turning off page versioning
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 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
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 wrote: > Thibault, > > On Wed, Sep 24, 2014 at 11:23 AM, Thibault Kruse > wrote: > >> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson >> 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
On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson 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
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 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 ..., 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 Class >> 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, >> Class pageClass, byte[] serializedPage) and byte [] get(String >> sessionId, Class 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 >> 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) d
Re: MarkupContainer rendering without children
bump, any opinion? Should I open a JIRA?
On Tue, Sep 16, 2014 at 4:02 PM, Thibault Kruse
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
>
> Foo works!
>
> 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
MarkupContainer rendering without children
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
Foo works!
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
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
GenericPanel 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
wrote:
> I forgot to mention, for my solution to work, the associated markup
> file must not have tags outside the wicket:panel tags:
>
> Fallback works!
>
>
> as opposed to
>
>
> http://www.w3.org/1999/xhtml";
> xmlns:wicket="http://wicket.apache.org";>
>
>
> Fallback works!
>
>
>
>
> So I guess I am still doing something wrong here.
>
> On Tue, Sep 16, 2014 at 12:28 PM, Thibault Kruse
> wrote:
>> So, I have a working solution like this:
>>
>> public class CustomMarkupFallbackMarkupContainer extends
>> WebMarkupContainer implements IMarkupCacheKeyProvider {
>> public CustomMarkupFallbackMarkupContainer(String id,
>> IModel 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
Re: Programmatic Markup with fallback
I forgot to mention, for my solution to work, the associated markup
file must not have tags outside the wicket:panel tags:
Fallback works!
as opposed to
http://www.w3.org/1999/xhtml";
xmlns:wicket="http://wicket.apache.org";>
Fallback works!
So I guess I am still doing something wrong here.
On Tue, Sep 16, 2014 at 12:28 PM, Thibault Kruse
wrote:
> So, I have a working solution like this:
>
> public class CustomMarkupFallbackMarkupContainer extends
> WebMarkupContainer implements IMarkupCacheKeyProvider {
> public CustomMarkupFallbackMarkupContainer(String id,
> IModel 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
> 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, "it
>> works");
>> }
>> }
>>>
>>> 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
>>> 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
So, I have a working solution like this:
public class CustomMarkupFallbackMarkupContainer extends
WebMarkupContainer implements IMarkupCacheKeyProvider {
public CustomMarkupFallbackMarkupContainer(String id,
IModel 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 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, "it
> works");
> }
> }
>>
>> 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
>> 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
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
wrote:
> Regarding the markupException, the example I posted was flawed, must
> be: return Markup.of("it works");
> 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
> 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 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 GenericPanel {
>>>> @Override
>>>> public IMarkupFragment getMarkup() {
>>>> return Markup.of("it works");
>>>> }
>>>> }
>>>>
>>>> CustomMarkupFallback1Panel.html:
>>>>
>>>> Fail!
>>>>
>>>>
>>>>
>>>> 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 GenericPanel
>>>> 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
>&g
Re: Programmatic Markup with fallback
Regarding the markupException, the example I posted was flawed, must
be: return Markup.of("it works");
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
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 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 GenericPanel {
>>> @Override
>>> public IMarkupFragment getMarkup() {
>>> return Markup.of("it works");
>>> }
>>> }
>>>
>>> CustomMarkupFallback1Panel.html:
>>>
>>> Fail!
>>>
>>>
>>>
>>> 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 GenericPanel
>>> 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.(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.DefaultMarkupLo
Re: Programmatic Markup with fallback
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 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 GenericPanel {
>> @Override
>> public IMarkupFragment getMarkup() {
>> return Markup.of("it works");
>> }
>> }
>>
>> CustomMarkupFallback1Panel.html:
>>
>> Fail!
>>
>>
>>
>> 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 GenericPanel
>> 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.(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
>>
Programmatic Markup with fallback
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 GenericPanel {
@Override
public IMarkupFragment getMarkup() {
return Markup.of("it works");
}
}
CustomMarkupFallback1Panel.html:
Fail!
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 GenericPanel
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.(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
org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrateg
respond with 404 page while keeping original URL
Hi, we have a page for some resource mounted at /resource/ 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
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 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 > 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 >> 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 >>> 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 >>> 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 Consultin
Re: Variant Change Behavior
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 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 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 >> 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 >>> 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 >> > >>> > 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
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 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 > 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 >> 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 > > >> > 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
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 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 > 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
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
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
