The Belligerent Ivy

Well, happily, Windows has free testing tools for your web server called WCAT. Unfortunately, the documentation is thoroughly confusing to the likes of the Ivy. I found some useful demo tests, but now I need a client list and I'm stuck.

I'm told to type cscript //H:Cscript in a command prompt.
This gives me CScript Error: Can't change default script host.
Er, okay. Running the command prompt as administrator doesn't help, so I went and right-clicked on the wscript file in a file explorer window, and changed the default program. I found cscript.exe in the Windows folder under System32.

Now, I want to install things on my local machine.
Run ‘wcat.wsf –update’
This results in me getting usage text. Okay. Inspect script, sigh, uninstall and reinstall. No dice.

I am directed to run the program manually to see what's going on. wcctl.exe is the controller program. In this case, the client and controller are both on the same computer. I'm supposed to try direct input of these commands. Sounds like fun.
wcctl.exe -t client.ubr -f settings.ubr -s mywebserver -v 10 -c 1 -o wcat_log.xml -x
wcclient.exe wcat_controller_machine_name
The latter gives me an error, the former is still running the test. No output files yet.

I should learn more about Jscript, I guess?

Labels: server, testing

The new CMS will play nice with existing ColdFusion pages, they tell me, so I'm going through our directory structure to check what apps/pages won't simply convert into it. I'm still pretty fuzzy on how form submissions/actions will work, and whether I can have a CMS page submit to a regular action CF page. The current answer is 'probably not', so I'll need to learn more about what kind of database stuff I'll have to install, or if it will work with our SQL Server.

Cruft is my enemy. Out-of-place pages that I can't move simply are sad-making. Also, people are having trouble emailing me, it seems my box under the old system is full and causing problems. Supporting the support is always an interesting run-around. But back to the point- site maintenance, keeping all the content organized especially if others have the responsibility to edit it, is a bear. That's why some people have content managers. Other places only have people like me, who have tasks that seem higher-priority but when said people look at the cleanup tasks end up saying AUGH.

The moral- Site cleanup/maintenance is best done bit-by-bit to avoid massive breakages of links and one's head.

Labels: cms, sql

It's been a bits-and-pieces week at work (plus some well-deserved rest) followed by a training week at work (plus not enough rest). It's going to be pretty crazy making up templates from scratch to look exactly like the current website so we can do a gradual rollout. Since CommonSpot is based in ColdFusion, the form creation is amazingly snappy. Some of the menus are in places I don't really grok, but this is true of all of my meager CMS experience.

In jQuery news, Wijmo has released some widgets! They are very pretty but I haven't a chance to use them yet. Hope to report on that later.

Labels: cms, jquery

I'm used to thinking of WordPress as a blogging tool, much like, er, Blogger. However, in my dev sojourn with conferences and more conferences and presentations and a coworker wanting to do my workplace's website in WordPress (I have to disagree), I have come to understand that WordPress is now used for nonblog sites to manage pages for those who don't know HTML or other coding very well.

But wait! I do web development for a living, I say! I know a bit of PHP and plenty of CSS and HTML and JavaScript, I can do this myself, right? I write dynamic forms and Ajax and write queries and they pay me to do so! I can write a site for my roommate that's more than sufficient!

The obstacle: I'm a poor designer. Maybe mediocre. I can troubleshoot a design, maintain or extend an existing one, but do one from scratch? I'd end up with wacky black fonts on white background. I do simple designs from scratch, but one for music and photography? Doing it justice would be problematic.

Enter the WordPress themes. They've done some design already for me, and the templates will ostensibly speed up page creation. My main concern is how much I can tweak the templates if they do not suit me- there's a template creator, but what if I want custom PHP code? Sonbal tells me that it's pretty hackable, and Donna says it's workable even if one doesn't know PHP. Anyway, the point of the site is to showcase her music, so a content management system may be a solution for her. I'll post again when we have made some progress- if we come to miserable failure I will describe why, and then be belligerent at the WordPress community until I get a response.

Labels: cms, design, wordpress

Sometimes one generates content via Ajax. Sometimes one is using jQuery to play with the content. Since jQuery usually works on document load (and updates the DOM), how can you use jQuery on the dynamic content as it's generated? I had some trouble implementing .live(), so I ended up using a plugin called LiveQuery.

LiveQuery lets me bind events to content that's being loaded asynchronously, and fire events on said content. Here's what I wrote:

$("select[name='favoriteColor']").livequery("change", function() {
var colorform = this.form;
var newSelectedValue = this.value;
colorform.action = "editProfile.jsp?color=" + newSelectedValue;
});

When I change the favorite color in my dynamic form, this makes the HTML in said form change to send the correct arguments- in this case changing the form action. The form action was the dynamic content in this case, because it was a hack. Not terribly proud of it, but it is an example of how LiveQuery saved my bacon.

Note: jQuery 1.3+ is required for LiveQuery 1.1.

Labels: ajax, javascript, jquery

Back in the day, I had a hilariously clunky JavaScript that ran form validation in accordance with some regular expressions- checking that a field had a length greater than zero, checking that the zip code field was numeric and one of two lengths, possibly with a dash...each form had different requirements and its own JavaScript. I thought about refactoring this, but the forms asked for very different information sometimes.

It took me a year to start using the cfform validation. It's not as flexible at javascript, but for familiar data, it has proven quite useful. It works with the form fields <cfinput> (as opposed to <input>), <cfselect> (instead of just &ltselect>) and <cftextarea> (you get the idea).

First Name: <cfinput type="text" name="firstName" size="20" maxlength="20" required="yes" message="Please enter the peon's first name." />

For a simple 'put something in this field, curse it!' don't forget that ColdFusion has this capability.

The fun doesn't stop there, though: you can specify several custom types to check for:

Zip: <cfinput type="text" name="zipCode" size="10" maxlength="10" validate="zipcode" required="yes" message="Please enter a five or nine-digit zip code. If you enter a nine-digit zip code you must put a dash or space in after the first five digits. " />

There's an assortment of types CF can validate. This lets me dig out my regex book only when I need to match a crazy pattern/unfamiliar data. Entire books on regular expressions? Phew!

Labels: coldfusion, forms, javascript

Have not posted, however, have been working in web development. Is this going to become Yet Another Technology Blog? Not really, others can do better. I'm going to use it to chronicle things relating to web dev- ColdFusion and Javascript with a dash of PHP and sysadmining, project management mishaps, complete with code snippets adapted. Funny things one can do, etc.

Labels: coldfusion, javascript, jquery, lincecum, yankees