Where Delphi has always excelled, even to this day, is where its IDE and it’s VCL meet – you design the look of the application first, and then slap code in behind it second.   Not the other way around.   Users are given a “form” on which they can drag components from the visual component library.   The VCL is a vast palette of components and elements really allowing you to make your program look however you want..   Afterward positioning everything and making the program look “correct” you go into each component and add the various bits needed to make them do what you want.  

When it comes to rapid application development, Delphi is king.   It beats VB, VC and Java hands down for easy of program design.  This is my opinion of course and largely an opinion based on my experiences with it years ago.   I don’t use it any more but I know a lot of folks still do and it’s doing fairly well..  I also see a lot of elements of Delphi’s innovated IDE in other IDE’s out there.. (*cough*Eclipse*cough*)

So my thought is.. How useful would that be for javascript?  This fits in nicely with a project I’m doing at work in that some of the same concepts are there..    You have a framework in the background that all this rests on (lets call it a desktop), then on top of that you have delphi like “forms” (lets call them viewlets) which are nothing more than a window framework container.  Each viewlet would have components that would be pulled from a common component library that you have positioned how you see fit and now have working how you want.

With jQuery it would be fairly simple to allow for any kind of function definitions; from onclicks to mouseovers.. Custom code would be simple and all of that could easily be serialized into a simple object definition that would be easy to store remotely..

You would need a “component inspector” like object that allowed you to edit and change things within a viewlet but once that’s done you simply disable the component inspector and you’re off to the races..

There are a lot of good javascript frameworks but they all come at this problem from the other direction.. More over there aren’t any drag and drop Delphi like application creation tools out there for javascript and certainly not any written entirely in javascript..

For work I am creating a whole new system and I was thinking of how I could keep it easy enough that third party developers could design and create their own viewlets for our system.. That’s when this whole thing plonked itself into my head..   If you designed it from the onset to be a system that could be entirely dynamically done then it would take very little programming on the part of the third party creator to get something new.. They don’t even need to know the framework because they could simply drag and drop the components they want onto a form (I have a hard time calling it a viewlet) then you’d have drop down boxes in the component inspector to attach information to that component..

At that point its just a matter of making your components sophisticated enough to provide the functionality you want..  The other nice thing is your shop goes from being application developers to simply being component developers..  If the framework works, you simply need to continue to develop better and better components..  You aren’t rewriting the wheel each time you want to make a change..

There would need to be some back end code in place to handle the storage of user generated forms, but all HTML, CSS, JPGS, and Components as well as the window framework and desktop are already written.  They don’t change. 

From a support standpoint it would be nice to give your support folks a way to pop-up some kind of component inspector widget that would allow you to browse components and forms on the fly.. etc.. 

I dunno.. its one of those things I was pondering.. I know I wont be allowed to do this for work but it amuses me..

You can see my progress here:

http://info.rsow.com/projects/fffredesign/

I’ve run into some interesting javascript foibles that I have had to deal with and have also taken this opportunity to start on my own javascript toolbox.

Every artist has his favorite paintbrush or pens, every carpenter his favorite hammer, and every plumber his favorite ass crack pants.. I’m using this project to develop my own javascript toolkits. For now they are largely unfinished and designed to be used for .. well this project.. but it is a start..

With regards to the theme, I’m working specifically on getting the colorchooser to work. Right now it doesn’t choose colors, and I only got the slider/picker cursors to work today. But only on clicks, you can’t drag them yet.

I’m hoping to have it work better than the Chromatophore stuff, and so far the one thing that works better (in my opinion) is the way the chooser slides out. Firstly from a purely javascript profiling stand point I win hands down;

The Chromatophore theme makes 454 javascript calls to “slide” their colorchooser down, where as my version only makes 88 calls.. 454 man! I have no idea what they are doing of course because they obfuscate their code and I don’t feel like eval’ing it out and running tidy to figure it out..

My color chooser will also be fixed once down so you can scroll around the page and have the color chooser open to see how your changes work live on the page, instead of having a mini-preview — right now this isn’t the case but it will be.

I’m still very excited about this and working on it.. but this is taking time.

My stance on it is simple; Don’t do it — If you ever catch me encoding or obfuscating my javascript, come kick me square in the jimmy.. I simply cannot abide by people who think they need be secretive with javascript.. And lets be completely honest here, that’s what it’s about.

Some folks will try to sling a steaming pile by saying it’s to shrink the file size for bandwidth purposes, but that’s crap — most .jpgs on this site are larger than its javascript. Most servers gzip everything before sending it to the client anyway so any file size benefits gained by obfuscation is nearly nil — unless you’ve written war and peace in the comments of the file.

Javascript obfuscation is purely about power — People who think they are smart and have done something they want to be noted for obfuscate their code to play the pointless and asinine game of “knowledge is power”. They yammer on about how they don’t want anyone to “steal it” — which is again a steaming pile of shash..

Obfuscation is at best like a padlock on a door — “it keeps the honest people honest” as my father would say.. if someone wants it their gonna take it.. More over, javascript on some webpage SHOULD be free and open..

