Did a quick search and couldn't see anything so ticket raised:
https://issues.apache.org/jira/browse/WICKET-4146 WICKET-4146
-
Eric is learning how to use Wicket and enjoying the experience so far...
--
View this message in context:
Martin Grigorov-4 wrote:
What do you think?
I think this problem deserves a ticket to be discussed in more details.
I'd like to see this resolved for the dynamic image case. Example use case:
1. I have a form that I'd like to re-use between two roles - Admin and
Read-only User. That is,
Encountering a show stopper for our project that involves being able to deal
with a form containing a file upload that can be revealed depending on
whether that particular workflow is desired.
Please see attached quickstart project that shows this failing using Wicket
version 1.4.15 (
Ok. So Igor you're basically saying that as long as there is a possibility
for a file upload, the root form should always be setMultiPart(true) as part
of initialisation. I guess this means it is not a bug? (if so, then I won't
add this to your bug tracking).
I should mention that it will be
Well as per Pedro and Igor's observation - if I setMultiPart(true) on the
root form on initialisation, then I don't encounter exceptions any more
using Wicket 1.4.15. I've applied this in our main development project and
it seems to work fine.
As a quick test, I switched back to Wicket version
As an after thought, I'm leaning towards leaving 1.4.15 the way it is. I
like the idea of having greater control over the multipart settings,
assuming developers know when to enable it and when not to. For example, if
I had another nested form that doesn't involve a file upload, then I'm
Thanks for the suggestion. Since our Wicket application is presently a
singular page, I can kind of imagine how this could work assuming the
'iframe' is embedded in the outermost part of the HTML (thus lies outside of
any potential AJAX refreshes by Wicket). It will also mean that we must
stick
Hi again,
This is how I interpreted your last post Jeremy (please see attached code
fragments:
http://apache-wicket.1842946.n4.nabble.com/file/n3081409/TestingServlet.txt
TestingServlet.txt )
The new approach appears to trigger the separate servlet, but the problem is
that it also redirects
Hi.
Ok, I'm trying to go down the path of what I believe is being suggested
here. So this is what I have as the servlet so far:
{code}
public class HelloServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Autowired
private
Thanks for the reply. Sure - I can understand that if the client submits the
form directly to the separate servlet, then this would achieve the
background processing thread on the server side.
However, wouldn't this mean that the Wicket application loses control in
that client browser window,
10 matches
Mail list logo
