Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

Banner Rotation - tag

Quote Reply
Banner Rotation - tag
Alex,

Something to think about, would be a <%banner rotation%> tag(s) to allow automatic rotation of banners.

While it's a simple idea, integrating the banner rotation into the Links-build process would allow 'category' banners, and internal rotations.

If the rotation was built in, banner rotation could be selected by Category, keyword, or special banner category field.

You don't have to develop the banner rotation code, just the hooks for it.

If a special tag <%banner rotation%> was available, in a template, the 'rotation' could be replaced by code from the appropriate rotation file.

The advantage of this, vs just a template tag, is that in the nph-build routine, when the program hits the <%banner rotation%> tag, it can branch to a subroutine that can be changed to handle whatever sort of banner rotation the user wanted, or just a basic set of commands. This keeps with good design, since major changes to the program are made in an isolated subroutine, with the access to them via the <%banner rotation%> tag.

This, with the unique page tag, can allow implementation of a full banner program.

Rules for banner rotation could be in the subroutine, such that first the "Rotation" field is filled in, the value there is used, if not, a rotation is selected from category or keywords (the highest ranked).

But, all this can be done by the user, or 3rd party, if the hooks to the <%banner rotation%> routines are added.

This would allow things such that the advertising field in the Category table is used for category development, and if the Link doesn't have an overriding category or advertiser for the detail page, the category rotation is used. This would allow 'generic' rotations for the category, but specific advertisers for a specific link (or category sponsor).

The <%banner Rotation%> tag means use the standard rules, a <%banner Toys02%> means use the Toys02 rotation code.

On you end, the 'official' implemenation of this is just the tag processing. The rest of the work can be left to the 3rd party. Even just implementing the tags allows minor functionality without much processing code.

It's something to think about. This simple addtion, opens a whole new set of features that can be easily customized without having to go into the code except for the one subroutine. (This also opens up a whole aspect of UserSubs.pm where hooks can be added into Links for functionality that can be user-added to files that are not part of the regular upgrade.)

Any chance for discussing this type of feature?

Quote Reply
Re: Banner Rotation - tag In reply to
I like this idea and think it would be a
great one to have although I have not bought
Links SQL yet...

Also in the next version of links I think
being able to build mutiple databases would
be nice... And was wondering if having
a search.db that only held the sites
seachable data that might help build larger
bases that search faster...

Charlie...

Quote Reply
Re: Banner Rotation - tag In reply to
You can already do this in Links SQL, set up in your globals:

banner_rotation = \&display_banner

Now whenever a <%banner_rotation%> tag is found, the display_banner subroutine would be called and the return value would be displayed. Is this close to what you were asking for?

Cheers,

Alex
Quote Reply
Re: Banner Rotation - tag In reply to
Hello Alex!

Hoping that this and all such issues will also be included in the next version, I do not copy this.

Thanks

------------------
rajani











Quote Reply
Re: Banner Rotation - tag In reply to
Pretty close...

but it doesn't allow the embedding of the parameter along the lines of your <%if eq xx%> tag.

For those who don't get it, \&banner_rotation creates a _reference_ to a subroutine, so every time it is accessed, it will run through the subroutine and return a value. This will allow a banner rotation, for example, if the subroutine returns banner code with a random number in it.

What I am hoping for is a slightly more advanced solution, adding the <%banner rotation%> tag to the parse subroutine, so that it will pass the &banner_rotation subroutine the second paramenter -- "rotation" being the default <%banner rotation%> value.

This will allow rotations to be set up such that <%banner rotate125toy%> would, for example, cause the &banner_rotation subroutine to return code for a 125x125 banner from the "toy" rotation.

More complexity: Nesting parameters such as <%banner <%cat_id%>%> might open a can of worms, but it would add a world of functionality to the code.

Some other way of passing the current value to the &banner_rotation subroutine should be enabled, so if nested parameters is not feasible, using an '_' preceding a vlaue would mean to use the current value of that parameter, rather than pass that to the &banner_rotation _as_ a paramter.

Again, _ALL_ the real work has to be in the &banner_rotation subroutine, but by providing this interface to the routine, it allows the development of banner rotation programs that don't alter "links" itself, but which can communicate with it through the <%banner rotation%> tag.

Quote Reply
Re: Banner Rotation - tag In reply to
How about just making available to any subroutine all the tags? This is quite easily added. So the first argument to any subroutine (like &banner_rotate) would be a hash ref of all the tags. You could then work with category ID quite easily.

Or even better, allow you to specify parameters in the tag (which is what I think you were getting at). So <%banner_rotate something%> would invoke a subroutine &banner_rotate with the first argument as 'something' and the next argument a list of current tags? It's still only a one or two liner addition.. Let me know what you think. Any preference to the order (tags first, then extra parameters)?

Cheers,

Alex
Quote Reply
Re: Banner Rotation - tag In reply to
Cool...

I think to keep things in the same way of thinking, the tag comes first, then the optional parameter.

