I created a clickable tag cloud generator. The tool generates a nice image which is the actual tag cloud, and also to make it clickable and hover-able (interactive), the tool (essentially a method in a class) also returns some HTML.
Since the image and HTML are both generated in the same action method, in my MVC project, I am wondering whether to return a ViewResult (with HTML) or an FileResult (with the Image). I do not want to use the session, and i have <sessionState mode="OFF"> in my App.
Right now, I have a partial solution, where I save the image to the filesystem and send back the HTML ViewResult with the <img> tag in it pointing to the saved image. This obviously will not work with concurrent users (each user may overwrite the file, and interfere with each other)
Essentially what is the best way to send the image and HTML to the browser, without using server-side session? And without using an elaborate filesystem based store for the images?
I'm aware of the <img src="data: .. " /> and since it does not work IE7 and less, and since the image is quite big, its not an option.
Thanks in advance!
Your image must be identifiable in some unique way. Perhaps a time stamp of when the tag cloud was changed? Or a hash of the tags in that cloud?
Put your image and image map into storage.
Mike Brown
Related
Tag 1: Retargeting
Fire on all pages of the site
For Image format use:
<img height="1" width="1" style="border-style:none;" alt=""
src="https://trck.adsway.org/track/pxl/?adv=ou2fddz&yy=0:r1wen4w&fmt=4"/>
I got this, so I created a Custom Html tag that fires on "All Pages" and I put the image DOM element inside the custom html tag, but I am not sure if this is the only thing we need. Aren't we suppose to add some kind of javascript code in order for this to work? I wasn't provided with any js script tag, and I wasn't provided with any documentation, so I have no idea if pixel tracking doesn't need some kind of js file to make the tracking work. Thanks.
You don't need a JS script in order for retargeting to work. Many vendors will provide a simple image pixel. You'll basically send a ping to the vendor each time a page is loaded.
JS would allow you to do more advanced things like read cookies and global variables to collect more information. But maybe you could reach out to who sent you the script and see if a JS script is provided. If not, you should be good to go with just the image pixel.
You do not need additional code. Image requests are a time-honoured method to send information across domain boundaries. On the receiving end there will be a script that writes the information from the query parameters ("?adv=ou2fddz" etc.) to some kind of data store, where it then can be processed. This was long in use before javascript based tracking became common because it is simple and reliable. In fact, even many javascript based tags generate an image request, only they collect information or set cookies or create user ids etc. via Javascript before they send it off. So this should work fine as is.
What you could do better is not to use a custom HTML tag, since they cause extra work every time the pixel is fired. GTM has a tag type "custom image". You save your user's browsers a little work when instead of using custom HTML, you create a custom image tag and insert the url from the "src" attribute of the image:
(the url is cut of in the image, but you need to use the full src attribute).
The cache busting option will add a random parameter. Browsers might decide to cache the image, which means it will be sent only once to the tracking server and on the next occasion will come from the browser cache. The random parameter means this a different url every time, and thus not cached (the parameter usually does not have ill effects on the tracking).
I am building a portfolio page, which contains quite anumber of images. I am pulling the image url's from a database, and creating thumbnails from the original source, and the dispaying the thumbnails. When clicked on, displaying the original full size pic.
Loading times are obviuosly affected and the site take some time before displaying anything...
I have tried putting all this in Ajax, but it seems ajax is only reqally effective if the site has initially loaded. As it is now, the site "hangs" while it waits for the on form laod work to be done.
Any ideas on putting a "please wait while iamges laod" section into the container where the iamges will eb displayed?
Thanks in advance.
Typically you create an HTTP handler that your page sends the image IDs to, something like
<img src="image-handler.ashx?id=SOME_ID" alt="..." />
The key to performance here is that you can then cache the images from this handler. You can save the generated thumbnails to disk and check for existence, and if then use something like Response.TransferFile() to send the file (or actually create the thumbnail files on creation of images, not loading them), or even better, apply output caching on the handler, with vary by param to the id key.
For the full images also you can use the same techniques. You can also in addition have some hidden images you keep setting their URLs by AJAX before clicking thumbnails, so, they are ready when a thumbnail is clicked and a full image needs to be displayed.
Those are just high level thoughts as per the amount of detail I get from the question.
I noticed the pixel array is only one image, I wonder if it is dynamically created on a page request and then cached? Is that possible to do with .NET?
I wouldn't be supprised if the entire page was completely static. It looks like nothing more than an image with an Area Map over the top of it, the query string just changes the image from the previous cached one, probably incremented when he was selling pixels.
http://milliondollarhomepage.com/img-pix/image-map.png?r=476
There's no reason why you can't dynamically generate the image server-side and cache it. So yes it's possible.
It's a single giant image with an image map
You can see this by viewing the source.
Also, being that the image has a querystring parameter, I'm assuming that the image generation and map generation is all being done server side.
src="img-pix/image-map.png?r=323"
And "YES" this is possible to do entirely in .NET
Why does Google Analytic request a GIF file?
Is it because the GIF allows access to more data than JavaScript alone. Is it to get the IP address of the user?
Google's javascript has to transmit the details of your page view to their servers some how. Ajax cannot be used across domains, so the only way to submit the information is to request a file from a Google server, passing the necessary information in the query string. To facilitate this, some form of content must be requested using a standard HTML tag. The easiest way to do this without impacting the page itself is to load a 1x1 transparent gif. Note that in the case of the Google script (and others), this image isn't actually added to the page. It's merely loaded via a javascript statement
var img1 = new Image();
img1.src = 'http://path/to/file.gif?otherinfohere';
This loads the image without adding it to the page. The information could also be loaded using a script tag like so:
<script src="http://path/to/script.js?otherinfohere" type="text/javascript"><script>
However, users are more likely to have javascript blocked than images, so the safer route is to request an image. As to why they would use a gif instead of say, a jpg, a gif is safer in case a rogue browser actually adds the image to the page. The transparent gif is unlikely to negatively impact the layout, where as a 1x1 jpg would leave a 1 pixel dot somewhere on the page.
Edit: To add to my comment about users having blocked javascript, a gif request containing static information can be added inside a noscript tag to allow basic tracking even in the event that javascript is disabled. To my knowledge, GA doesn't do this, but some other web analytics providers do.
Even with JavaScript enabled, analytics requests a GIF file. If you look at the GET params of the image, it contains a lot of information about the browser. Stuff like utmsr=1280x1024 (the screen size). Google Code has a list of parameters.
It uses the image request to send information about the browser without an XMLHttpRequest.
Now, to actually answer the original question, Google is probably doing this to get around cross-domain XMLHttpRequest restrictions.
http://www.perlmonks.org/?node_id=7974
The smallest transparent GIF is 43 bytes.
http://garethrees.org/2007/11/14/pngcrush/
The smallest transparent PNG-24 (which can't be shown by older browsers too) is 67 bytes.
http://www.techsupportteam.org/forum/digital-imaging-photography/1892-worlds-smallest-valid-jpeg.html
The smallest (opaque) JPEG is 134 bytes.
The math is simple! Bigger size = more costs.
you can use the __utm.gif tracker without javascript (w some server help)
you can use it in an email message (w some programmatic help before sending the email)
Urchin was developed before AJAX was popular (2005)
It has nothing to do w cross-domain. They could have used JSONP for that.
Right, in short we basically already have a system in place where the HTML content for emails is generated. It's not perfect, but it works.
From this, we need to be able to derive a plaintext alternative for the email. I was thinking of instantly jumping on and creating a RegEx to strip the <*> tags from the message - but then I realised this would be no good because we do need some of the formatting information (paragraphs, line breaks, images etc).
NOTE: I am OK with actually sending the mail and setting up alternative views etc, this is only about getting plaintext from HTML.
So, I am pondering some ideas. Will post one as an answer to see what you guys think, but thought I would open it up to the floor. :)
If you need any more clarification then please shout.
Many thanks,
Rob
My Solution
OK, so here it is! I thought up a solution to my problem and it works like a charm!
Now, here are some of the goals I wanted to set out:
All the content for the emails should remain in the ASPX pages (as the HTML content currently does).
I didn't want the client code to do anything more other than say "SendMail("PageX.aspx")".
I didn't want to write too much code.
I wanted to keep the code as semantically correct as possible (no REALLY crazy-ass hacks!).
The Process
So, this is what I ended up doing:
Go to the master page for the email messages. Create an ASP.NET MultiView Control. This control would have two views - HTML and PlainText.
Within each view, I added content placeholders for the actual content.
I then grabbed all the existing ASPX code (such as header and footer) and stuck it in the HTML View. All of it, DocType and everything. This does cause VS to whinge a little bit. Ignore It.
I then of course added new content to the PlainText view to best replicate the HTML view in a PlainText environment.
I then added some code to the Master Page_Load, checking for the QueryString parameter "type" which could be either "html" or "text". It falls over to "text" if none present. Dependant on the value, it switches the view.
I then go to the content pages and add new placeholders for the PlainText equivalents and add text as required.
To make my life easier, I then overloaded my SendMail method to get the response for the required page, passing "type=html" and "type=text" and creating AlternateView's as appropriate.
In Summary
So, in short:
The Views seperate the actual "views" of the content (HTML and Text).
A master page auto switches the view based on a QueryString.
Content pages are responsible for how their views look.
Job done!
If any of this is unclear then please shout. I would like to create blog post on this at some point in more detail.
My Idea
Create a page based on the HTML content and traverse the control tree. You can then pick the text from the controls and handle different controls as required (e.g. use ALT text for images, "_____" for HR etc).
You could ensure the HTML mail is in XHTML format so you can parse it easily using the standard XML tools, then create your own DOM serialiser that outputs plain text. It'd still be a lot of work to cover general XHTML, but for a limited subset you plan to use in e-mail it could work.
Alternatively, if you don't mind shelling out to another program, you could just use the -dump switch to the lynx web browser.