Most of these folks fail to realize that they themselves wouldn’t be able to write the code in the first place if there wasn’t a “view source” button. Myself included — And now you’ve written something you think is so awesome and innovative you need to hide it?! Douche..

By obfuscating all you’re doing is refusing to give back to the community and saying “fuck you” to the very system that trained you to begin with. You are stifling innovation in the industry, screwing over the little guy who doesn’t know as much, and making yourself look like an ass and generally speaking you should hang your head.

All of us are the modern day equivalent to shade tree mechanics.. You wanna know how something works? Look under the hood.. That’s the beauty of the system we use.. There are no secrets, and there shouldn’t be..

Stop it.

Basically if you had any more than 10 items (or however many you have your WP set up to display in the admin area) they just wouldn’t show up. There was no way to page back through those archives. This is lame, and I’m fixing it.

I have no idea if this is an issue with other WordPress Themes, but it certainly was with this one. This fix will happen mostly through a very simple use of Ajax. The main reason is that there is no way to easily pass this information to the PHP with an HTTP/GET that satisfies all problems. AND, do it in such a way as to not have to edit the core code of wordpress.

Thus, a very simple ajax object will now live in the theme to facilitate this change. Soon when you go to an archive you will see an enumeration at the top and bottom of the listing similar to any other pagination system.

Eg: << < 5 6 7 8 > >>

Each page will display a fixed number of items.. I’ll see if I can pull that out of the config for wordpress but I may just default to 10 or something..

Most of the ajax code and server side code is in place to handle the call, however right now the JS object doesn’t know what to do with the response.

Also, I have fixed the template to correctly use engine logic as opposed to cheating and grabbing information directly from the URL. This means that no matter what your permalink structure, it will correctly know where you are and what you want to display.

EDIT: After looking at the other templates it seems the “correct” way to do this is to use the “next_posts_link” and “previous_posts_link” which will correctly set the HTTP/GET depending on your permalink structure.. However, I still like the pagination system so I’m going to go ahead and move forward with that. 

I am going to dig a little deeper into the default and classic themes that come with WP just to get a better idea how things should have been done.  So if you show up and suddenly the site is in “classic” or “default” theme then that’s why.

I’m also going to explore ways of making a real time theme switcher and more themes..

But by god I can say it here… IE7′s javascript engine is complete shit. They need to scrap it completely and start over. Firstly, It’s sloooowww.. IE7′s JS is slower than IE6.. which I find to be impressive as IE6 was slow as hell..

In one of my current projects we have a bunch of objects being cloned in real time to make a popup menu. It pops up over all other divs and what not from a nested element to a child element of the body. It’s a very simple procedure;

Mouse over the icon – pop goes the menu.

We are attaching the event to fire the pop dynamically.. (Don’t even get me started on the “attachEvent” command.. Can we please use addEventListener like everyone else.. ) When the even fires it is sent to a function which does the work.

All other browsers know that “this” in that function is the sender.. Not IE. IE expressly requires you to define the sender through the function handle and then call “sender.fromElement” to get the sender. That’s retarded. Oh but the good times don’t stop there.. No no..

See it takes time to figure out who the sender is, and it will report the sender as whatever is below the mouse when it finally gets around to it. So the fromElement could be fricken anything! Its the most unreliable crap on the planet.

Thank you very much Microsoft for this wonderful piece of crap browser. You’re an inspiration to us all.

Hacks such as:

• html > body {element}
• * html {element}
• head:first-child + body {element}
• head + body {element}
• body > {element}

Or even those that worked inside of the element definition like;

• _{property}:value

Which was actually ignored by all other browsers but Internet Explorer.

The issue is, most of these hacks have been fixed in IE7 and thus that specific IE formatting will not be applied in 7.  Which is great if the rendering quirk your hack was designed to get around had been fixed.  

The issue I’m having is that I am still seeing quite a lot of CSS tom-foolery in IE7.  Things don’t render 100% the way they should, sure its leaps and bounds better than previous flavors of IE, and I’m glad that they are finally getting around to actually listening to a spec, but still.. stuff doesn’t always work 100% the way it should and that is why those hacks were handy. 

MS didn’t seem to care about most customer complains with regards to the way CSS was implemented in previous versions of IE, and developers got used to dealing with it in a certain way, now they want us to abandon those ways too.  They have taken away the one nice way we could “fix” stuff in the CSS file.  Instead they want us to use the conditional comments crap.. which I personally don’t like and forces you to have multiple files for inclusion or forces you to have completely seperate style blocks.

The thing is, NOW because IE7 wont play nice you have to not only remove your hacks for all flavors of IE, but you also have to divide up all former versions of IE into their own files;

< !--[if lte IE 7 ] > .. Load the IE7 file .. < ![endif]-- >
< !--[if lte IE 6 ] > .. Load the IE6 file .. < ![endif]-- >
< !--[if lte IE 5.5 ] > .. Load the IE5.5 file .. < ![endif]-->

This sucks.  I want a CSS solution – and I’m going to hold my breath until I get one!

Okay maybe not.. But a CSS solution would be nice.. 

Also, comments from me will now have a CSS class applied to their parent object so that they can have their own color.  This will allow users to see comments from me more easily.. not that my comments are worth a damn.. but there ya go.