Hey all! haven't posted here in a while... good to be back.
So, i've been blessed with the task to create a somewhat sophisticated video player...
Here is a quicky example of something I have now:
http://www.vmatrix.com/clients/welcome/
Ok, so thats a shitty example. But, what it DOES do (or should do) is automatically detect your connection speed and video player availible - then stream you the appropriate file.
Anywho, im revamping the entire thing and creating an all new system. Clients will be able to login to an interface and create their own players. There will be a templating system involved. Its going to be all PHP/MySQL. Im not 100% sure about all the specs yet because im a poor planner. I just tend to start writing a module, and then go from there. Usually I try to write my code well enough so I can make alot of design changes without wasting coding time.
Anyways, the first thing I wanna figure out is the templating system. There will be an ability for the client to 'skin' the player however they want. So, I need to write a VERY SIMPLE and scalable templating system. I don't need anything really fancy... i don't think.
Now... I've read a few docs on some different templating systems. Have given smarty a look and all that. But, I can't use opensource software this time. I'm just going to write my own customized one. So, I was curious if anyone had some good information (http/webpage/etc) on making templating systems. Or maybe, someone has a direction they can point me in, or maybe I need to be giving more info?
Currently, im thinking... Store the HTML for the template in the MySQL database, and its associated data in the same table....
Any help appreciated, thanks!
Tekime
04-24-2003, 05:18 PM
Heya Yoshi, player doesn't look half bad so far!
Smarty is way too complex for what you want to do, IMHO it would be a huge waste of time. You can't go that route anyway though, so that's a moot point!
I have used Smarty, FastTemplate, rFastTemplate and a few other hacked up classes and ultimately none of them are entirely perfect. Right now I use rFastTemplate for my main site, but I intend to write my own templating class down the road and use that.
I think for your purposes you can get away with a fairly simple template class, or even just a few functions. Unless you expect to be doing complex things like dynamic blocks and nested dynamic blocks you will be able to get a away with some basic regexps.
I choose to store my template files in .tpl flat files on disk, but you could also insert them into a MySQL DB.
If you know the variable names that will be substituted and you don't care about getting into regexp's you can store your templates as php files and just include them. PHP in itself can almost be considered a templating system:
include('mytemplate.tpl');
As simple as it is, that's templating. The .tpl file could look like:
<h3><?php echo $tpl_title; ?></h3>
<div class="<?php echo $tpl_boxClass; ?>">
This is my customized player box!
</div>
You could set the styles and variables in the template with normal PHP variable assignments. Users could configure their personal style preferences with a form and that info could be stored to DB, then extracted when needed and assigned to the template variables.
Not knowing exactly what you are trying to tackle, it's hard to say the best solution. Not to mention, everyone has a different idea of the perfect template system in the first place.
I don't know any tutorials off the top of my head, most of the stuff out there just tells you how to use existing systems. I'll do some digging and post if I find anything. Not sure if this info even helped much, or if I'm just explaining the obvious, but I've struggled with this for a while so what the heck.
If you have any specific problems or questions I'll do my best to offer some insight though :)
yoshi273
05-02-2003, 02:56 AM
hey, thanks a ton for that information.
And yes, my templating system will need no logic, but there are some template-specific things...
for example, if i want to open up a popup window, a user-made template might have a different dimension size than my templates. So, the template needs some of that data.
I'm planning on just storing everything in MySQL. As far as i can see for now, i might need some advise on setting up my tables, here is what I have so far:
CREATE TABLE vp_templates (
template_id int(10) unsigned NOT NULL auto_increment,
user_id int(10) unsigned NOT NULL default '0',
type_id int(10) unsigned NOT NULL default '0',
width int(5) unsigned default NULL,
height int(5) unsigned default NULL,
code text NOT NULL,
PRIMARY KEY (template_id)
) TYPE=MyISAM;
Can you think of any other fields I might need? And as far as normalization goes, i can't really split this up anymore - can I (and still being reasonable)?
template_id = template id
user_id = the owner of this template (there is user table in the db)
type_id = the type of the template. Some templates are for popups, some are for flat-html pages.
height/width = define the popup size, or how big to be in a flat-html page
code = the html template
=====
also, thanks for the comments on the player. Its actually just static HTML files that are written to the disk when u run through my 'popup creator' thing in PHP. However, alot of those files are duplicates and take up alot of space. I wanted to write 1 player, that would work for ALL clients who have different videos, styles, text, etc. I think this is the best way to do it.
Oh, also... comment on my player-access method. This is how a player will be called:
http://vplayer.vmatrix.com/?variable=value
the variables are:
template = template_name
player = stream type (quicktime, windows, real). used if you want to force a stream type
speed = bitrate of video to be played (we encode in 50, 150, and 300). If this variable is left out, it will be autodetected with js code
video = video name. This is the name of the video to be played (video=sharky means load the sharky videos in, then pick the proper stream codec and speed)
and... thats all i have so far. What do you think?
Tekime
05-02-2003, 10:02 AM
Originally posted by yoshi273
....
I'm planning on just storing everything in MySQL. As far as i can see for now, i might need some advise on setting up my tables, here is what I have so far:
CREATE TABLE vp_templates (
template_id int(10) unsigned NOT NULL auto_increment,
user_id int(10) unsigned NOT NULL default '0',
type_id int(10) unsigned NOT NULL default '0',
width int(5) unsigned default NULL,
height int(5) unsigned default NULL,
code text NOT NULL,
PRIMARY KEY (template_id)
) TYPE=MyISAM;
Looks pretty good to me. The only thing I might change (and this depends on whether you want public templates), is to remove the user_id field (the owner), and instead set a current template_id in the user table. Then users can select from a list of public templates. If you want users to make their own templates and remember who's they are; your current fields look just fine.
Can you think of any other fields I might need? And as far as normalization goes, i can't really split this up anymore - can I (and still being reasonable)?
I don't think there is any need to normalize this table further... really, there isn't much more you could normalize even if you wanted!
The only alternative I might suggest is this. If you have a standard template, and you would rather use that and allow users to create their own deviations of it using styles and variables (like width/height), create a separate table for templates, with an style_id field and a code field. Then create another table for styles (say, tpl_styles) with an template_id and a owner_id. This would create a many-to-many relationship between users and templates, and users could create endless combinations of template styles, while you would maintain control over the basic template format. You could, of course, create any number of basic template formats for users to modify to their personal taste. Just an idea though, and again it depends on how much flexibility you want your users to have, and whether you want the code for every style deviation in the DB. You might want to have a standard format for people to work off though, in which case this method might work better.
Oh, also... comment on my player-access method. This is how a player will be called:
....
I see no problems with that method. You might consider storing some of these variables to a users profile, and session or a cookie so you don't need to access that info via GET every time. You can always supply a small link to change the bitrate, player, etc.
Your model looks good so far, great luck with it and certainly let me know if I can offer any more advice!