I know that wicket will take min files when running in deployment mode. But I would like to have possibility to bundle multiple javascript files into one, so that the generated page can load whole javascript from single url. This should happen only is deployment mode, development should still deliver pages containing multiple javascript files.
You need to use "resource bundles". See http://wicket.apache.org/guide/guide/resources.html#resources_6.
You can wrap the registrations with "if (usesDeploymentMode()) {...}"
Related
I'm developing a new Hugo site and in this case I thought to create also a template so.I can use for future site.
Well in the template there are tons of vendor files and library because depending of the pages that the site will implement these library will be used. The problem is on the deploy. For example I use Line icons library that has a lot of .png files. (For example 200 files).
Well in the template I put all the files but could happen that in the site that implement this template I use only five icons. Is there a way that look around the final HTML and the usage of the icons and delete in the public folder the not necessary files?
Not directly.
You would need to add an utility script to your template, in order for any user implementing said template to be able to call this script on demand.
That script should then be able to:
analyze the HTML files generated in public_html
cleanup the icons accordingly
I am writing a web service using play 2.0 in scala.
After getting client's configuration parameters, then the web service will take a while to generate some files. (Note: some files can be short, some other files can take long).
I figured out how to get client's configurations and trigger my computation,
now I need to present the generated files to client side at the end of the session.
So questions are:
How to present the files to client?
I'm thinking about returning a static folder link to client, so that they can go into the folder to
see further what files are there, and so when clicking on the files, the details of the files can be shown, either jpg or text.
But how?
How to not to block client during the generation of the files?
For example, client can still click on the files that are available at that moment.
Then here comes the third question:
How to let the client side know that the long-time computation file is available and listed in the folder?
I'm pretty new to web application, thanks for any suggestion, advice, or little examples are greatly appreciated too!
I would create a web interface to show the created files to your clients and create a background job to for the long computation process. You can create a wait page where a javascript check if the file is created.
The compiled JavaScript output of a GWT application is divided into various files, for instance
*.cache.html
*.gwt.rpc
hosted.html
*.nocache.js
...
I know this is done with the purpose of minimizing the size of the JavaScript, which has to be downloaded by users. For instance so that a Firefox user does not have to load the JavaScript specifically compiled for IE6.
However, especially for small GWT applications it might often be faster to download a single file of say 500kb rather than make two sequential requests first for the 5kb *.nocache.js script and then for the rest of the app (cache.html files, etc.).
This leads me to the question: Is there any framework or procedure to bundle the output of the GWT compiler into a single JavaScript file?
First, you can merge all permutations in a single file by using so-called "soft permutations".
Then, you can inline your *.nocache.js into the HTML host page (e.g. using a JSP's #include directive) to cut one additional request (you might have to add a <meta name=gwt:property content='baseUrl=myapp'> where myapp is the subfolder where the .nocache. files are located).
AFAIK that's what Google are doing for their GWT apps.
Alternatively, you can run the permutation selection on the server-side if you can totally replace the selection script (*.nocache.js) with server-side content negotiation (based on User-Agent and Accept-Language request headers for instance) that can directly generates a <script> tag for the appropriate *.cache.js file (provided you use the xsiframe linker).
AFAIK, Google use all these techniques for their GWT apps (such as Google Groups). For a small app, though, I'm not sure it's worth the effort…
Also, the last two techniques work best when your HTML host page is already dynamic and therefore already non-cacheable; otherwise you're mostly moving the problem, not solving it.
I wonder whether the sso linker can be used when you collapse all properties and soft-permutations down to a single hard permutation.
Yes, but it's maybe not something you want. See this answer: https://stackoverflow.com/a/4453716/66416 to this stackoverflow question: Merge GWT generated files.
I found another way to accomplish this: Writing a custom Linker for GWT. Two examples for linkers which compile into a single JavaScript file are:
GwtNodeLinker.java from Gwt Node project
ServerSingleScriptLinker.java from Env.js project
Can someone explain to me in simple term the concept of caching in GWT. I have read this in many places but may be due to my limited knowledge, i'm not being able to understand it.
Such as nocache.js, cache.js
or other things such as making the client cache files forever or how to make files cached by the client and then if file get changed on the server only then the client download these files again
Generally, there are 3 type of files -
Cache Forever
Cache for some time
Never Cache
Some files can never be cached, and will always fall in the "never cache" bucket. But the biggest performance wins comes from systematically converting files in the second bucket to files that can be cached forever. GWT makes it easy to do this in various ways.
The <md5>.cache.js files are safe to cache forever. If they ever change, GWT will rename the file, and so the browser will be forced to download it again.
The .nocache.js file should never be cached. This file is modified even if you change a single line of code and recompile. The nocache.js contains the links of the <md5>.cache.js, and therefore it is important that the browser always has the latest version of this file.
The third bucket contains images, css and any other static resources that are part of your application. CSS files are always changing, so you cannot tell the browser 'cache forever'. But if you use ClientBundle / CssResource, GWT will manage the file for you. Every time you change the CSS, GWT will rename the file, and therefore the browser will be forced to download it again. This lets you set strong cache headers to get the best performance.
In summary -
For anything that matches .cache., set a far-in-the-future expires header, effectively telling the browser to cache it forever.
For anything that matches .nocache., set cache headers that force the browser to re-validate the resource with the server.
For everything else, you should set a short expires header depending on how often you change resources.
Try to use ClientBundle / CssResource; this automatically renames your resources to *.cache bucket
This blog post has a good overview of the GWT bootstrapping process (and many other parts of the GWT system, incidentally), which has a lot to do with what gets cached and why.
Basically, the generated nocache.js file is a relatively small bit of JS whose sole purpose is to decide which generated permutation should be downloded.
Each individual permutation consists of the implementation of your app specific to the browser, language, etc., of the user. This is a lot more code than the simple bootstrapping code, and thus needs to be cached for your app to respond quickly. These are the cache.html files that get generated by the GWT compiler.
When you recompile and deploy your app, your users will download the nocache.js file as normal, but this will tell their browsers to download a new cache.html file with the app's new features. This will now be cached as well for the next time they load your app.
I have a web app project that I will be starting to work on shortly. One of the features included is going to be a content management system where users can add content and then that content will be combined with a template and then output as a regular .html file. This .html file would then be FTPed to their own web host.
As I've always believed in not reinventing the wheel I figured I'd see if there are any quality customizable CMSes out there that do this already do this. For instance, Blogger.com allows you to post all of your content to your account there; but offers the option to let you use your own hosting. Any time you publish a new article then a new .html page is generated (as well as an updated index page with links to the new article) and then the updated content is FTPed to your own server.
What I would like is something like this that I can modify to more closely suit my needs.
Required Features:
Able to host on my own server
Written in PHP
Users add content through their account, then when posted it is FTPed as .html to their server
Any appropriate pages are also updated to link to the new content (like the index page or whatnot)
Templateable
Customizable
Optional (but very much desired) features:
Written in CodeIgniter or a similar PHP framework
While CodeIgniter isn't strictly required, I would very much prefer it. It speeds up development time and makes things much easier to implement.
So - any suggestions? I've stumbled across a few CMSes that push to remote servers as static pages, but the ones I've found all are hosted on the developers servers which means that I cannot modify it at all.
Adobe Contribute might work for your situation. A developer/designer creates a set of templates with Dreamweaver and publishes the templates. Authorized users can then create pages based on the templates and only make changes within the editable regions. It includes systems for drafts and reviews prior to publishing (via many options, including ftp) and incorporates automatic version control. It can work with static html pages or dynamic pages like php.
Sounds like you need a separate application that can do this for you.
For example, you should be able to write something that queries Drupal's menu router and saves the output (with curl) to a directory and then run's rsync to push your content where you want it to go.
Otherwise your requirements are likely to be outside the scope of a typical CMS. Separating this functionality will give you better options.
You'd need to write a filter for your URLs too. It's a bit of work...
Hope that helps!