I'm working in a tool (TOPdesk) which uses Freemarker to manipulate outgoing and incoming REST API calls. One of my outgoing POST API calls simply happens too soon, so I need to artificially slow it down, and my only option is to use Freemarker. So I'm looking for a 'wait' command or something similar.
There's no such command in FreeMarker (out of the box). Purely in the template language, you could do a very long #list loop and #break if .now?long has changed the desired amount, but that would be absolutely horrid, as it eats lot of CPU. Actually, the whole premise (you have to wait in a template) sounds quite crazy.
Related
I was wondering if it is possible to use Julia to perform computations on a webpage in an automated way.
For example suppose we have a 3x3 html form in which we input some numbers. These form a square matrix A, and we can find its eigenvalues in Julia pretty straightforward. I would like to use Julia to make the computation and then return the results.
In my understanding (which is limited in this direction) I guess the process should be something like:
collect the data entered in the form
send the data to a machine which has Julia installed
run the Julia code with the given data and store the result
send the result back to the webpage and show it.
Do you think something like this is possible? (I've seen some stuff using HttpServer which allows computation with the browser, but I'm not sure this is the right thing to use) If yes, which are the things which I need to look into? Do you have any examples of such implementations of web calculations?
If you are using or can use Node.js, you can use node-julia. It has some limitations, but should work fine for this.
Coincidentally, I was already mostly done with putting together an example that does this. A rough mockup is available here, which uses express to serve the pages and plotly to display results (among other node modules).
Another option would be to write the server itself in Julia using Mux.jl and skip server-side javascript entirely.
Yes, it can be done with HttpServer.jl
It's pretty simple - you make a small script that starts your HttpServer, which now listens to the designated port. Part of configuring the web server is that you define some handlers (functions) that are invoked when certain events take place in your app's life cycle (new request, error, etc).
Here's a very simple official example:
https://github.com/JuliaWeb/HttpServer.jl/blob/master/examples/fibonacci.jl
However, things can get complex fast:
you already need to perform 2 actions:
a. render your HTML page where you take the user input (by default)
b. render the response page as a consequence of receiving a POST request
you'll need to extract the data payload coming through the form. Data sent via GET is easy to reach, data sent via POST not so much.
if you expose this to users you need to setup some failsafe measures to respawn your server script - otherwise it might just crash and exit.
if you open your script to the world you must make sure that it's not vulnerable to attacks - you don't want to empower a hacker to execute random Julia code on your server or access your DB.
So for basic usage on a small case, yes, HttpServer.jl should be enough.
If however you expect a bigger project, you can give Genie a try (https://github.com/essenciary/Genie.jl). It's still work in progress but it handles most of the low level work allowing developers to focus on the specific app logic, rather than on the transport layer (Genie's author here, btw).
If you get stuck there's GitHub issues and a Gitter channel.
Try Escher.jl.
This enables you to build up the web page in Julia.
I know this question has been asked before..a lot in fact. But I can't seem to get the wheels turning on this thing. To be honest I'm a bit lost on mating client side and server scripting and the examples I've seen are either far to simplistic or way above my head.
Goal:
My goal is to take a long running process I've writtin in VB.NET on the server, which happens to be loop based, and calculate a percentage complete (I know the range of the index values) and relay that back to the user by some means.
Idea:
As the loop iterates I want to pass back up to the client an integer of percent complete or poll it from the client.
What I've done:
Is very limited, I have little to no experience here, I've been doing a lot of googling and I've played with the UpdatePanel and UpdateProgress controls from AJAX a bit, but this method so far seems to lean towards an idicator, like GIF.
As always any help is appreciated, and if I can answer any questions I will.
Have you considered using an inline frame (iFrame) to host your long running process and report back status to the client via the Response object of the long running .aspx page?
If so, then I suggest you read Easy incremental status updates for long requests.
The example uses a button as the display for the progress after the user clicks it, but you could direct output to another DOM element if you wish.
I am using wxWidgets to download the contents of a website into a wxHtmlWindow control. This works flawlessly, except for one thing. The entire gui seems to freeze while the data is being downloaded, which is highly problematic for my application. In most other wxWidgets class methods, events continue to be processed automagicly for you even if the call in question is said to be blocking. This does not appear to be the case here, and I am wondering how I might tell wxWidgets to download the page in the background? I am currently using the LoadPage method.
I guess I could use a second thread, but with the restrictions that wxWidgets imposes on changing the state of any window through any thread other than the main one makes me hesitate to dive into this. Is there a better way? The raw http class, for instance, does not block the window while it's downloading so I don't understand why wxHtmlWindow, which surely must be using the raw http class internally, does not have the same behavior.
Unfortunately wxHtmlWindow uses synchronous sockets to fetch contents of a URL. Call hiearchy goes like this: wxHtmlWindow -> wxHtmlParser -> wxFileSystem -> wxURI -> wxHTTP -> wxHTTP::GetInputStream . The GetInputStream method will use the open a socket in blocking mode.
You will need to use a separate thread to fetch the contents of a website.
I have a flex application that repeatedly polls a remote XML file to detect changes, but I've found that once the file hits a certain size, the poll blocks the UI and makes the page unresponsive for a short time.
Is there any way to ensure that the call made to the server or the event from the flash.utils.Timer class runs asynchronously to the main UI thread?
It sounds like the blocking is caused by Flash parsing the XML rather than the actual loading.
If that is the case then you can keep loading the file and just check the size of the raw data you get back - if it's bigger, parse it and take the parsing hit. Otherwise toss the data and wait for the next request.
There's no explicit way to do threading with Flash at this time. Certain tasks happen async naturally (network and pixelbender comes to mind) but that's it.
Branden's right -- the code we write essentially always happens on the main thread; while the network call itself does happen on a background thread, the handling of that call happens on the main one.
One thing to keep in mind is that the WebService and HTTPService classes will likely attempt to serialize your responses automatically, which could mean taking that processing hit unnecesarily. Using URLLoader, on the other hand, could give you more direct access to the response data, allowing you to work more directly with it without the unnecessary overhead of that built-in processing.
In that light, if you find you do have to process the entire XML file, you might consider breaking it up into chunks somehow, and distributing the processing of those chunks into separate functions, rather than handling everything within the scope of a single function. Just doing that might allow the player to continue updating the UI while you're processing that big bunch of text (processing a bit, exiting the function, rendering the UI, entering the next function, rendering, and so on); Oliver Goldman, an engineer on the AIR team, did a presentation on this concept at last year's MAX conference.
Hope it helps!
Like mentioned, AS3 is single threaded. But there are a couple of ways to handle your situation. Here are ur possible choices:
First,make sure you really need to parse entire XML when loaded and cant just keep the loaded xml nodes in memory as the data model (XML being a native data type now). Sometimes I create value objects by passing them an XMLNode and thats kept in memory till a node value is needed at which point I read it. This allows you to keep some of the parsing for later.
If you are using an ArrayCollection or similar structure to hold data, try using a primitive Array ( see http://www.arpitonline.com/blog/?p=114 for an issue I ran into)
See if you can creatively use callLater()(http://livedocs.adobe.com/flex/2/langref/mx/core/UIComponent.html#callLater())
Can you pass the data to the client in a native format like SWX or using Remoting
Can you use data paging? ArrayCollections and I am pretty sure XMLCollection support it
Side Note:
While AS3 is single threaded, Pixel Bender and I think Alchemy (http://labs.adobe.com/technologies/alchemy/) run on a different thread. There have been a couple of experiments on blogs using Pixel Bender to do calculations which dont slow the UI of the app (Example:http://elromdesign.com/blog/2009/02/09/using-pixel-bender-to-do-heavy-lifting-calculations-makes-flash-player-multi-thread/).
Also please vote on this feature enhancement ticket with Adobe if you feel the need for this feature enough:
https://bugs.adobe.com/jira/browse/ASC-3222
I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.
I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.
As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?
[Edit]
I also should mention that this page will be running in a SharePoint environment.
Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.
i'm against Ajax for such tasks, and vote (and implemented) the first option.
As far as I understand, you won't create Code smells if the JS part is being written by your server-side.
From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).
I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.
Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.
I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.
The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.
Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.
EDIT
Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.