Generating and Validating Web Forms With PEAR HTML_QuickForm

Generating and Validating Web Forms With PEAR HTML_QuickForm: „This article will introduce you to one of PEAR’s most powerful tools for generating Web forms and validating the input that arrives through them: the HTML_QuickForm package. This package provides a flexible, reusable library of methods that can literally save you hours of time when dealing with form-based user input – and best of all, it’s free and extremely easy to use.

(Via Zend Developer Zone.)

YUI 2.3.0: Six New Components and a Prettier Face

YUI 2.3.0: Six New Components and a Prettier Face: „

YUI 2.3.0 is now available as a download from SourceForge.We’re pleased to announce today the release of YUI version 2.3.0. This release features six new additions to the library as well as a new skinning architecture and a new visual treatment for most of our UI controls. All of this, plus 250 enhancements and bug fixes, is available for download immediately.

Here’s what’s new to YUI in version 2.3.0:

  1. Rich Text Editor (beta): YUI developer Dav Glass brings you the new YUI RTE, featuring rich-text editing with robust A-Grade browser support. Cross-browser support has always been a major challenge for RTEs, and we think you’ll be impressed with how well this editor works across the various environments. You can instantiate it with just a few lines of code for simple implementations, and when you need to go beyond the ordinary it’s easy to extend the RTE’s Toolbar with your own custom buttons.
    Try out the YUI RTE with a custom Flickr photo extension.
  2. Base CSS: Nate Koechley continues to extend and refine the YUI CSS foundation, which now includes four members — Reset CSS neutralizes browser CSS treatments; the new Base CSS applies some consistent and common style treatments that many developers use as a foundation; Fonts CSS provides a foundation for typography; and Grids CSS delivers CSS-driven wireframes for thousands of potential page designs.
  3. YUILoader Utility (beta): YUI’s most prolific author Adam Moore has contributed the new YUILoader Utility, a mechanism for loading YUI components (and/or your own custom components) on the page via client-side script. YUILoader knows all about YUI’s dependency tree and introduces into the page only those files that are needed to support your desired components. It can load files from Yahoo! servers or from your own hosted location.
  4. ImageLoader Utility (experimental): Yahoo! Travel engineer Matt Mlinac authored the new YUI ImageLoader Utility, which allows you to defer the loading of some images to speed initial rendering time on your pages. If you suspect that you’re serving a lot of images that are never actually seen by your users, you’ll want to check out Matt’s work on this clever utility.
  5. Color Picker Control (beta): Adam Moore built the new YUI Color Picker Control on top of his own Slider Control. The Color Picker provides a powerful UI widget for color selection, featuring HSV, RGB, and Hex input/output and a web-safe color-selection swatch.
  6. YUI Test Utility (beta): Nicholas C. Zakas, who works on My Yahoo! when he’s not writing books or blogging on YUIBlog, authored our new YUI Test Utility. YUI Test introduces a flexible unit-testing framework for the YUI ecosystem and serves as the foundation for our own unit-test battery.

YUI Shows Some Skin

The new YUI Sam Skin.YUI components have always been receptive to implementation-specific styling, but with 2.3.0 we’ve moved to a more formal skinning approach that helps to separate core CSS definitions from purely presentational ones. YUI’s support for skinning makes it easier for you to implement your own design on top of, say, the TabView Control — and it makes it easier to share that skin with others in the community.

In concert with that effort, Yahoo! designer Sam Lind pitched in over the past several months to help us create an attractive, consistent visual treatment for the many UI controls in YUI that ship with a default look-and-feel. This baseline skin is much more stylish than what we’ve shipped in the past; many thanks to Sam for his hard work. In his honor, we’re calling this debut visual treatment the ‚Sam Skin‘. Hopefully this will be just the first of many YUI skins that evolve within the developer community as time goes on.

More To Come

The YUI Team will have more to say over the coming weeks about what’s new in 2.3.0, including in-depth looks at the Rich Text Editor, the skinning approach, other new components, and Jenny Han’s significantly upgraded DataTable Control. In the meantime, George Puckett from the YUI team has posted a detailed release manifest to our forums and there are release notes accompanying every component (available on the website and as part of the download).

We’ve been working hard on YUI since the last release and we’re excited to share this work with everyone today. Please check out the new version and let us know what you think.

(Via Yahoo! User Interface Blog.)

Some Notes on the YUI Rich Text Editor

Some Notes on the YUI Rich Text Editor: „

The YUI Rich Text Editor

About a year ago I made a Rich Text Editor (RTE) prototype to show that it was possible to build one on top of YUI. Of all my YUI examples, it quickly became one of the most requested, and the project indirectly resulted in me joining the YUI team in a formal capacity.

