Auch Google wird OpenID Provider

Nach der Ankündigung von Microsoft hat nun auch Google nachgezogen: nur einen Tag dem Konzern aus Redmond macht Google seine Nutzer-Accounts zu einer OpenID, so dass sich alle Google-Nutzer (mit Google-Account) bei OpenID-fähigen Websites identifizieren können.

Die OpenID-Schnittstelle für TYPO3 ist mittlerweile in den Hauptentwicklungszweig übertragen worden und damit fester Bestandteil des CMS (als Systemerweiterung). Die Integration dieser Schnittstelle wurde unter anderem wegen CGL und Philosophie-Fragen in der Entwicklerliste heiß diskutiert.

[update] heise.de: Der US-amerikanische Internetdienstleister Google stellt innerhalb eines begrenzten Testbetriebs eine Programmierschnittstelle (API) für OpenID 2.0 bereit. Open ID ist ein offener Standard zur einfachen Identifizierung und Authentifizierung von Anwendern im Web. Für den Zugang zur API müssen sich Interessierte bei Google anmelden.[/update]

Microsoft wird OpenID Provider

Microsoft hat angekündigt, dass alle Windows Live accounts für OpenID freigeschaltet werden. Damit kann man sich dann mit seinem Windows Live Account (derzeit angeblich rund 420 Millionen Accounts) an OpenID-kompatiblen Websites anmelden.

Auch TYPO3 wird in der kommenden Version 4.3 über eine OpenID Schnittstelle direkt im Core verfügen (eine Erweiterung dazu gibt es schon länger). Die Integration dieser Schnittstelle wird derzeit in der Entwicklungsliste heiß diskutiert.

YAML-Template für TYPO3 jetzt unter der GPL

Seit dem 1. September 2008 stehen alle aktuellen und künftigen Versionen des YAML-Templates (basiert auf dem bekannten CSS-Baukasten YAML) unter der GPL und dürfen kostenlos und ohne Zahlung einer Lizenzgebühr auch komerziell verwendet werden.

Der Entwickler des TYPO3 Templates schreibt:

Warum dieser Schritt?
Abgesehen von den Querelen, die sich mit der Auszahlung der Einnahmen aus den Lizenzverkäufen an mich ergeben haben, habe ich dies schon seit längerer Zeit überlegt und geplant. Die Antwort ist ganz einfach. Ein freies und quelloffenes CMS wie TYPO3 lebt davon, daß soviele Entwickler wie möglich dazu beitragen, daß es besser und leistungsfähiger wird. Lizenzgebühren für ein einzelnes Modul zu verlangen, paßt nicht zum Konzept von TYPO3.

Anders als das TYPO3-Template steht YAML selbst weiterhin unter der Creative Commons Lizenz (CC-A 2.0), also die Attribution Lizenz. Das heisst, für die kostenfreie Nutzung des YAML-Frameworks ist die Rückverlinkung zur YAML-Homepage in der Fußzeile der Website oder im Impressum vorgeschrieben.

A Free JavaScript Speed Boost for Everyone!

A Free JavaScript Speed Boost for Everyone!: „An exciting development in the world of DOM scripting is the W3C Selector API. Up until now, using the DOM Level 2 API, the only way to obtain references to HTML elements in the DOM was to use either document.getElementById or document.getElementsByTagName and filter the results manually. With the rise of CSS, JavaScript programmers asked the obvious question, ‘If the browser has a really fast way of selecting HTML elements that match CSS selectors why can’t we?’.

The Selector API defines the querySelector, and querySelectorAll methods that take a CSS selector string and return the first matching element or a StaticNodeList of matching elements, respectively. The methods can be called from the document object in order to select elements from the whole document or a specific HTML element to select only from descendants of that element.

To illustrate how much easier your life will be using the Selector API, have a look at this example HTML:

<ul id='menu'>
  <li>
    <input type='checkbox' name='item1_done' id='item1_done'> 
    <label for='item1_done'>bread</label>
  </li>
  <li class='important'>
    <input type='checkbox' name='item2_done' id='item2_done'> 
    <label for='item2_done'>milk</label>
  </li>
  <!-- imagine more items -->
</ul>

Our task is to check all the checkboxes for the list items that have the class ‘important’. Using only DOM Level 2 methods we could do it this way:

