Re: readering strategy of the 'head' section
Hallo, I understand that potentially things could be overridden at a lower child. Although, you can have the same in the opposite direction. Same counts for bugs, but the beauty would be the flexibility I would say. On top of that, I am wondering how others use it than in combination with jQuery. Typically, jQuery has some element specific javascript and css, but rely on the common jQuery (file jqeury-min.js). If now all is driven from the lower childs you cannot place the common jQuery in the toplevel page from which all pages inherit and if a lower child adds the common jQuery you may end up with multiple (potentailly even different versions as well). Therefore, I am curious how most people use it with jQuery as I would say adding a single line in the html from which pages inherit from is way easier then putting a this in Java code. I understand the point of view that you may try to avoid a ParentFHRS, but disagree that core-developers make such a choice for others. So deprecating it sounds not the way to go for me, it reduces maybe the burden of maintaining it by core developers, but for sure also reduces the flexibility of using Wicket. Harrie hhazewin...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: readering strategy of the 'head' section
We add a site-wide IHeaderContributor in Application#init()
using getHeaderContributorListenerCollection(). Our initial implementation
used wicket:head contributions as you do. This became difficult to
maintain when we had multiple top-level pages. (Your site has only one
top-level page?) We also require programmatic switches to conditionally
include various third-party analytics and customer support chat widget.
This is most easy accomplished for us at the application level. Here is a
snippet of this global decorator to give you an idea.
@Override
public void renderHead(IHeaderResponse response) {
response.render(StringHeaderItem.forString(
link rel=\shortcut icon\ type=\image/vnd.microsoft.icon\
href=\/images/favicon.ico\/);
response.render(JavaScriptHeaderItem.forReference(
Application.get().getJavaScriptLibrarySettings().getJQueryReference()));
response.render(Assets.BOOTSTRAP_JS);
response.render(Assets.GLOBAL_JS);
I agree with the point that each component should make its dependencies
clear in its renderHead(), but our jQuery and Bootstrap dependencies are so
pervasive that we got lazy. It makes our components less reusable across
different apps, but that is not an immediate concern for us.
Re: duplicate/conflicting contributions, Wicket automatically de-dups
header contributions. See HeaderItem#getRenderTokens(). Since Wicket itself
pulls in JQuery, your app's use of it should be configured
through IJavaScriptLibrarySettings as shown here.
Dan
On Sun, Mar 24, 2013 at 10:29 AM, Harrie Hazewinkel
hhazewin...@gmail.comwrote:
Hallo,
I understand that potentially things could be overridden at a lower child.
Although,
you can have the same in the opposite direction. Same counts for bugs, but
the
beauty would be the flexibility I would say.
On top of that, I am wondering how others use it than in combination with
jQuery.
Typically, jQuery has some element specific javascript and css, but rely
on the
common jQuery (file jqeury-min.js). If now all is driven from the lower
childs you
cannot place the common jQuery in the toplevel page from which all pages
inherit
and if a lower child adds the common jQuery you may end up with multiple
(potentailly even different versions as well).
Therefore, I am curious how most people use it with jQuery as I would say
adding a single line in the html from which pages inherit from is way
easier then
putting a this in Java code.
I understand the point of view that you may try to avoid a ParentFHRS, but
disagree that core-developers make such a choice for others. So
deprecating it
sounds not the way to go for me, it reduces maybe the burden of
maintaining it
by core developers, but for sure also reduces the flexibility of using
Wicket.
Harrie
hhazewin...@gmail.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
wicket-atmosphere issues
Hello! I'm playing with the wicket-atmosphere module and, while generally it works fine, I stumbled upon a couple of issues: 1) Suppose I have a Page with a method marked with @Subscribe annotation, this subscribtion has a filter attached. Is it possible to get the Page instance inside the filter to, e.g., access Page instance variables when deciding on event filtering? 2) It seems like sometimes empty Atmosphere messages are sent to a page when a filter rejected the specific message. For such events I have the following log record on the server [Atmosphere-AsyncWrite-1] INFO o.a.w.atmosphere.AtmosphereBehavior - onBroadcast: 0|msg| and there is a JS error in a browser after receiveing the event ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Could not find root ajax-response element What is the purpose of sending empty messages to a browser? 3) In my app Apache Shiro framework is integrated via a plugin adapted from fiftyfive-wicket-shiro project. User credentials are checked in an AJAX login form. In order to prevent a session fixation attack there is a call to invalidate old and create new session right before credentials check: getSession().replaceSession(); // inside AjaxFallbackButton.onSubmit() After integration with Atmosphere this code no longer works, an exception in thrown on login attempt: 22:11:41.698 [qtp18908406-24] ERROR o.a.wicket.DefaultExceptionMapper - Unexpected error occurred org.apache.wicket.WicketRuntimeException: Method onRequest of interface org.apache.wicket.behavior.IBehaviorListener targeted at org.apache.wicket.ajax.markup.html.form.AjaxFallbackButton$1@f78197 on component [AjaxFallbackButton [Component id = submit]] threw an exception at org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerInterface.java:268) ~[wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:241) ~[wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:247) ~[wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:226) ~[wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:840) ~[wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) ~[wicket-request-6.6.0.jar:6.6.0] at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:254) [wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:211) [wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:282) [wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:244) [wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188) [wicket-core-6.6.0.jar:6.6.0] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:267) [wicket-core-6.6.0.jar:6.6.0] at org.atmosphere.util.AtmosphereFilterChain.doFilter(AtmosphereFilterChain.java:155) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.util.AtmosphereFilterChain.invokeFilterChain(AtmosphereFilterChain.java:132) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.handler.ReflectorServletProcessor$FilterChainServletWrapper.service(ReflectorServletProcessor.java:314) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.handler.ReflectorServletProcessor.onRequest(ReflectorServletProcessor.java:172) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:256) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:166) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.container.Jetty7CometSupport.service(Jetty7CometSupport.java:96) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.container.JettyAsyncSupportWithWebSocket.service(JettyAsyncSupportWithWebSocket.java:70) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1307) [atmosphere-runtime-1.0.8.jar:1.0.8] at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:293) [atmosphere-runtime-1.0.8.jar:1.0.8] at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) [javax.servlet-3.0.0.v201112011016.jar:na] Caused by: java.lang.IllegalStateException: null at
