Das TYPO3 Team hat die Core-Dokumentationen für Version 4.2 aktualisiert.
Die PDFs dazu habe ich wie immer im Dokumentationsverzeichnis abgelegt: http://doc.dev.mehrwert.de/TYPO3/4.2.x/. Die Originale wie immer im Unterverzeichnise OpenOffice.
Die mehrwelt
PHP
Das TYPO3 Team hat die Core-Dokumentationen für Version 4.2 aktualisiert.
Die PDFs dazu habe ich wie immer im Dokumentationsverzeichnis abgelegt: http://doc.dev.mehrwert.de/TYPO3/4.2.x/. Die Originale wie immer im Unterverzeichnise OpenOffice.
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.
SitePoint hat im Blog einen leidlich interessanten Artikel zur Aufteilung der E-Mail-Programme auf Anwenderseite veröffentlicht.
»There are lots of reasons for hating HTML Email, but perhaps no#1 on most people’s hit list is having to produce HTML Email to deliver to potentially hundreds of different mail clients and configurations.
Now, clearly it’s completely impractical to test your work on hundreds of mail rigs, but the question is, where do you draw the line? Generic browser usage statistics are reasonably common, but mail clients stats?«
Zur Verwendung haben sie auch eine Tortengrafik eingebunden, allerdings irgendwie unvollständig bezeichnet.
In der Zusammenfassung allerdings schon interessant: Mit zwei Webmailern, nämlich Yahoo! und Hotmail, und dem Desktop-Client MS Outlook, verteilen sich auf nur drei E-Mail-Anwendungen mehr als 81% der Anwender. Andere (allen voran Apple Mail und Gmail mit je 4%) sind eher unter »ferner liefen« zu verbuchen.
(Via SitePoint Blogs.)
Im Google Webmaster Central Blog wird diskutiert, wie man als Webmaster – oder Entwickler – mit dynamischen und statischen URLs umgehen kann (und soll). Ein interessanter Artikel, der an einer Stelle sinngemäß schlicht rät, die URLs um alle unnötigen Parameter zu bereinigen und »doch Google den Rest erledigen zu lassen«. (Aber welcher SEO-Spezialist und Entwickler kann das – bei seiner Ehre – schon…)
Abgesehen davon ist ein Absatz wesentlich:
»Which can Googlebot read better, static or dynamic URLs?
We’ve come across many webmasters who, like our friend, believed that static or static-looking URLs were an advantage for indexing and ranking their sites. This is based on the presumption that search engines have issues with crawling and analyzing URLs that include session IDs or source trackers. However, as a matter of fact, we at Google have made some progress in both areas. While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking. Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static.«
Timothy Hatcher writes:
„Web Inspector Redesign: It has been nine months since our last Web Inspector update and we have a lot of cool things to talk about. If you diligently use the Web Inspector in nightly builds, you might have seen some of these improvements, while other subtle changes might have gone unnoticed.
Some of the Web Inspector improvements were contributed by members of the WebKit community. We really want to get the whole community involved with making this the best web development tool available. Remember, most of the Web Inspector is written in HTML, JavaScript, and CSS, so it’s easy to get started making changes and improvements.
First and foremost, the Web Inspector is now sporting a new design that organizes information into task-oriented groups — represented by icons in the toolbar. The toolbar items (Elements, Resources, Scripts, Profiles and Databases) are named after the fundamental items you will work with inside the respective panels.
The Console is now accessible from any panel. Unlike the other panels, the Console is not just used for one task — it might be used while inspecting the DOM, debugging JavaScript or analyzing HTML parse errors. The Console toggle button is found in the status bar, causing it to animate in and out from the bottom of the Web Inspector. The Console can also be toggled by the Escape key.
Error and warning counts are now shown in the bottom right corner of the status bar. Clicking on these will also open the Console.
In addition to the visual changes to the Console, we have also greatly improved usability by adding auto-completion and tab-completion. As you type expressions, property names will automatically be suggested. If there are multiple properties with the same prefix, pressing the Tab key will cycle through them. Pressing the Right arrow key will accept the current suggestion. The current suggestion will also be accepted when pressing the Tab key if there is only one matched property.
Our compatibility with Firebug’s command line and window.console APIs has also been greatly improved by Keishi Hattori (服部慶士), a student at The University of Tokyo (東京大学) who tackled this area as a summer project.
The Elements panel is largely the same as the previous DOM view — at least visually. Under the hood we have made number of changes and unified everything into one DOM tree.
The Resources panel is a supercharged version of the previous Network panel. It has a similar looking timeline waterfall, but a lot has been done to make it even more useful.
The previous standalone Drosera JavaScript debugger has been replaced with a new JavaScript debugger integrated into the Web Inspector. The new integrated JavaScript debugger is much faster than Drosera, and should be much more convenient.
From the Scripts panel you can see all the script resources that are part of the inspected page. Clicking in the line gutter of the script will set a breakpoint for that line of code. There are the standard controls to pause, resume and step through the code. While paused you will see the current call stack and in-scope variables in the right-hand sidebar.
The Web inspector has a unique feature regarding in-scope variables: it shows closures, ‘with’ statements, and event-related scope objects separately. This gives you a clearer picture of where your variables are coming from and why things might be breaking (or even working correctly by accident).
The brand new JavaScript Profiler in the Profiles panel helps you identify where execution time is spent in your page’s JavaScript functions. The sidebar on the left lists all the recorded profiles and a tree view on the right shows the information gathered for the selected profile. Profiles that have the same name are grouped as sequential runs under a collapsible item in the sidebar.
There are two ways to view a profile: bottom up (heavy) or top down (tree). Each view has its own advantages. The heavy view allows you to understand which functions have the most performance impact and the calling paths to those functions. The tree view gives you an overall picture of the script’s calling structure, starting at the top of the call-stack.
Below the profile are a couple of data mining controls to facilitate the dissection of profile information. The focus button (Eye symbol) will filter the profile to only show the selected function and its callers. The exclude button (X symbol) will remove the selected function from the entire profile and charge its callers with the excluded function’s total time. While any of these data mining features are active, a reload button is available that will restore the profile to its original state.
WebKit’s JavaScript profiler is fully compatible with Firebug’s console.profile() and console.profileEnd() APIs, but you can also specify a title in console.profileEnd()
to stop a specific profile if multiple profiles are being recorded. You can also record a profile using the Start/Stop Profiling button in the Profiles panel.
The Databases panel lets you interact with HTML 5 Database storage. You can examine the contents of all of the page’s open databases and execute SQL queries against them. Each database is shown in the sidebar. Expanding a database’s disclosure triangle will show the database’s tables. Selecting a database table will show you a data grid containing all the columns and rows for that table.
Selecting a database in the sidebar will show an interactive console for evaluating SQL queries. The input in this console has auto-completion and tab-completion for common SQL words and phrases along with table names for the database.
Accompanying the task-oriented reorganization, the search field in the toolbar now searches the current panel with results being highlighted in the context of the panel. Targeting the search to the current panel allows each panel to support specialized queries that are suited for the type of information being shown. The panels that support specialized queries are Elements and Profiles.
The Elements panel supports XPath and CSS selectors as queries in addition to plain text. Any search you perform will be attempted as a plain text search, a XPath query using document.evaluate()
and a CSS selector using document.querySelectorAll()
. All the search results will be highlighted in the DOM tree, with the first match being revealed and selected.
The Profiles panel supports plain text searches of the function names and resource URLs. Numeric searches are also supported that match rows in the profile’s Self, Total and Calls columns. To facilitate powerful numeric searching, there are a few operators and units that work to extend or limit your results. For example you can search for ‘> 2.5ms’ to find all the functions that took longer than 2.5 milliseconds to execute. In addition to ‘ms’, the other supported units are: ‘s’ for time in seconds and ‘%’ for percentage of time. The other supported operators are ‘< ’, ‘<=’, ‘>=’ and ‘=’. When no units are specified the Calls column is searched.
In all the panels pressing Enter in the search field or ⌘G (Ctrl+G on Windows and Linux) will reveal the next result. Pressing ⇧⌘G (Ctrl+Shift+G on Windows and Linux) will reveal the previous result. In the Resources, Scripts and Profiles panels the search will be performed on the visible view first and will automatically jump to the first result only if the visible view has a match.
All of these things are available now in the Mac and Windows nightly builds. Give them a try today, and let us know what you like (or don’t like).
If you would like to contribute, there are some really interesting tasks in the list of Web Inspector bugs and enhancements, and other contributors in the #webkit chat room are pretty much always available to provide help and advice.“
(Via Surfin‘ Safari.)
Zend Studio for Eclipse Sneak Preview: „I am very excited to announce that Zend Studio for Eclipse 6.1 has been released, and would like to share with you some of its new features.“
(Via Zend Developer Zone.)
„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: „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.)
Die Konkurrenten Firefox, Safari und Opera knapsen dem Platzhirschen unter den Windows-Browsern, dem Internet Explorer, kontinuierlich Marktanteile ab – wohl auch, weil sie wesentlich konsequenter weiterentwickelt werden. Mit Release 8 des Internet Explorers findet Microsoft aber wieder Anschluss an die erste Browser-Liga, wie die Feature-vollständige Beta 2 zeigt. Sie steht auf den Microsoft-Servern für Vista, XP und Windows Server 2003 zum Herunterladen bereit.
Vollständiger Artikel bei heise.de
T3Cast zu DEV3: Eclipse basierte FLOW3- und TYPO3-Entwicklung: „David Brühlmeier ist Robert Lemke per Skype aus einem Park in Zürich zugeschaltet. In knapp 20 Minuten zeigt Brühlmeier Robert Lemke beispielhaft, wie die von ihm im Rahmen seiner Masterarbeit geschaffene Entwicklungsumgebung DEV3 zu bedienen ist.
Gezeigt werden alle für die Arbeit notwendigen Schritte: Nach der eigentlichen Installation des Plugins wird die weitere Einrichtung gezeigt. Darüber hinaus geben Robert Lemke und David Brühlmeier einen Einblick in die Arbeit mit DEV3.
Das Projekt DEV3 verfolgt das Ziel, Entwicklern eine auf Eclipse und den PHP Development Tools (PDT) basierende Entwicklungsumgebung für TYPO3 zur Verfügung zu stellen.
Entstanden ist DEV3 aus den zuvor unabhängig gestarteten Projekten tyClipse von Sebastian Böttger und Eckhard M. Jäger sowie FLOW3DE von David Brühlmeier. Auf Anraten von TYPO3 5.0– und FLOW3-Entwicklungsleiter Robert Lemke haben sich die Projekte zur gemeinsamen Arbeit entschlossen.“