Once I started on the YUI team, building a full-featured YUI Rich Text Editor became my top priority. Even though there are many DHTML-based RTEs available in the open-source world, including Moxiecode’s excellent TinyMCE, there were four key reasons I took on the challenge of building a new one for YUI.

  • A-Grade browser support – Most available RTEs fail to support the full spectrum of A-Grade web browsers. Most support IE and Firefox well, but few support Opera and I’m not aware of any that fully support Safari. For example, many existing RTEs don’t offer list editing in Safari. I thought we could do better. Because YUI is committed to A-Grade browser support (and because I’m a fanatic Mac user) fully supporting Safari was a top priority for me. Wrestling Safari into submission was no small task, and I’ll look at some of the specific challenges below.
  • Extensibility – I wanted to build an editor that would allow fellow developers to add their own unique functionality. The YUI Rich Text Editor’s Toolbar is designed from the ground up to be extensible; the Flickr example is meant to illustrate this, as is the example of the Calendar Control implementation.
  • Accessibility – What happens when users employing assistive technologies are presented with a rich-text-editing interface? What should happen? I spent time working with Yahoo! accessibility specialist Victor Tsaran to answer those questions. I believe that I have engineered some of the answers into the YUI Rich Text Editor. This is an area of ongoing development, and I’ll share more details as the RTE progresses out of Beta status.
  • Footprint and Performance – I wanted to build an RTE that was small and fast. It’s already lighter-weight than some, but let’s be clear: It is not there yet. You can count on the fact that I’ll be putting a lot of effort into shrinking its footprint and improving its performance, while maintaining (and improving) consistency across the A-Grade browsers.

Current and Future Status

Before I get into the fundamentals of the YUI RTE, let me give you an update on the state of the project. First, this editor is currently a Beta control, and as such there is still much work to be done. Second, it’s neither a site editor nor a development environment. It’s designed for simple things like web mail systems, blog posts and comments, online reviews, and so forth. However, I did try to expose as many hooks and events as possible so that others could build upon the basic A-grade browser foundation that the RTE provides.

The Development Path

My development approach was to bend Safari first. I built it to work in Safari 2 before retrofitting it back to Opera, then Firefox and lastly Internet Explorer. I figured that if I could make Safari do what I wanted, the other three would fall into place nicely. And they did. By choosing to make Safari work first I was able to make the others do things in a standard way as well. I hope that Safari will eventually catch up to its A-grade peers and add support for the things that I have ‘emulated’, so I took that into consideration too.

Hacking Around Safari

Safari 2 is a really good browser, but it was also the most challenging browser to support with the RTE project. It lacks some serious and critical features when it comes to editing HTML content from JavaScript. I will try to explain the main hurdles that Safari presents:

Iframe Focus – One of the biggest issues was actually quite simple to solve. Safari (and Internet Explorer) has an issue with selecting text inside of an embedded iframe. If you select text within the editor’s iframe then click/focus the parent document, the selection within the iframe is lost. Clearly, this makes it rather difficult for a button click to take action on the selection (because the selection is lost when you click the button!). It also makes it difficult to use, say, a YUI Menu Control for a drop down. As I investigated this problem, I determined that if you stop the mousedown event on the button/href the selection doesn’t get lost. However, if something else (say a href in a dropdown menu) gets focus, the selection will still get lost. This leads me to the next Safari trick.

Selection Object – The selection object in Safari is very limited (to say the least). To work around its limitations, the YUI RTE caches a copy of the current selection in the _getSelection method. Then, the next time _getSelection is called I check to see if a cache existed. If the cache is there, I ‘rebuild’ the selection and destroy the cached copy. This little trick is what lets Safari use a YUI Overlay as a menu instead of the more classic approach of a select element. It’s roundabout, but it works.

execCommand limitations – This is the mother of all hacks for Safari (and the others). My biggest problem with the native execCommand method (in all browsers) is that the browser doesn’t tell you what it applied the command to. So there is no real way to get an element reference back after running a command on a selection. The world of JavaScript editors would be so much more civilized if this would happen (hint, hint, nudge, nudge). So what I had to do was implement this feature myself. My current approach may not be the best way to do it (I have some other ideas that I am working through), but it does the job for now. The method is named _createCurrentElement and basically it runs execCommand('fontname', false, 'yui-tmp'); on the given selection (since fontname is supported on all A-Grade browsers). It will then search the document for an element with the font-family/name set to yui-tmp and replace that with a span that has other information in it (attributes about the element that we wanted to create), then it will add the new span to the this.currentElement array, so we now have element references to the elements that were just modified. At this point we can use standard DOM manipulation to change them as we see fit. In short, I’m using the iframe’s DOM to store metadata during editing as a way to enrich the communication that’s possible between the editor and the iframe.

Making it Your Way

Over the past few years I’ve implemented many of the available RTEs. Because of this I brought a ‘taste of your own medicine’ mentality to the table. I wanted to build an editor that was easy to extend and change. The YUI RTE has Custom Events for everything that I could think of! I made all of the event handlers standalone functions that can be overloaded on the instance or on the prototype. I also tried to make as many things configurable as possible.

Just to give you an idea, let me show you a quick way to change one of the editor’s default behaviors.

Editing links in the YUI RTE.

The Create Link Dialog – Say you want to use a different input utility for link creation (a pre-defined links list maybe?) instead of the default link editor. Well, here’s some sample code to turn it into a JavaScript prompt:

var oEditor = new YAHOO.widget.Editor('demo');
oEditor._handleCreateLinkClick = function() {
    oEditor.on('afterExecCommand', function() {
        var str = prompt('URL: ', 'link');
        var el = this.currentElement[0].setAttribute('href', str);
    }, oEditor, this);
};

