Now I know they don’t need my approval - who the heck does apart from my children! - but the new design is certainly less cluttered, and offers (IMHO), a better visiting experience. Things are easier to find, easier to read…. overall a job well done (though of course you would expect that, this is Adobe after all!)

There was, however, one surprise…. of course being a Dreamweaver fan (and yes, I still am a fan of it, even though they don’t have Dreamweaver for Linux (I wish), though I do use Dreamweaver MX running on my main Ubuntu laptop, running under WINE (though I digress)… the surprise I’m about to show you completely threw me, but can you guess what it is?

As you may or may not know, ADOBE have their own AJAXian framework - SPRY - which is a kind of offshoot/amalgamation/rework/integration of the old InterAKT MXWidgets (but with so much more!), so imagine my surprise when I saw this on the Dreamweaver page at ADOBE (http://www.adobe.com/products/dreamweaver/?ogn=EN_US-gntray_prod_dreamweaver_home)

All good so far, and I would definitely agree with these reasons to upgrade……

However, I’m a nosey sod, and because there’s also a nice Accordion widget at the bottom of the page, I thought I’d have a look-see to find out which set of tools they’ve used to create it…. Now as it turns out, it’s a Flash Accordion - Not always easy to tell these days with some of them (yes Javascript can be that good), so in Firefox, with my Web Developer tools extension installed, I did the trusty right click thing….

Now for those not in the know, this won’t mean much… however, Moo Tools (http://mootools.net/) is a compact, light Framework that provides Flash-style effects and widgets, using plain old Javascript… yes you guessed it… in the great scheme of things Moo Tools is a competitor to SPRY! (Well if you can call it a competitor, we’re talking about FREE tools here).

So what does this mean? Do the developers at ADOBE feel that SPRY isn’t up to the job? Moo Tools is certainly a more mature, and robust framework, though SPRY does offer features that Moo doesn’t, the same is also true . Could this be an early indicator that ADOBE are setting their sights on aquiring another company - Mad4Milk (http://mad4milk.net/), who produce Moo Tools, also produce Moo.Fx?

Or could it simply be that in this day and age of open source code, that the ADOBE developers just chose the best tools for the job?

Personally, I believe it to be the latter, but just couldn’t resist fuelling the Conspiracy Theories…. hehehe.

From their site:-

The Complete Mailroom Solution

Not happy with your current franking machines supplier? Make the switch to themailingroom.com

• No hidden extras - we don’t charge for topping up franking machines
• A refreshing change to Pitney Bowes and Neopost franking machines
• Extensive range of quality franking machines to suit every business size
• Value for money franking machines and postal products
• Nationwide network of experienced customer service and support engineers
• At the forefront of design, technology and innovation.

Definitely worth a look!

http://www.themailingroom.com

There are, however, times when I use a stock library to perform some form of function, and these days I find that I’m using the SPRY Framework more and more often.

It all started with the form validation widgets, along with their integration into Dreamweaver CS3, mean that I only occassionally have to delve into code to make minor modifications. To be honest, I haven’t really played with the other widgets that much, until now…

The first of the Widgets I’ve been playing with is the SPRY Accordion.

Now, taking into account, that I’ve upgraded my SPRY installation into CS3 using the freely available extension from Adobe Labs, I’ve been delving under the hood a little.

One of the things I like about the Accordion widget is that it’s easy to implement, but I hit a snag with a project I’m currently working on, as the client will be using IE6. Not that much of a problem, really, until you put an IFRAME into a Conent Panel. Under IE6 it looks awful. Not when it’s rendered, that’s fine, it’s the transition that leaves a lot to be desired, as it flashes, and does all sorts of nasty stuff… so the way around it?

The standard methods don’t allow me to trigger the Opening or Closing of the panels, so that left me stuck, as I thought that I could hide (set the css display property to ‘none’), during the closing transition… but there was no way to trap that…. well… until now

Note: This requires modification to the base file, and while it won’t have any lasting effects, it’s recommended that you make a copy of this file, prior to changing it, and then name it something else. The file I refer to, of course, is SpryAccordion.js

Right, so first things first… hunting through the source, I discovered that there’s a line referring to an onComplete method, though this isn’t implemented… it’s simply presented as:-

this.onComplete = null;

Well that’s no good, throughout the code there are references to this method, if it’s not null, then call the function name that it contains… so…

Search for the Spry.Widget.Accordion.PanelAnimator method, and a few lines down you’ll see:-

this.onComplete = null;

Change it to:-

this.onComplete = accordion.onComplete;

Now that you’ve done that, why not add one for the start? So just above the line I’ve mentioned previously, add the following:-

this.onStart = accordion.onStart;

This is all well and good, but there’s no trigger… we’ve passed a reference but it doesn’t get called at any time. To make sure it’s called find the Spry.Widget.Accordion.PanelAnimator.prototype.start method, and just before the setTimeout line add the following:-

if (this.onStart) this.onStart();

And that’s pretty much all there is to it! So how do we use it?

When you’re instantiating the Accordion object, you now have 2 additional parameters that you can send to it. In my case, the original line instantiating the Accordion was:-

var Accordion1 = new Spry.Widget.Accordion(”Accordion1″);

However, it now reads:-

var Accordion1 = new Spry.Widget.Accordion(”Accordion1″, { onStart: hideMe, onComplete: showMe });

The values hideMe and showMe are references to functions within my page that handle the hiding of the iFRAMEs… For completeness, here are those functions too:-

function toggleIframe(theState) {

// First let’s find which panel is open

var acc = document.getElementById(”Accordion1″);

var divs = acc.getElementsByTagName(”div”);

for (k=0; k < divs.length; k++) {

if (divs[k].className == “AccordionPanel AccordionPanelOpen”) {

var ifr = divs[k].getElementsByTagName(”iframe”);

for (i=0; i < ifr.length; i++) {

ifr[i].style.display = (theState != “show”) ? “block” : “none”;

}

} else {

var ifr = divs[k].getElementsByTagName(”iframe”);

for (i=0; i < ifr.length; i++) {

ifr[i].style.display = (theState != “show”) ? “none” : “block”;

}

}

}

}

function hideMe() {

toggleIframe(”hide”);

}

function showMe() {

toggleIframe(”show”);

}

Both hideMe and showMe call the same piece of code, but with different parameters (note: I didn’t look for ways of passing parameters to the callback function, but then, I didn’t need to)… and in this way, when a panel containing an IFRAME is closed, the IFRAME is hidden first. When the panel is opened and the transition is complete, the IFRAME is shown.

Now, this worked, but there was a delay, because the default speed of the animation is quite slow (60fps taking 500ms… no, I didn’t work this out, it’s in the code). So, I decided I wanted to control the speed of the animation, speed it up a bit, and cause the hide/show iframe element to become less noticeable.

All of this is handled in the Spry.Widget.Accordion.PanelAnimator method. Look for the line that says:-

this.fps = 60;

And change this to:-

this.fps = (accordion.fps) ? accordion.fps : 60;

So when the fps parameter is set, that value us used, otherwise the default value is used instead. Just under that line is another one:-

this.duration = 500;

So perform a similar modification to this line too:-

this.duration = (accordion.duration) ? accordion.duration : 500;

In this way, we now have control over the speed, and the length of the transition (open/close) of each panel. To use these new parameters, you can instantiate the Accordion like this:-

var Accordion1 = new Spry.Widget.Accordion(”Accordion1″, { onStart: hideMe, onComplete: showMe, enableAnimation: true, fps: 120, duration: 125 });

Which if you look at it, makes the transition run at twice the speed for a quarter of the length of the time, and bingo! You no longer notice the hide/show of the iframe.

For now, I’m not putting a working example of this online. The site where I’ve used this is a closed CRM, so no public access… but anyway, I hope this is of use.

Of course, now that InterAKT have been bought by Adobe themselves, the focus has now shifted, and if you want to continue working with your old sites in Dreamweaver CS3, then you have to buy the toolbox. What a ripoff. What’s more, is that the FAQ’s now state that you can’t use the toolbox to work with the PHP_ADODB that InterAKT Championed.

The brings me back to a series of very public arguments between myself and Alexandru COSTIN, proprietor of InterAKT, when Dreamweaver MX first hit the shelves. Those of you who know my background, that pre-DMX I worked extensively alongside InterAKT, teaching them ways of working with the Extensibility Layer and developing core components for them. (Granted this was a two-sided field of learning, and I too learnt alot from these talented guys), but elements such as Server Formats wouldn’t have worked for a long long time, had I not rewritten the implementation, and implemented the now oft copied extensive list of formatted outputs, that some developers believe they can repackage and call their own, when all they’ve really done is taken my work and put it in an extension.

When Dreamweaver MX was released, with it’s own PHP Server Model, I went on record as stating that having 2 PHP Server Models was daft (I still think it is), and that ultimately InterAKT should drop the non-native in support of the native. My arguments were derised, and Alexandru made a number of very public, very loud threats towards me.

Granted, over time, their business model has worked for them (after all they have been aquired by Adobe), but ultimately my argument has won over. PHP_ADODB is dead. It served a great purpose while there was no PHP Server Model, but it’s days were numbered the moment a native one was released.

So what’s the point of this post? Well, not much really, to say that I feel vindicated. It’s also interesting that all of the arguments raised by Alexandru to keep the PHP_ADODB Server Model, supporting InterAKT’s existing customers being the foremost I believe, have now turned to dust, as the moment that they’ve been aquired by Adobe, they’ve given all the customers and developers (who supported InterAKT and put them where they are today) the proverbial punch in the nose.

Don’t believe me? Well, take a look at the original conversation between Alexandru and Myself here and here, and judge for yourself.

Edit: It appears that if you use the PHP/MySQL Server Model in Dreamweaver, then there is a light at the end of the tunnel. According to this thread on the InterAKT forums, there are complimentary upgrades being offered.

So, if you have been a previous customer of either the MX Kollection or MX Kollection Pro, then there is some hope… unfortunately no luck if you bought only one of the bundled items though….

IntelliCART MX has now been discontinued for 6 months, and many things have changed along with the website. First of all, the hosting has been moved to Dreamhosts (who are fantastic BTW). My previous hosts 1&1 were fine and dandy except for the last year, and after a number of major outages (4, where my server was mysteriously unplugged from the switch), numerous support requests which were ignored for weeks (I kid you not) all due to problems with their Plesk admin, I decided enough was enough. They’ve had thousands of pounds out of me over the last few years, and it’s just not on!

Anyway, forgive the rant, with the move, I’ve made a number of decisions. All the old IntelliCART related stuff is now gone. Removed. The support forum was averaging 12 posts a year, and all of the stuff on there is now either out of date, or defunct or both. So there’s no point keeping it live.

I’m keeping the registrations up to date on the domains etc, as I’ve not entirely ruled out a comeback, but given my currently situation at home, time is tight, so I can’t guarantee anything. IntelliCART may return, but no promises.

It’s been a long while since I did anything with this site, largely due to time and family restrictions. So, what’s been happening, and where have I been?

Well, it’s been a difficult year. For those of you who don’t already know, there were some major family upheavals in 2006, that caused many things to change. My children from my previous marriage came to live with us Permanently in June last year, which was the culmination of a number of events involving my ex-wife.

I can’t really comment on the precise in’s and out’s of what happened, but suffice to say, that Bethany and Jordan were removed from their mother’s care, and placed in the care of Becky and I at the behest of Social Services. This was initially an interim solution, though the situation was so bad, that we were all preparing for this to be a permanent placement.

This was finally confirmed in January, when Becky and I were granted residency orders for Bethany and Jordan until they reach their majority (age 18).

It’s been a tough time, with plenty of tears, and no doubt there will be more to come. If it weren’t for the generosity and support of our friends and family we would surely have all cracked under the pressure, and I would like to take this opportunity to thank everyone for their kind words of support and their help.

Thankfully Bethany and Jordan have both settled in very well both in their new home, and in their new schools. Within days of starting her new school Bethany was made a prefect, and we couldn’t be more proud. Jordan has had some settling-in issues, but is progressing well, and thankfully, he’s a bright, intelligent lad, and he’s coming on leaps and bounds, and we couldn’t be happier with their progress.

So, what are my plans with the website now? Well, the hope is that this site will serve as both an oft-used blog, and a repository of knowledge. When I get the time and inclination I shall return to developing extensions for Dreamweaver, though I shall also be working on applications that don’t necessarily rely on that august editor. I’ve not fallen out with the software, though was very surprised to learn about the Macromedia takeover by Adobe. Old news I know, but as I said, it’s been a busy year, and I’ve still got some catching up to do. As the full ramifications of this merger are yet to be felt (though I doubt that will last for long now), I’m really going to reserve judgment until I start seeing some new software versions, before making my final judgements.

I will be honest, though, Adobe’s history with Web Development software hasn’t been a good start IMHO. GoLive was an awful waste of time, I just hope they don’t inflict on Dreamweaver the same fate. Time will tell.

Anyway, update over (for the moment), thanks for taking the time to stop by.