Random thoughts
It has been a long time coming. For the first time ever, I have a reliable, affordable asp.net host. I can’t believe I am *HAPPILY* using a hosting service from GoDaddy.
I have been averse to go godaddy over the years, but im a .net develoepr. How am I supposed to pass up $5 / month including asp.net 3.5 and sql server 2005?
Today I created a Windows web hosting account so I could start testing my new CMS project.
The current version is extremely basic and lacking in content, but it works and is improving daily. The rendering engine is at a point where I am ready to begin connecting everything to the database. Once I get the content management system squared away, I will start on the admin panel.
Until I get the admin panel in working order, posting there will be mostly for testing purposes.
link: ForrestLedbetter.net
For the past week, I have been working on creating a content management system, using a template I found on oswd.org. As I was writing the boring stuff, I thought about several more interesting components I could create. The first thing that came to mind was an easy way to display a video from any of the more popular video sharing sites.
So I started this.. a YouTube player wrapper written in ASP.Net (C#). Yeah, I know… there is nothing earth-shattering about sticking some javascript in a usercontrol, but there is a lot more to come. I plan to add support for other popular video sites (hulu, vimeo, etc), as well as rendering options.
All currently available Youtube video parameters have been exposed as properties of the usercontrol. Once properties have been set, call initializeEmbeddedYoutubePlayer(). Grab the code folder for an example.
Whenever I get Amazon’s EC2 figured out, I’ll have it up for demo. Until then, I promise it works! You can download it and run the code yourself.
UPDATE: Link to Sharptube Example
I just read over some of my oldest posts, and found this gem. While I stand by it still, the code is unreadable, and using some class names that will not be relevant to your project. Mayhaps a better approach would be to create a class to implement in pages where needed.
Again, this is really only needed when time is at a premium and you have legacy javascript that accesses page elements by ID that will be mangled by master pages.
Obviously, the best course of action is always to use the coding tools you have and not hack around them. Sometimes, that is not an option. That was the situation I was in when I wrote those posts. Shakespeare’s gotta get paid, son.
Now you can write AND run .net code on pretty much anything, for free. With Mono’s newest release, you can use Visual Basic. I’m not sure why you would want to, but you can if you feel the urge.
Side by side comparison of VB.Net and C# syntax. This was very useful for me when starting out in C# since I already had VB.Net experience.
Pixel2life is an awesome source of tech tutorials including graphic design, coding, 3D animation, photoshop, and on and on. There are tons of things to learn there.
Personally, I don’t like using Modal Dialogs because they are IE only – BUT some times thats what the client wants, so thats what they get. One of the biggest annoyances when using Modal Dialogs is the little quirk of opening a new window when trying to submit a form located within the dialog. The solution is easy enough, it just took a while for me to find so I thought I would post it here:
<head>
<base target="_self" />
</head>
Thats it. I don’t recall where I found this exactly, but it was on some message board after scouring Google search results for quite some time.
So, how do you tell whether to use modals or pops? Thats a pretty easy one too, but its a pain because of all the extra coding required:
var oInput = new Object();
var oReturn = new Object();
if(!window.showModalDialog)
{
//code for browsers not supporting modal dialogs goes here
//
window.open("testpop.htm","testpop","height:570px;width:700px;help:no;scroll:yes;"")
}
else
{
//code for browsers supporting modals goes here
oReturn = showModalDialog("testpop.htm", oInput, "dialogHeight:570px;dialogWidth:700px;center:yes;help:no;scroll:yes;");
tstFormElement.value = oReturn.value;
}
This is more robust than checking whether the incoming browser is IE or not, because who knows when or if the other browsers will integrate modal dialogs? Of course, this just handles opening the window. If you want to manipulate any data on the page opening the dialog/pop, you have to place a similar block in the opened page because the opener is referenced differently. Wait…what?
if(!window.showModalDialog)
{
//code for browsers not supporting modal dialogs goes here
opener.document.getElementById('elementID').value = "test value";
}
else
{
//code for browsers supporting modals goes here
var oReturn = new Object();
oReturn.value = "test value"
//place code to change values when this object is returned
}
So the last (?) hurdle here, is making your faux modal window act like a modal dialog, which is to say, it retains focus and does not allow the user to return to the calling window. I wrote a basic script – placed in the opening window – checking whether the opened window was still open or not. If it was still open, the opener returned focus to the dialog. This worked nicely at first, but when I started hammering away at it I could get it to fail. If anyone has a better suggestion, please let me know – just don’t bring up Mozilla’s modal=true bs, because its crap and it doesn’t work – at least not for me. And even if it does, its only for Mozilla.
There are probably other techniques for this, but these work adequately for me when I am forced to take this route.
Modal Dialogs are bad. If you feel you have no other choice, take a step back and find another way. It will save you blood, sweat, and tears.
UPDATE:
Master pages are quite useful. Use them when applicable, but pay careful attention when you have thousands of lines of legacy javascript. I will leave the original post as is…this is a learning experience for me as well. Note my frustration below:
/UPDATE
UPDATE 2:
Paragraph 2 doesn’t make any sense to people that were not working on that project. I should have made this much more generic
/UPDATE 2
My suggestion: don’t use Master Pages. That is, until MS releases a tool to retrofit your existing javascripts or prevent master pages from name mangling. From what I hear, it is hell on CSS as well, but I haven’t run into that yet.
Instead, I just created 2 user controls, one containing the head of my layout, and one containing the footer. Simple enough for me, and I don’t have to waste time figuring out why my scripts don’t work. If that’s not good enough for you, you’ll need to make use of the .clientID property in your code behind pages – it just was not a viable option in my particular case.
Here is a much cleaner solution. Instead of having to modify all of your javascript calls to use a new function to get elements by partial id or name, you can put a recursive function in the Master Pages onload, which will walk through all the controls and create a javascript variable named with the controls original name, which points to the object declared by the new name. As long as you don’t use any special characters in your elements ids/names, this works like a charm.