Re: Rationale for Converting to AngularJS/Spring MVC
Hi, On Fri, Jan 3, 2014 at 10:11 PM, Richard W. Adams wrote: > As to "How was it difficult?" Don't know. Nothing official came out. I'm > so low on the food chain I don't have many details. All I know is what > leaks out through the grapevine. > Good luck then: in the worse case you will learn new technologies and gain experience on technologies that start to be "hot"
Re: MultiThreading issues with Wicket.
Hi, On Sat, Jan 4, 2014 at 1:06 AM, eaglei22 wrote: > Here is the errors I get: > > > Jan 03 17:04:20 WARN RequestCycleExtra- > Jan 03 17:04:20 WARN RequestCycleExtra-Handling the following exception > org.eclipse.jetty.io.RuntimeIOException: org.eclipse.jetty.io.EofException > at > > org.eclipse.jetty.io.UncheckedPrintWriter.setError(UncheckedPrintWriter.java:107) > This error usually means that the client (the browser) has closed the connection before the server had chance to write the response back to it. It could be caused by many things: - manual: just press ESC key while the server is doing something for a longer time. This will tell the browser to close the connection - IE sometimes switches the compat modes for some reason and this often causes any background connections (like Ajax, image loading, script loading) to be restarted. I.e. the original connection is closed so the first request cannot finish - ... > at > > org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:280) > at > > org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:295) > at > > org.apache.wicket.protocol.http.servlet.ServletWebResponse.sendRedirect(ServletWebResponse.java:251) > at > > org.apache.wicket.protocol.http.HeaderBufferingWebResponse.sendRedirect(HeaderBufferingWebResponse.java:117) > at > > org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:157) > at > > org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:300) > at > > org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:165) > at > > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:861) > at > > org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) > at > > org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310) > at > > org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) > at > > org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) > at > > org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) > at > > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233) > at > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) > at > > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) > at > > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) > at > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) > at > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474) > at > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517) > at > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225) > at > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404) > at > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) > at > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869) > at > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) > at > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247) > at > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:151) > at > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114) > at org.eclipse.jetty.server.Server.handle(Server.java:341) > at > > org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589) > at > > org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823) > at > org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220) > at > org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) > at > > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515) > at > > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) > at > > org.eclipse.jetty.util.thread.QueuedThrea
Re: problem with stateless + onInitialize() + request listener + ListView
Done: https://issues.apache.org/jira/browse/WICKET-5460
On Fri, Jan 3, 2014 at 10:16 PM, Sven Meier wrote:
> This could be a bug. Could you create a quickstart please and attach it to a
> JIRA issue?
>
> Many thanks
> Sven
>
>
> On 01/01/2014 07:38 PM, Martin Geisse wrote:
>>
>> Hi,
>>
>> thanks for the quick response. Just to be sure, I added code to detach
>> the model after changing it, but nothing changed in behavior. In this
>> case, LoadableDetachableModel only caches a *reference* to the
>> underlying java.util.List, which is shared by all instances of the
>> model class (it comes from a static variable). So it's expected that
>> detaching does not change anything in this example, though in more
>> realistic cases it would indeed be another way to cause a similar
>> effect. Sorry for the confusion.
>>
>> The problem is, I think, not that the component is being marked as
>> *rendered*, but as *prepared for render*. From class Component:
>>
>> protected void onBeforeRender()
>> {
>>setFlag(FLAG_PREPARED_FOR_RENDER, true);
>>onBeforeRenderChildren();
>>setRequestFlag(RFLAG_BEFORE_RENDER_SUPER_CALL_VERIFIED, true);
>> }
>>
>> Note the first line. This causes subsequent invocations of
>> internalBeforeRender() to skip the relevant part.
>>
>> Greetings,
>> Martin
>>
>>
>> On Wed, Jan 1, 2014 at 6:33 PM, Sven Meier wrote:
>>>
>>> Hi,
>>>
>>> if I read its javadoc correctly, #internalPrepareForRender(false) should
>>> not
>>> mark the page as rendered (thus the false parameter).
>>>
>>> If your link modifies the ListView's model, it should call #detach() on
>>> it.
>>> Otherwise it will show stale data on next rendering. This doesn't have
>>> anything to do with stateless pages, it is a general practice.
>>> Can you verify whether this is the actual problem?
>>>
>>> Regards
>>> Sven
>>>
>>>
>>> On 01/01/2014 03:51 PM, Martin Geisse wrote:
Hi,
first of all, sorry for double-posting. It seems like I triggered some
strange keyboard shortcut in Gmail before I was finished writing that
mail... :(
I'm having a problem with a ListView that displays an outdated list.
In my test, the ListView uses a LoadableDetachableModel that "loads"
from a static variable just to make sure the model is independent from
any page instance. As far as I can tell, this problem has nothing to
do with the model, but with the way Wicket prepares for a request
listener invocation.
The exact setup is this:
- the page contains a ListView and (outside of the list) a Link that
adds an item to the list in its onClick(). The list itself is stored
in a static variable.
- the page is stateless
- the page's components are created in onInitialize()
Result:
The list doesn't show the most recently added item. Reloading the
original page shows the correct list. Note that by "reloading" I mean
entering the page's URL since the browser's address bar now contains
the request listener URL due to the page being stateless.
This is how I think is happens:
- Initially rendering the page works fine. The page is then discarded
since it's stateless.
- Clicking on the link creates a new page instance to invoke the
link's request listener.
- IPageAndComponentProvider.getComponent() cannot find the link yet
since it is not created until onInitialize() has been called.
- as a consequence, it calls page.internalInitialize() and
internalPrepareForRender(false)
- this creates the link, but it also creates the ListView and prepares
it for rendering. This in turn polls the ListView's model and creates
list items. It also marks the ListView as "prepared for render", which
is the crucial point.
- The link's request listener runs and adds an item to the list.
- After the request listener handler, the page render handler runs
- That handler renders the page, including the ListView
- ... but it doesn't call onBeforeRender() on the ListView anymore,
because it's already marked as "prepared for render"! So it doesn't
pick up the new, up-to-date list from its model.
I'm not sure if I'm "doing it wrong", but then it doesn't seem quite
right that onBeforeRender() gets called before invoking the listener,
but not actually before rendering. There's probably some kind of logic
behind the decision to run onBeforeRender() only when this hasn't yet
happened, right? Is there a general way to "unprepare" the component
in onClick()?
Greetings,
Martin
-
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
AjaxFormComponentUpdatingBehavior works only on first element in a ListView
I am attaching AjaxFormComponentUpdatingBehavior to a DropDownChoice element in a ListView which displays a hidden panel on change event. It works for the first element in the ListView but not for subsequently added elements. I have tracked the cause: All subsequent AJAX behaviours are bounded to the first element, because all DropDownChoice elements in the ListView have the same generated HTML id. Actually when change event triggered on the first element the number of AJAX requests sent is equal to the number of elements in ListView. Does anybody know how to fix this?
Make a Panel draggable
Hi everybody,
I have a panel that contains a RepeatingView, which in turns generates a
number of links. The links are generated based on the context (defined as
current page and previous user actions).
Just now the panel shows up in the top right corner of my webapp and it's
above other things, and I'd like to let users move it where they want.
My code now is:
public class DataContextPanel extends Panel
{
public DataContextPanel(String id)
{
super(id);
add(new Label("contextTitle", "Context"));
RepeatingView sels = new RepeatingView("repeating");
fill(sels);
add(sels);
...
Type
Value
Inhibit
Forget
Ditta⇒
∅
⊠
and, in the page, I have a simple as placeholder for it.
I've tried to change the class and make it extend Draggable from
wicket-jquery-ui instead of Panel, and changed wicket:panel to wicket:extend,
but I got the following exception:
org.apache.wicket.WicketRuntimeException: The component(s) below failed to
render. Possible reasons could be that: 1) you have added a component in code
but forgot to reference it in the markup (thus the component will never be
rendered), 2) if your components were added in a parent container then make
sure the markup for the child container includes them in .
1. [Component id = contextTitle]
2. [RepeatingView [Component id = repeating]]
at org.apache.wicket.Page.checkRendering(Page.java:661)
at org.apache.wicket.Page.onAfterRender(Page.java:818)
at org.apache.wicket.markup.html.WebPage.onAfterRender(WebPage.java:215)
at org.apache.wicket.Component.afterRender(Component.java:892)
at org.apache.wicket.Component.render(Component.java:2319)
at org.apache.wicket.Page.renderPage(Page.java:1010)
...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Make a Panel draggable
wiquery provides draggable as a behavior: which would solve your problem.
On Sat, Jan 4, 2014 at 6:17 PM, Lucio Crusca wrote:
> Hi everybody,
>
> I have a panel that contains a RepeatingView, which in turns generates a
> number of links. The links are generated based on the context (defined as
> current page and previous user actions).
>
> Just now the panel shows up in the top right corner of my webapp and it's
> above other things, and I'd like to let users move it where they want.
>
> My code now is:
>
> public class DataContextPanel extends Panel
> {
> public DataContextPanel(String id)
> {
> super(id);
>
> add(new Label("contextTitle", "Context"));
>
> RepeatingView sels = new RepeatingView("repeating");
> fill(sels);
> add(sels);
> ...
>
>
>
>
>
> Type
> Value
> Inhibit
> Forget
>
>
> Ditta wicket:id="openDetail">⇒
>
> ∅
> ⊠
>
>
>
>
> and, in the page, I have a simple as placeholder for it.
>
> I've tried to change the class and make it extend Draggable from
> wicket-jquery-ui instead of Panel, and changed wicket:panel to
> wicket:extend,
> but I got the following exception:
>
> org.apache.wicket.WicketRuntimeException: The component(s) below failed to
> render. Possible reasons could be that: 1) you have added a component in
> code
> but forgot to reference it in the markup (thus the component will never be
> rendered), 2) if your components were added in a parent container then make
> sure the markup for the child container includes them in .
>
> 1. [Component id = contextTitle]
> 2. [RepeatingView [Component id = repeating]]
>
> at org.apache.wicket.Page.checkRendering(Page.java:661)
> at org.apache.wicket.Page.onAfterRender(Page.java:818)
> at org.apache.wicket.markup.html.WebPage.onAfterRender(WebPage.java:215)
> at org.apache.wicket.Component.afterRender(Component.java:892)
> at org.apache.wicket.Component.render(Component.java:2319)
> at org.apache.wicket.Page.renderPage(Page.java:1010)
> ...
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Regards - Ernesto Reinaldo Barreiro
Re: AjaxFormComponentUpdatingBehavior works only on first element in a ListView
Hi Igor. Try calling listView.setReuseItems(true) Hope that helps Peter. On 4 January 2014 17:09, Igor Dvorzhak wrote: > I am attaching AjaxFormComponentUpdatingBehavior to a DropDownChoice > element in a ListView which displays a hidden panel on change event. It > works for the first element in the ListView but not for subsequently added > elements. > > I have tracked the cause: > > All subsequent AJAX behaviours are bounded to the first element, because > all DropDownChoice elements in the ListView have the same generated HTML > id. > > Actually when change event triggered on the first element the number of > AJAX requests sent is equal to the number of elements in ListView. > > > Does anybody know how to fix this? >
Re: AjaxFormComponentUpdatingBehavior works only on first element in a ListView
Hi Peter, I have already used the listView.setReuseItems(true) method. The actual problem not in refreshing the ListView but in the registering AJAX behavior for DropDownChoice element in it, because the event (AJAX request) is fired only for the first element in a ListView not for the any of the subsequently added elements. In fact for each subsequently added DropDownChoice behavior created but for some reason all of them (behaviors) are registered on the first element. The same problem (with code) described here: http://apache-wicket.1842946.n4.nabble.com/AjaxFormComponentUpdatingBehavior-event-works-only-on-first-element-ListView-td4662721.html -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormComponentUpdatingBehavior-works-only-on-first-element-in-a-ListView-tp4663459p4663463.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFormComponentUpdatingBehavior works only on first element in a ListView
Check your markup for explicit html ids (not wicket ids): ... Remove them. Regards Sven On 01/04/2014 06:09 PM, Igor Dvorzhak wrote: I am attaching AjaxFormComponentUpdatingBehavior to a DropDownChoice element in a ListView which displays a hidden panel on change event. It works for the first element in the ListView but not for subsequently added elements. I have tracked the cause: All subsequent AJAX behaviours are bounded to the first element, because all DropDownChoice elements in the ListView have the same generated HTML id. Actually when change event triggered on the first element the number of AJAX requests sent is equal to the number of elements in ListView. Does anybody know how to fix this? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFormComponentUpdatingBehavior works only on first element in a ListView
Sven, You are right, it helped. Thank you very much. Best, Igor -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormComponentUpdatingBehavior-works-only-on-first-element-in-a-ListView-tp4663459p4663465.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Update to Wicket 6.9.0
When I'm trying to update from Wicket 6.8.0 to 6.9.0 or any succeed release the AJAX components stop to work. For example, AjaxSubmitLink and AjaxButton. There are no any errors in log and AJAX events just not send. Does anybody faced similar issues? Best, Igor
Re: Update to Wicket 6.9.0
Hi, Read the announcement - jQuery has been upgraded. Check the browser JS console On Jan 4, 2014 11:23 PM, "Igor Dvorzhak" wrote: > When I'm trying to update from Wicket 6.8.0 to 6.9.0 or any succeed release > the AJAX components stop to work. > > For example, AjaxSubmitLink and AjaxButton. > > There are no any errors in log and AJAX events just not send. > > Does anybody faced similar issues? > > Best, > Igor >
Re: Update to Wicket 6.9.0
Hi Martin, Don't notice JQuery update note in the release notes for Wicket 6.9.0. You are right, the problem was in removed jQuery method. Thanks for quick response. Best, Igor -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Update-to-Wicket-6-9-0-tp4663466p4663468.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Detecting when nothing is added to AjaxRequestTarget
We get a lot of ComponentNotFoundExceptions in production and I have not been able to reproduce them. I've had discussions on here before about this and I think what is happening is that the user clicks something to change the state of the page, say it removes a button. If we don't add the panel to the AjaxRequestTarget then the button will still be there on the browser for the user to click. When they click that button wicket throws this exception because the server side does not find that button in the component hierarchy(or it isn't visible or whatever). So my question is how can I detect when an Ajax request happens and nothing gets added to the AjaxRequestTarget and log it out? Or is there a better way to run this down? I'm open to any ideas or strategies for fixing this issue. Thanks, Josh -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Detecting-when-nothing-is-added-to-AjaxRequestTarget-tp4663469.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