var items = document.getElementById('menu').getElementsByTagName('li');
for(var i=0; i < items.length; i++) {
  if(items[i].className.match(/important/)) {
    if(items[i].firstChild.type == 'checkbox') {
      items[i].firstChild.checked = true;
    }
  }
}

Using the new selector API we can simplify it to this:

var items = document.querySelectorAll('#menu li.important input[type='checkbox']');
for(var i=0; i < items.length; i++) {
  items[i].checked = true;
}

That’s much nicer! The methods also support selector grouping — multiple selectors separated by commas. The Selector API is working right now in Safari 3.1, the Internet Explorer 8 beta, and Firefox 3.1 alpha1. Opera is also working on adding support for the API.

If you’re a fan of one of the many JavaScript libraries available you’re probably thinking ‘But, I can already do that.’ One of the great examples of the benefits of using JavaScript libraries are the implementations of CSS selectors found in nearly all of them. Recently we’ve seen huge speed improvements in the CSS selector implementations because library authors have been sharing their techniques. So what’s the benefit of using the Selector API? In a word: speed — native implementations are fast! And better yet all of the javascript libraries are poised to benefit. jQuery and Prototype are already developing implementations that make use of the Selector API, while The Dojo Toolkit, DOMAssistant and base2 have already made use of it.

There’s a reason why those 3 libraries were the first ones to benefit. Kevin talked about the potential problem back in Tech Times #190 in the article titled ‘Is Your JavaScript Library Standards Compliant?’ The Selector API makes use of standard CSS selectors so if the browser doesn’t support a certain selector then you won’t be able to use it. The libraries that have already taken advantage of the Selector API are those that only supported standard CSS selectors. For those libraries, supporting the API was (almost) as easy as doing this:

if(document.querySelector) {
  return document.querySelector(selector);
} else {
  return oldSelectorFunction(selector);
}

Libraries that support custom selectors will have more work to do. The risk is that if you have used custom CSS selectors extensively in your project, it may be difficult for your chosen library to pass on the speed benefit to you because the library will have to use its default selector instead of the Selector API. If the library somehow rewires its custom selectors so that they can utilize the Selector API, the secondary risk is increased code bloat.

Hopefully the Selector API will encourage the use of standard CSS selectors over custom ones. In fact if uptake of the new browser versions is good and the performance benefits of the new Selector API are compelling enough we could see custom selector functionality moved to supplementary libraries you only need to use in case of legacy compatibility requirements.

Dean Edwards’ base2 Library has the nicest implementation in my opinion. Base2 implements the API exactly, which means you can write your JavaScript using standard the standard API methods — Base2 only creates custom querySelector and querySelectorAll methods if the browser doesn’t support them. You can’t get any cleaner than that. Base2 does, however, implement the non-standard ‘!=’ attribute selector in it’s custom selector function, apparently because of peer pressure, so it’ll have to have points deducted for that.

Regardless of whether you use a JavaScript library or roll your own, the new browser implementations of the Selector API give everyone an instant speed boost. We all win, hooray!“

(Via SitePoint Blogs.)

Zend Framework 1.6 mit Dojo veröffentlicht

Zend Framework 1.6 mit Dojo veröffentlicht: „Die neue Version der Codebibliothek Zend Framework enthält unter anderem zwei neue, stabile Komponenten für die Integration von Dojo und SOAP, dazu kommen kleinere Ergänzungen bestehender Komponenten und Bugfixes. Das Highlight der neuen Version ist aber eine frühe Version der experimentellen Zend_Tool – Zends Antwort auf Ruby-on-Rails und CakePHP. (JavaScript, IBM)“

(Via Golem.de.)

Open-Source-Plattform für Social Networks: Elgg v1.0 startet

Open-Source-Plattform für Social Networks: Elgg v1.0 startet: „Elgg ist eine Open-Source-Social-Network-Plattform, die Blogging, Networking, Messaging, Communitys, RSS-Feeds und Filesharing miteinander verbindet. Die webbasierte Anwendung wurde auf der Grundlage von LAMP (Linux, Apache, MySQL, PHP) entwickelt.

Ein wesentlicher Bestandteil von Elgg sind die ‚Views‘. Damit werden die einzelnen Seiten für unterschiedliche Anwendungsfelder aufbereitet. Neben Standard-HTML sind beispielsweise Views für mobiles Internet, iPhone oder als eingebettetes Widget möglich.