<%banner_rotate%> would run through the &banner_rotate subroutine with default parameters, <%banner_rotate one two <%cat_id%>%> would run through the &banner_rotate routine with the parameters one, two and <%cat_id%> ??

The only question I have is if this is going to be passed as a hash, what are key=>value pairs? For <%cat_id%> it would be cat_id => 'value' but what would the other parameters be passed as? name=>'name' ?

I _like_ this discussion Smile
Quote Reply
Re: Banner Rotation - tag In reply to
What I was thinking is your subroutine should expect at least one argument, a hash reference. This will be a list of all available tags in the templates. Any other arguments will just be what's passed in. So to setup banner rotate add:

banner_rotate => \&banner_rotate

to the globals. Then call it with:

<%banner_rotate my123%>

and your actual subroutine would look like:

sub banner_rotate {
# -------------------------------------------
my ($tags, $arg1) = @_;
...
}

where tags is a hash reference so you could do things like get $tags->{ID} to get the current category ID, etc.

Let me know if you have any comments, I'll try and get this in the next version.

Cheers,

Alex
Quote Reply
Re: Banner Rotation - tag In reply to
Ok,

Let me see if I'm getting this, but it sounds pretty complicated (I tend to make things that way).

PERL allows only one hash/array to be passed to a subroutine, and it sould be the LAST parameter, because it's flattened.

I guess I'm blocking on how a parameter list from the templates gets parsed into the hash.

Are you saying that the parameter line will just be unparsed tokens -- date rather than <%date%>

Wait -- you are saying the only values passed in the template are global values -- so they must exist in the %globals array, then they are hashed through the magic of perl.

How about a compromise situation, where the first paramter of the <%banner_rotaion%> tag is scalar, so you can pass something directly to the routine <%banner_rotation 'something nice to pass' HASH_VALUES%>

So, let's say you wanted to insert the banner, but you wanted to be able to pass some arbitrary value the arbitrary value is placed first. It's NOT a global variable, since those will be passed in the HASH list.

That's a 'wish' since it will allow more flexibility such as hard-coding some value into a template to be passed to <%banner_rotate%> so that the routine knows where it is (maybe overriding the cat_id value with a 'section' or preferred advertiser value)

Alex, the reason for this is that in a specific template you might want to pass a certain value to the subroutine, rather than a global value.

There needs to be a way to pass "hard" scalar values as well as globals to the subroutine for maximum utility.

Since the &banner_rotate is a routine that is handled by the 3rd party, it can be as complex or simple as they want. Some things don't need to be global -- they just need to be passed in that instance.

This way banner rotation internals can be hidden from Links, and the templates interact with the programs by how many parameters they pass.

I'm trying to isolate the 'user subroutine' from the rest of links. As long as links can process the tag, everything else should be done by the subroutine -- including what parameters it needs. Globals can be defined as needed, but static locals can be passed too. This way, the hacker can decide what is passed to a subroutine, and the subroutine returns a 'tag value' in a scalar. Input is:

<%&subroutine list HASH%>

and output is

$value

This is more important with template sets, since you might want to set certain things template by template to override defaults.



Would it be possible to have the only required parameter be the LAST one, the HASH, and anything else between the tag and the last parameter is passed to the subroutine?

Otherwise, a heck of a lot of things would need to be declared in the %globals hash that really don't need to be global.

Although, the more I think about it, I think my original idea might work best -- 'scalar' values are passed 'as is' and the globals are defined with an '_' ....

<%banner_rotate 125 blue _date _cat_id%>

would pass 125 and blue directly as parameter 1 and 2, and a HASH of the values 'date' and 'cat_id'

Passing globals only would be a great first step, but to make this a general way of creating user-defined subroutines some mechanism for being able to pass non-global parameters needs to be thought about. Keeping as many users out of the code as possible makes it much easier in the long run for upgrades, mods and support. To debug something, just use the 'standard' templates, to see if it's in links or a 3rd party routine.




[This message has been edited by pugdog (edited September 24, 1999).]
Quote Reply
Re: Banner Rotation - tag In reply to
Hi,

I think you are missing what I suggested. The first arguement to the subroutine would be a reference to a hash, not a hash. If you are unfamiliar with references, have a look at man perlref to see how they work.

Basically, your first argument would be $tags and you could access any of the tags available to that template by doing: $tags->{Field_Name}. The next arguments would be items passed in the actual template. i.e: <%banner_rotate my123 joeblow%>, so you would get 'my123' as the first argument, and 'joeblow' as the second.

Does this make sense?

Cheers,

Alex
Quote Reply
Re: Banner Rotation - tag In reply to
Got it, I think...

<%banner_rotate mytag1 mytag2%>

Would in reality pass 3 parameters to the %banner_rotate subroutine - by default -- \$tags (the reference to the available 'tags'hash) -- and 'mytag1' and 'mytag2'.

So, this particular &banner_rotate subroutine would be expecting -- my (HASH, tag1, tag2).

Sometimes I miss the forest for the trees.

Pass by reference makes it all simple....