Using this technique, you could easily write your own property editor. By the way, the ‘insert image’ dialog can be overridden in exactly the same way (for example to make it a photo picker), just override the _handleInsertImageClick method. You could either override it as above, or you could override all editor instances (so every editor on the page would behave the same) like this:

YAHOO.widget.Editor.prototype._handleCreateLinkClick = function() {
};

The Look and Feel

If you don’t like the visual design of the RTE, simply change the CSS. As with YUI’s entire family of controls, the visual presentation of the control is written in CSS and can be reskinned to suit your implementation. See the RTE’s skinning example for more information on how CSS controls the presentation of the RTE specifically. We’ve even provided the Photoshop source file for the icons to make it easier for you to create a design that’s customized for your site. Maybe you like the colors, but you don’t want to see the labels above the ‘groups’? Well, add these few lines of CSS:

.yui-skin-sam .yui-toolbar-container .yui-toolbar-group h3 {
	display: none;
}
.yui-skin-sam .yui-toolbar-container .yui-toolbar-group {
	margin-top: .75em;
}

Once you dig in, I think you will find that the YUI RTE is pretty flexible and easy to extend.

In the End

Safari was tough, but I’m stubborn. When Safari properly supports execCommand, things will be even better. YUI’s RTE is exceptionally extensible and customizable; from very low-level functionality all the way up through the visual layer. It’s also semi-lightweight, and will be even lighter before I’m done with it.

I hope you enjoy my first YUI control. Please keep the feedback coming.

(Via Yahoo! User Interface Blog.)

Schnellere Websites mit Firebug und YSlow

Mit YSlow ist eine Firefox-Extension erschienen, die den Ladeprozess von Webseiten analysiert und so möglichen Performancebremsen auf den Grund geht.

Bei der von Yahoo veröffentlichten Software handelt es sich um eine Erweiterung der für Webdesigner unumgänglichen Extension Firebug. YSlow liefert Informationen über Ladezeiten einzelner Elemente wie Bilder, CSS- und JavaScript-Dateien sowie die Anzahl der zum Aufbau der Seite nötigen Requests – auf Wunsch auch unter Berücksichtigung des Cache.

Basierend auf den Ergebnissen wird die Seite nach verschiedenen Kriterien bewertet, so dass sofort zu erkennen ist, wo ihre Schwächen liegen. Dieses Prinzip ist bereits von Online-Tools wie dem Web Page Analyzer von WebsiteOptimization.com bekannt und stellt besonders für unerfahrene Nutzer eine große Hilfe dar.

(Via t3n.yeebase.com.)

Angriffswelle gegen Webserver (”iFrame-Attacken”) – nun auch TYPO3

Angriffswelle gegen Webserver (”iFrame-Attacken”) – nun auch TYPO3: „Schon seit einiger Zeit wird von wiederkehrenden Angriffen auf Webserver berichtet, so etwa in den Pressemeldungen “Groß angelegter Angriff auf Web-Anwender im Gange”, “Weitere Details zu Web-Attack-Toolkit MPack” “Schneeball-Effekt: nur ein anfälliges PHP-Script genügt” und vielen anderen Quellen. In diesen Angriffen werden – zumindest teilweise automatisiert – verschiedene Wege ausgenutzt, um Kontrolle über die Webserver zu erlangen.

Dies hat nun auch TYPO3 (und andere CMS-Systeme) erreicht: Einige Berichte zu solchen Vorkommnissen waren in Foren zu lesen, andere wurden diskret dem TYPO3 Security Team gemeldet. In diesem Artikel möchte ich vorstellen, was davon von allgemeinem Interesse ist.“

(Via TYPO3 Security Blog.)

Yet another one more thing… a new Web Inspector!

Yet another one more thing… a new Web Inspector!:

„As some of you saw last week at WWDC, we have a brand new version of the Web Inspector. We know that a lot people have found the current Web Inspector useful, and we have gotten a lot of feedback and sugestions about how to make it even better. And boy have we been listening! We have taken the current Web Inspector and have added a bunch of new features that you will find invaluable for web development:

  • Completely redesigned interface, no longer a transparent panel
  • Works with any WebView inside third-party applications, not just Safari
  • Supports docking to the inspected page
  • Shows all resources included by the page, sorted into categories
  • Global search through all text-based resources
  • Console to show errors and warnings with live JavaScript evaluation
  • Network panel showing resource load timeline along with HTTP request and response headers
  • Resource size and load time summary graph in the Network panel
  • Syntax highlighted HTML source
  • Inline JavaScript and HTML error reporting

We will be telling you in more detail about all of the great new features in future blog posts.

We have been working on this for a long time, but now we want to get the whole WebKit community involved with making this the best web development tool available. So show up in #webkit or on the mailing list and suggest new ideas or implement them yourself (remember everything is HTML, JavaScript and CSS)!

And there is one more thing… all of this new inspector goodness also works on Windows.

The new inspector is available in the Mac and Windows nightly builds.

New Web Inspector

(Via Surfin‘ Safari.)