Das Konzept von Elgg beinhaltet die Erweiterung der Plattform über Plugins. Damit diese Möglichkeit einfach und schnell umsetzbar wird, wurde das Framework von Elgg so geschrieben, dass viele Komponenten eines Plugins schon enthalten sind, wie beispielsweise ein Benachrichtigungssystem, Import/Export-Filter, Sprachanpassung und eine API.

Die Möglichkeit zum Datentransport zwischen unterschiedlichen Social Networks wurde in der nahen Vergangenheit immer wieder gefordert und von einigen Netzwerken auch schon angegangen. Elgg präsentiert in diesem Bereich mit der openData Definition (ODD) schon zum Start ein fertiges Konzept, mit dem die Nutzer in der Lage sein sollen, ihre persönlichen Daten von einem Netzwerk in ein anderes zu kopieren.

Die Social-Network-Plattform Elgg verfügt über einen hohen Funktionsumfang und ist als webbasierte Anwendung crossplattformfähig. Das vom Start weg enthaltene Konzept zur Data Portability macht Elgg zukunftssicher und hält eventuell vorhandene Einstiegshürden niedrig. Die vereinfachte Möglichkeit zur Entwicklung von Plugins sorgt zudem für eine zusätzliche Anpassungsfähigkeit der mit Elgg entwickelten Social Networks.

Heute (18.08) startet Elgg nun die finale Version 1.0. Einen ersten Eindruck kann man sich mit einer Testseite von Elgg verschaffen.“

(Via t3n.yeebase.com – Open Source, Web & TYPO3.)

A Closer Look at YUI 3.0 PR 1: Dav Glass’s Draggable Portal Example

A Closer Look at YUI 3.0 PR 1: Dav Glass’s Draggable Portal Example: „

YUI 3.0 Preview Release 1 was made available on Wednesday, and with it we provided a look at how the next major iteration of YUI is taking shape. Among the elements we shipped with the preview is a new example from Dav Glass, the Draggable Portal, which exercises a broad cross section of the preview’s contents.

The Portal Example in the YUI 3.0 preview release.

The Draggable Portal is a common design pattern in which content modules on the page can be repositioned, minimized, removed, and re-added to the page. The state of the modules persists in the background, so a reload of the page or a return to the page calls up the modules in their most recently positioned state. You see variations of this design pattern on many personlizable portals like My Yahoo, NetVibes, and iGoogle.

In this article, we’ll take a look under the hood of this example to get a richer sense of YUI’s 3.x codeline and the idioms and patterns it establishes. We’re just pulling out some specific code snippets to examine here, but you can review the full code source for this exampleand for 66 others — on the YUI 3 website.

(more…)

(Via Yahoo! User Interface Blog.)

YUI 3.0 Preview Release 1

YUI 3.0 Preview Release 1: „

YUI 3.0 Preview 1 website.The YUI team is pleased to announce the public availability of YUI 3.0 Preview Release 1, an early look at what we’re working on for the next generation of the YUI Library. Documentation for YUI 3.0 is on the YUI website; the download is available on the YUI project area on SourceForge; you can find us with questions or comments on the YUI 3.x discussion forum. Keep in mind that this is an early preview, not a production-quality (or even a beta) release. This release is not suitable for production use, but it will give you an idea of what we’re working on, and it should provide a good framework for conversation about the future of the library.

Five Goals for YUI 3:

We’ve talked to thousands of YUI users over the past 30 months, and based on that feedback we’ve set five design goals for the next generation of the library. What you’ve told us is that YUI 3.0 should be:

  • lighter (less K-weight on the wire and on the page for most uses)
  • faster (fewer http requests, less code to write and compile, more efficient code)
  • more consistent (common naming, event signatures, and widget APIs throughout the library)
  • more powerful (do more with less implementation code)
  • more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)

With this early release, we’ve made progress toward most of these objectives — and we believe we have the right architecture in place to meet all five as we move to GA over the next few quarters.

What’s New in YUI 3.0?

When you start to write code using YUI 3.0, you’ll notice some changes in structure and style. Here’s a taste:

