Is there any way to request pipeline processors in Apache Wicket? Possibly with an open-source framework that integrates with Wicket?
I want to check requests before my web pages are rendered.
In Wicket 1.4.x, you have to extend [Web]RequestCycle, so that you an override the hook methods (onBeginRequest(), onEndRequest(), onAfterTargetsDetached(), etc.), and override Application.newRequestCycle() to return the custom class.
In Wicket 1.5.x, this mechanism has been refactored, so you can just implement the RequestCycleListener, which provides the same hooks. This new mechanism is much better, since you can compose and reuse listeners.
In Wicket 1.4.x (don't know if this has been kept in 1.5) you have RequestCycle#onBeginRequest() and RequestCycle#onEndRequest() that you can override.
Related
I am wanting to use Nuxt3. From my understanding, it uses universal rendering, which is like a cross between CSR and SSR. I have a few questions, however, before I get started.
How does Nuxt3 determine which code is executed on the client-side vs. the server-side?
If I wanted to use JWT auth, will Nuxt3 know that this would be stored on the client-side?
If I wanted to use Pinia as my state management library, which will manage state in the client, how would Nuxt3 be able to distinguish that?
What about API requests or using 3rd party realtime services like
Pusher?
[assuming that you do have ssr: true in your Nuxt config file]
Nuxt runs your app in an isomorphic way, meaning that most of the code should both run on the server and on the client.
Here are all the various hooks available for Nuxt3, and an explanation as of where they are supposed to run (server, client or both). This lifecycle for Nuxt2 may be useful because it's more visual overall.
Note that some parts of Nuxt can be exclusive to the server (server routes) or client (middleware).
Depending on how you use and implement your JWT, you may give some hints to Nuxt. Assuming that you want to use it as a plugin, you could have:
/plugins/myPlugin.ts to have it isomorphic
/plugins/myPlugin.client.ts to have it only on the client side (reciprocity for the server.ts suffix)
It all depends if your package/implementation can be isomorphic or not. There is no need to have everything running on the server if there is no benefit.
Please also note that some code can only run on the client (using window) or on the server (using fs).
You can also of course use some dirty conditional like if (process.client) { ... into an isomorphic place (middleware, composable, etc).
Pinia would probably be used with it's Nuxt module, so you don't really need to worry about it running on the server or the client. I'm not sure if there are parts that could run on both btw.
If there are such situations, don't worry: the core team of Vue have already done that work for you.
Too vague of a question, I'd say it depends. You need to take that decision, based on how a given NPM package works and what you do want to achieve with it.
If it supports a server, that would probably be faster there rather than on the client.
For things only available on the client, you can import it globally with a client side-only plugin, or import it into a local component + make a conditional (or use a lifecycle hook that is run only on the client).
Documentation for DS.ActiveModelAdapter is exists only for 1.13 (for 2 - 404:
https://api.emberjs.com/ember-data/1.13/classes/DS.ActiveModelAdapter
So, it looks like it's moved out from DS:
https://github.com/ember-data/active-model-adapter
We have ember-data 2.13.2 and it's working fine with active-model-adapter
But we got some issues with the bump to ember-data 2.14.11 with nested behavior
The big issue here is to rewrite the backend part.
We also may use RESTAdapter:
https://www.emberscreencasts.com/posts/113-restadapter-vs-jsonapiadapter-vs-activemodeladapter
but it looks like ember way is JSONAPIAdapter way:
https://api.emberjs.com/ember-data/release/classes/JSONAPIAdapter
So, generally, the question is: what way is better for ember-upgrade?
keep backend API and maintain active-model-adapter
rewrite backend API and migrate to JSONAPIAdapter (with data/relationships approach)
rewrite backend API and migrate to RESTAdapter
keep backend API and implement custom serializer to change on the fly input/output to use JSONAPIAdapter or RESTAdapter (pick best) logic on FE (maybe it's some crazy way, but it's just to ask)
Note: backend API on RubyOnRails
A rewrite of your backend is not needed. Ember Data is flexible enough to handle all REST APIs that follow some convention among their endpoints.
Let's have a look on your specific use case.
ActiveModelAdapter and ActiveModelSerializer were deprecated in Ember Data 1.13 and removed in Ember Data 2.0. But the logic itself is still available through active-model-adapter package.
All that package does is providing a customization of Ember Data's build-in RestAdapter and RestSerializer packages. If you ignore the in-source documentation it's actually not much code. You can find it in the addon/ folder of active-model-adapter package.
So even if this package would not be available you could still customize RestAdapter and RestSerializer in the same way to support your backend as is.
We need to setup a new AEM 6.x project that on production makes use of benefits of a CDN (like Akamai) and a dispatcher module within a Apache HTTP Web Server.
So this query is about asking for what point to begin at and what are the steps involved in the same? Also what are the best practices to take into consideration while going for the same?
It entirely depends on how you want to configure your systems, both dispatcher and CDN cache have their own best practices outlined in documentation (available over internet).
There are two types of setup I have seen so far -
Cache everything on dispatcher as well as CDN
Cache everything on dispatcher but do not cache HTML on CDN (so effectively you are caching images, CSS, JS but no HTML)
Cache everything on dispatcher as well as CDN
After first hit everything gets cached
Simple setup
Cache cleanup is complex, you will need your own logic to associate with dispatcher flush to flush CDN cache. Refer to Akamai Connector
There are complexities to related content flush, while publishing the content from author to publish AEM identifies the related content and sends the activation for same. This needs to happen for CDN flush as well.
Complete flush of CDN cache is not an option, it takes a lot of time to complete.
Not caching HTML on CDN
Has all the advantages of above approach
For libraries and image assets implement selector based versioning (AEM ACS Commons provides that for ClientLibs, you could implement your own logic for ASSETS url rewriter that adds last modifiedDate as selector to asset call, and your rendering servlet takes care of selector management)
With proper expires header set on Assets and clientLibraries you will not have to worry about explicit CDN cache management
Pages when activated with new assets and/or library will refer to updated selectors and get cached on dispatcher. When a call is made to that page, CDN caches the libraries and assets and page refers to CDN version of same. Assets and libraries are independent and are reflected independently with the Pages.
Based on TTL the outdated resources gets cleared of from CDN
There may be additional steps required in getting the above steps working, what I have outlined is the high level approach. You will need to follow the security, SSL, domain modeling, and other configuration guidelines as specified in the dispatcher documentation and CDN setup. For few you could refer to AKAMAI blog here
I have a module written in servlets and needs to be recently moved to velocity framework
So in the process I am rewriting the web.xml to create velocity servlet object whcih calls
our original servlet .
Now if this has to be moved to
<servlet>
<servlet-name>VeloServlet</servlet-name>
<servlet-class>org.apache.velocity.tools.view.servlet.VelocityViewServlet</servlet-class>
</servlet>
How can we acheive this and what are all changes need to use the existing servlet as it is.
My Existing servlet looks like
<servlet-name>DataBridgeServlet</servlet-name>
<servlet-class>com.jda.pwm.databridge.framework.common.DataBridgeServlet</servlet-class>
<init-param>
<param-name>jda.databridge.config.path</param-name>
<param-value>d:/usr/databridge/conf</param-value>
</init-param>
This is loaded using the url http://localhost:8080/databridge/databridgeservlet
So in the newer case how velocity servlet calls this servlet
Have you looked at the VelocityViewServlet in the Velocity Tools project? This is a useful way of quickly getting Velocity pages on the web.
http://velocity.apache.org/tools/devel/view.servlet.html
You can subclass this for more customizability if desired. And if nothing else, you can look at the source and use this as inspiration to make your own servlet.
You should take a look at: jpublish.org (I am the maintainer, therefore biased :) and replace your Servlet with a simple Action; scripting (BSH, JS) or Java, as you feel fit. My 0.2CAD
If I have a custom .browser file, and I want to evaluate what will happen if it is given a particular User Agent, is there any way to do that through the .NET API?
I was attempting to use HttpBrowserCapabilites, but I'm not sure how to load a custom .browser file into that class.
Normally, you should not have to explicitly load the HttpBrowserCapabilities class; ASP.NET will load it for you, as long as you have your .browser file in the right place (in App_Browsers).
However, testing it will be another problem. You can't modify the "User-Agent" HTTP Header from within either the HttpApplication (global.asax) or a custom HttpModule.
This leaves only awkward techniques, such as using Reflection to force the value, or using an external tool (such as Fiddler). Alternately, if you're good with C/C++, you could take a simple example for an ISAPI filter and modify it, then install it in IIS.
Install the User Agent Switcher Firefox extension. It will let you adjust the user agent the browser sends to the web server.
http://chrispederick.com/work/user-agent-switcher/