Just a non-technical question. We're using Wicket 1.4.x and 1.5.x in
different projects and we're feeling quite confident (at least me) using
this framework. By the way, it might be not quite easy migrating an existing
wicket 1.4 project to wicket 1.5. But that's not the point.
I've noticed, that
Similar to this topic
(http://apache-wicket.1842946.n4.nabble.com/Possible-AbstractAjaxBehavior-Bug-tp1867734p1867734.html)
I'm running into trouble adding a Behavior to a Component dynamically with
an Ajax request.
I have a test page for jQuery UI Effects similar to this example
I have a static list of pre-configured instances (my Effects). On the
page is a select box (a DropDownChoiceAbstractEffect component) which uses
this list of instances to select an effect. Within the onClick() method of
an additional AjaxLink, the WebMarkupContainer (effectContainer) is
updated
Yes, I mean Java's static. Actually it was not meant to re-use this list due
to concurrent requests. It's just a test page. But I've got it. I'll chance
the page and use new instances instead.
--
View this message in context:
Our Wicket application is stateless and doesn't need a HttpSession (the
JSessionID is disabled by default for some SEO reasons for all requests). In
Wicket 1.4 we use our own CodingStrategy implementation to switch between
the Http/Https protocols if a secure annotation (RequireHttps) for a page
I'm not sure. But this is the comment within the source of the
HttpsConfig.class:
/**
* Sets whether or not a new session is created before redirecting from
{@code http} to {@code
* https}
* p
* BE VERY CAREFUL WHEN SETTING THIS VALUE TO {@code false}.
I know, that this setting tells Wicket when to create the HttpSession. And it
seems that if the HttpSession is created in the Https request, the created
Session is not visible to any Http request. In Wicket 1.4 we never switch
back to the Http protocol once the secure protocol is used. So probably
Why is it important not to use RestartResponseException? In Wicket 1.4 it was
the preferred way to redirect to another (error) page e.g. in case of a
missing resource during construction time of a page.
--
View this message in context:
Okay, this is the preferred way if I would have a link on the page, but I
have not. This is also the way like the DownloadLink works:
@Override
public void onClick()
{
...
getRequestCycle().scheduleRequestHandlerAfterCurrent(
Sorry for all the hassle. This sounds now obvious to me. Thank you for your
hint.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Capture-the-response-of-a-page-request-and-displays-another-page-as-result-tp4039468p4042521.html
Sent from the Users forum mailing list
Finally I've implemented my customized IRequestMapper
(CapturingRequestMapper). How can I contribute this little working example
to the wicket-examples?
--
View this message in context:
See https://issues.apache.org/jira/browse/WICKET-4228. Please check the
attached patch whether it works.
Locally it works the way intented.
Dirk Forchel
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Capture-the-response-of-a-page-request-and-displays-another-page
With Wicket 1.4 we used the CapturingBookmarkablePageRequestTarget (and the
belonging CapturingBookmarkablePageRequestTargetUrlCodingStrategy) from the
static examples to capture the response of a page request and display
another page as result instead. I still don't know how to achieve the same
I know this example, but in my opinion this is not really the same use-case,
isn't it? Or I don't fully understand this example. The mailtemplate example
uses a link to generate an email (e.g. generated by the rendering of the
TemplateBaseOnPage) and replaces the content of the MultiLineLabel
Based on the staticpages examples in Wicket 1.4 we used a
CapturingBookmarkablePageRequestTargetUrlCodingStrategy to capture requests
to a bookmarkable page with page parameters and respond with a 'static' page
afterwards. During the capture phase
Hi Martin,
do you mean the asemail package with the MailTemplate page? Unfortunately
this example is not visible live (see
http://www.wicket-library.com/wicket-examples/index.html). But I'm able to
run these examples locally with the latest checkout. But if you type in your
name into the input
Yes, but not on my local machine. Strange enough, only the Panel example
updates the name attribute correctly ...
Oh dear, I found the problem. My local IDE made the String name final. So
the PropertyModel could not update the value correctly. Now it works.
Cheers.
--
View this message in
I've created a quickstart and a ticket in Jira (see
https://issues.apache.org/jira/browse/WICKET-4172).
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Enclosures-and-transparent-WebContainer-tp3935753p3939556.html
Sent from the Users forum mailing list archive at
Here the correct markup:
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Enclosures-and-transparent-WebContainer-tp3935753p3939487.html
Sent from the Users forum mailing list archive at Nabble.com.
Similiar to this post
(http://apache-wicket.1842946.n4.nabble.com/Enclosure-changes-in-1-5-tp3822819p3822819.html)
I've got the same error message using the enclosure-tag and a transparent
WebContainer. I’ve just converted some working 1.4.18 code to 1.5.2 and got
the same error:
In our WebApplication we use a customized WebRequest which extends
ServletWebRequest.
@Override
protected WebRequest newWebRequest( final HttpServletRequest servletRequest,
final String filterPath )
{
return new FooServletWebRequest( servletRequest, filterPath );
}
In order to test some
What is the prefered way to replace removed HeaderContributors in Wicket 1.5?
The migration guide says:
Wicket 1.4:
public class MyPage extends WebPage {
public MyPage() {
add(HeaderContributor.forCss(AbstractCalendar.class,
assets/skins/sam/calendar.css));
}
}
becomes in Wicket 1.5:
After creating a quickstart I've noticed that this might not be a bug but
rather a problem with my application settings. I've got no problems with the
quickstart application and the test page running on Jetty. I let you know
what causes the problem.
--
View this message in context:
I've figured out, that this might be a problem with autodetecting the content
type of a FileResourceStream. If our application uses the development mode,
we use our own ResourceStreamLocator for loading resources from the source
path rather than the class path. This was working in Wicket 1.4
In Wicket 1.4 we used our custom RequestCycle and the onRuntimeException
method to add/change the exception handling. How do we change the exception
handling in Wicket 1.5?
The Migration Guide says:
Exception handling
In Wicket 1.4 it was needed to extend
After struggle for hours with a custom PageFactory implementation and the
WicketTester in Wicket 1.5 I finally figured out, that setting the flag
FLAG_WAS_CREATED_BOOKMARKABLE on a new created page solved our problems with
a new page instance and page redirection (see also
After migration to Wicket 1.5 I'm wondering why our tests with our own
IPageFactory implementation is not working anymore. In our tests we use the
following code ...
WicketTester tester = new WicketTester();
tester.getApplication().getSessionSettings().setPageFactory( new
FooPageFactory() );
But
Martin Grigorov-4 [via Apache Wicket]:
Indeed this is missed.
I'll create a ticket for it.
Thanks!
On Thu, Sep 29, 2011 at 8:05 AM, Dirk Forchel [hidden email]
/user/SendEmail.jtp?type=nodenode=3854567i=0 wrote:
After migration to Wicket 1.5 I'm wondering why our tests with our own
.
Dirk Forchel
Am 29.09.2011 09:40, schrieb Martin Grigorov-4 [via Apache Wicket]:
Put a breakpoint in your factory and see what it returns and why
PageProvider believes it is null ...
On Thu, Sep 29, 2011 at 9:34 AM, Dirk Forchel [hidden email]
/user/SendEmail.jtp?type=nodenode=3854689i=0
...
On Thu, Sep 29, 2011 at 9:34 AM, Dirk Forchel [hidden email]
/user/SendEmail.jtp?type=nodenode=3854689i=0 wrote:
Hi Martin,
thank you for your quick response ... indeed I have another problem
too ...
In our own BookmarkablePageFactoryTest I set up now the test
environment
I still got no solution for the problem mentioned above.
I assume the detection of JavaScript with the following line of code does
not work for Firefox even if JavaScript support is enabled:
((WebClientInfo)Session.get().getClientInfo()).getProperties().isJavaEnabled();
This works for IE but
Hello,
according to this post
(http://apache-wicket.1842946.n4.nabble.com/Overloaded-ClientProperties-isJavaEnabled-and-JavaScript-support-detection-td1889053.html#a1889053)
I'm wondering whether somebody got some problems with the java-enabled
property of his browser too. Using IE8 the
101 - 132 of 132 matches
Mail list logo
