I'll describe that task in some detail so you won't go chasing quickie solutions that can't do the job.
I'm now managing a web site which is embedding ads from a Big E-tailer. (If you're thinking big, you've got the right one.) We have ad blocks for a large number of books and a variety of swag (totes, banners, pins, mugs) and we'd like random selection of ad blocks, as below. Since each ad block results in a request to Big E-tailer's servers, and since our 'library' of ad blocks may run into the hundreds, we don't want the code for a block to be interpreted unless we choose it for display.
In addition we'd also like to have a lot of control over how the blocks are selected, so we would like to be able to store parameters both with the ad blocks and in the display spaces. (Example to follow.) My feeling is that it would be fastest and least stressful all around if the ad blocks' HTML could be stored, with the control parameters, in a single file on the file system we see in our hosting company's server environment. We might have a second file, also there, with parameters for the various display spaces.
What I envision is something like this: An ad display space in the web page (perhaps in the coding for a sidebar) contains a JS program (or the URL thereof). Parameters for that space (one of many) say "three NewBooks, two ClassicFiction, two ClassicNonFic, one Swag, one to three selected randomly from NewBook, ClassicFiction, ClassicNonFic, and Swag.
This yields nine to eleven slots to be filled for this display space, each needing an ad from the specfied category. The order of the slots is now randomized. (I -know- there is a random number function in JS.)
The list of ad blocks (and associated parameters) resides in the server file. Perhaps each category is read into an array, and each array element has a string with the ad block HTML and display control parameters.
For each ad slot in the display space, an ad is selected as follows: First a weighted likelihood is assigned for each available ad, based on the parameters and the slot's location (eg. from top to bottom in the display space). Then, based on the weighting and more "random" numbers, the ad is selected and its text is "injected" into the page. Finally, the ad is removed from consideration for re-display on that page (unless there are not enough left).
Since we have many times more ads than we will use on any given page display, it seems best to keep them as text rather than as Object Model Objects until we know that the particular ad will be needed. This is doubly true because each one results in a request to the e-tailer's servers and too many requests from one browser can make those servers send generic ads rather than the particular product ads. (And of course, making unneeded requests is Not A Nice Thing To Do.)
So where can I use advice? Mostly with the tools and suggested practices for reading the hosting-server files, structuring their content to be interpreted by the program (variable numbers of parameters and defaulted parameters, keyword and numeric, would be helpful; so would a comment convention in the file), and mechanisms for injecting HTML and the subtleties and pitfalls associated with it. Since I have the Rhino Book, pointers to chapter and section would be just fine, if that's best for you.
If you're read this far, I thank you for your patience and attention, and I will be grateful for any pointers you care to offer.
Would you explain why? How does PHP run in the client/broswer environment?
Youd store all your ads and related weighting parameters in a database and manipulate the SQL query to spit out your 9 unique adverts in order of importance/relevancy/popularity etc (depending on your algorithm of choice).
Note that the article stated that the article is obsolete but it is still a good read.
From that you can see why PHP is suggested.
The problem is that I don't own the server and can't run arbitrary programs there. It belongs to a hosting service. I can construct web pages (which are built on the fly from formatting templates and parts I edit like body and sidebar) to be served and use a file system which is accessible via http. I can insert arbitrary HTML, CSS, and compatible scripting languages into the pages and some of the format control blocks. I can edit formatting controls, and even add new parameter/CSS pairings. I can upload, move, rename, and delete files and directories ('folders') and manipulate photo sizes. And replace the favicon, and do a lot of other fiddly little stuff that's probably not helpful here.
I created the high-level design above with these limitations in mind.
Just to be sure the picture is clear: The HTML for each ad is a code fragment that sets up geometry and invokes an object/script from the E-tailer's servers. Those fragments make up the collection(s) that I need to store, manipulate, and select from.
So you can upload a php file ? Thats all you need to do. Sounds like you are just using the HTTP interface given to you by the hosting company, if you go into your admin panel somewhere in there will be section called FTP settings or accounts, make yourself an FTP account for the domain then you will be able to upload download or modify your files in a program such as dreamweaver or one of the many that are out there. It'll make the job much easier.
Yes we understand that
but you will still be better off doing that from the server end with PHP.
Are you familiar with the use of databases ?
Hey Mandes, you beat me to it. So I’m just going to add this:
Databases in the abstract, yes, and I've done a little with them. Databases via PHP, web service, etc., no, I haven't done it and don't understand the architectures, so I don't know what is possible and what is not, or whether anything is possible in the environment here. I'm climbing a learning curve, and am trying to start from my highest point, where I can see all the little issues as well as the big ones.
The hosting service states outright that their system is incompatible with Dreamweaver, etc. Their system builds web pages from units they store, parse, etc. (No, I don't have the option to switch hosting services. It would be a massive change and it's not my decision in any case.)
But I don't need to update data on the server. Or rather, I don't need to do that under program control within a web page. Nor do I need to store data on the client. I need only to access and select data on the server and insert it in a web page on the fly, before/as the page is interpreted and rendered.
Assuming it's even possible in this environment, what advantage is there to pushing the work back to the server? And what does a database give me? Storage without the need to parse the file content? Valuable, but it means that anybody who needs to insert a new ad must go through a database interface or browser/editor. Selecting ads? The processing in question doesn't do joins or content-based selects. This seems like classic loop-and-array work with numbers and strings. Where am I wrong?
can I ask who the hosting company is ?
So your going to hard code the data into the website, so nobody without programming experience and knowledge of your array structures can edit/change/add adverts ?
Your not pushing work back to the server, your doing the work before the page is served in the first place.
The ad fragments are provided by the E-tailer, via web interface. It's copy-and-paste, so the person doing the update does have to see the HTML, but not understand it.
We can't write server files under program control. Well ... we can write forms which will write Excel spreadsheet files. But that doesn't seem very helpful because we can't get the information out from a web page.
The most direct road seems to be storing things in a text file with the ad fragments and parameters, with a fairly simple format including comments which can explain what formatting is needed. It may have to be downloaded, edited, and uploaded, but this is a rote operation and not hard for someone to learn. The hard part is in the programming, being able to read the file and parse it reliably. I've done this many times, but not with HTML fragments embedded. I know that it can waltz through the limited pathways in the environment; I don't know which parts of JS I must master to do it, nor do I know if there's anything to help with reading the HTML text and recognizing syntactic boundaries without inserting everything into the browser's object structures. (Why don't I want that? Because the text, even with 16-bit characters, is almost certainly smaller, and I don't care to dump unneeded megabytes into the user's browser. A megabyte here, a megabyte there, and pretty soon you're talking real memory.)
Can you give an example of how the data is retrieved from the database or how
you actually create a webpage or a link to your site?
Maybe this could be useful:
I use PHP and the data record retrieved from the table may have an image link.
If the page has an image then different Google Adverts are used and the layout changes.
// returns TRUE if an image link is in the $data_2_display
$HAS_PICTURE = strpos( $page_data_2_display, 'src=' );
if( ! $HAS_PICTURE && ! SMARTPHONE)
# vertical spacer to position google advert 10 lines from the top
echo "<div styl='float:right; width:1px; height:10em'>";
echo ' ';
fn_google('_gg_250x250', 'cll flr bgr mg1011');
echo "<div style='float:left'>";
if( $HAS_PICTURE && ! SMARTPHONE )
fn_google('_gg_336x280', 'mga tac');
OK if thats the way you want to proceed I see no reason why you cant put the data into a .txt file on the server in XML format (or similar) then just manually update this file when required.
However I still advise you to do this in PHP before the page is served, as you say its only HTML fragments, so why not assemble them as the page is parsed.
The PHP example highlights some of the differences in how I see things.
If I can effectively insert the "generated" HTML in the HTML stream of the page, I won't have to worry about things like placement. In fact, since much of the overall formatting code is beyond my easy control, it's the only reasonable way. I have blocks of a given size that fit a div of a given width, and that, with border, fits nicely into a sidebar created by code I do not own (but whose width I specify).
The tools at hand do not seem to allow me to assemble the page on the server. If server-side programming were available to me I'd consider it (though it seems to run against scalability).
This task doesn't require assembling something from functionally interdependent components like the PHP example shows. Each ad block is self-contained, so I can shuffle them in an array without breaking things.
I expect to use enough code, in whatever language, that I would rather not embed it inline but instead keep the script on the server to run in the browser.
This topic is now closed. New replies are no longer allowed.