Snippet: What it does:
YUI().use('node', function(Y) {
    Y.get('#demo').addClass('enabled');
});
Creates a YUI instance with the node module (and any dependencies) and adds the class ‚enabled‘ to the element with the id of ‚demo‘.
YUI().use('dd-drag', function(Y) {
        var dd = new Y.DD.Drag({
        node: '#demo'
    });
});
Creates an instance of YUI with basic drag functionality (a subset of the dd module), and makes the element with the id of ‚demo‘ draggable.
Y.all('.demo').addClass('enabled');
Adds the class ‚enabled‘ to the all elements with the className ‚demo‘.
Y.all('.demo').set('title', 'Ready!').removeClass('disabled');
Sets the title attribute of all elements with the className ‚demo‘ and removes the class ‚disabled‘ from each.
Y.get('#demo').plug(Y.Plugin.Drag, {
    handles: 'h2'
});
Adds the Drag plugin to the element with the id ‚demo‘, and enables all of its h2 children drag as handles.
Y.on('click', function(e) {
    e.preventDefault();
    e.target.query('em').set('innerHTML', 'clicked');
}, '#demo a');
Attaches a DOM event listener to all anchor elements that are children of the element with the id ‚demo‘. The event handler prevents the anchor from navigating and then sets a value for the innerHTML of the first em element of the clicked anchor.

What’s different here?

  • Sandboxing: Each YUI instance on the page can be self-contained, protected and limited (YUI().use()). This segregates it from other YUI instances, tailors the functionality to your specific needs, and lets different versions of YUI play nicely together.
  • Modularity: YUI 3 is architected to use smaller modular pieces, giving you fine-grained control over what functionality you put on the page. If you simply want to make something draggable, you can include the dd-drag submodule, which is a small subset of the Drag & Drop Utility.
  • Self-completing: As long as the basic YUI seed file is in place, you can make use of any functionality in the library. Tell YUI what modules you want to use, tie that to your implementation code, and YUI will bring in all necessary dependencies in a single HTTP request before executing your code.
  • Selectors: Elements are targeted using intuitive CSS selector idioms, making it easy to grab an element or a group of elements whenever you’re performing an operation.
  • Custom Events++: Custom Events are even more powerful in YUI 3.0, with support for bubbling, stopping propagation, assigning/preventing default behaviors, and more. In fact, the Custom Event engine provides a common interface for DOM and API events in YUI 3.0, creating a consistent idiom for all kinds of event-driven work.
  • Nodes and NodeLists: Element references in YUI 3.0 are mediated by Node and NodeList facades. Not only does this make implementation code more expressive (Y.Node.get('#main ul li').addClass('foo');), it makes it easier to normalize differences in browser behavior (Y.Node.get('#promo').setStyle('opacity', .5);).
  • Chaining: We’ve paid attention throughout the new architecture to the return values of methods and constructors, allowing for a more compressed chaining syntax in implementation code.

And that’s just the beginning. Dive into the examples to learn more and to see the preview release in action, including some hidden gems like full A-Grade cross-domain requests. Our resident metahacker Dav Glass created a nice multi-component example, the draggable portal, that will give you some sense of what’s included in today’s preview.

Is YUI 3.0 Backward Compatible with YUI 2.x?

No. YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.

We know that ease-of-migration will be a critical factor for all YUI users. We’re taking two important steps to facilitate the transition as it arrives:

  • Limited compatibility layer: YUI 3.0 will ship with a limited compatibility layer for the current YUI Core (Yahoo Global Object, Dom Collection, and Event Utility). This will allow you to run many of your YUI 2.x-based implementations on top of YUI 3.0. We’re not shipping the compatibility layer with today’s preview, but you’ll see it appear in a future preview or beta release prior to GA.
  • Full parallel compatibility: YUI 3.0 can be run in parallel to YUI 2.x with no side effects for either version. If you choose to make the transition in stages, you can run the full 2.x stack and 3.x stack together as needed.

Even with these provisions in place, we know that an API change (along with new concepts and idioms) has a real cost for everyone involved. We’re convinced that this change is both necessary and worth the effort, and obviously we’re going to work hard to make the value proposition compelling.

What’s Next?

YUI 3.0 is a work in progress. The common widget framework for 3.0 is not included in this preview and we’re continuing to work on refinements to the core — including optimizations to the package structure to minimize base K-weight. We anticipate the next two releases coming up as follows:

  • October 2008 — PR2: Widget Framework, sample widgets, additional utilities.
  • December 2008 — Beta 1: Final mix of module structures, API completion, full complement of utilities.

We have some great stuff to share as we move further along in this process. We’ve never been more excited about YUI and its future — and we think YUI 3.0 will have a big role to play in that future.

(Via Yahoo! User Interface Blog.)