TYPO3 – Get content element from extension code
I've not wrote something from long time, so today I give you a little snippet.
If you have to use in your extension a content element from another page, you can use this function to get it from it's uid :
-
function loadContentElement($uid) {
-
-
'tables' => 'tt_content',
-
'source' => $uid,
-
'dontCheckPid' => 1,
-
);
-
-
return $this->cObj->RECORDS($conf);
-
}
Two new SDK for Bing Maps
A new test environment and development has been made available to developers for 90 days for free access to APIs Bing Maps.
This good news comes two SDKs interactive, comprehensive and very educational which are also offered by Microsoft "to learn how to utilize the APIs Bing Maps."
For the record, this web-services platform enables the development of localization features for both web applications for mobile or house.
Among the features there are of course the creation of routes, location of the advanced search or proximity search.
But these APIs can also customize the browser, integrate multimedia (videos, images and other multimedia objects to map), or to imagine new uses (see above).
Two SDK (AJAX and Silverlight SDK Interactive Interactive SDK) and five different interfaces are proposed to meet the needs closer to each developer.
The mod_python project is “officially dead”
The project consisted of a mod_python Apache module for integrating a Python interpreter, and to program web applications in Python.This was equivalent to mod_php or mod_perl (which respectively include PHP and Perl interpreter into the Apache server).
Many applications and Web frameworks written in Python mod_python support.
Graham Dumpleton explained in more detail on his blog, in a note dated May 27, the reasons for this failure (mainly: inactivity). But also, more broadly, the history and future of Python. Finally, he advises to stop using mod_python, presenting alternatives.
The mod_python project last had a release February 2007. There has more or less been no developer activity since. Under the rules of the Apache Software Foundation if a project becomes inactive then it can be moved into what is called the Apache Attic. Come the next meeting of the ASF board a proposed resolution will be put up to dissolve the Quetzalcoatl project management committee and projects which it overseas, namely mod_python. Thus, in some respect one can say that mod_python will be officially dead.
What will this really mean. Well, no more development on mod_python, but then that isn't happening now. Linux distributions will likely still carry the package, but they will need to apply any changes themselves to ensure that it continues to work for newer versions of Apache. This actually is already being done as a bug in mod_python was exposed by some changes to the Apache runtime library and since no mod_python release has been made since then, only option was for distributions to patch it themselves.
I suspect though that this patching by distributions will only extend to Apache 2.2.X as Apache 2.4 changes the internal APIs enough that getting mod_python to compile will need more significant changes than a minor patch. You also will never see a version of mod_python for Python 3.X as that is going to require a radical rewrite.
For platforms like MacOS X where the last release of mod_python doesn't build properly, the only option will be to checkout mod_python source code from the subversion repository as that incorporates a fix for those issues, although it has since been shown to not be a complete fix and so you may still have some problems. In other words, the subversion repository will still exist, but it will be made read only and the location may potentially move.
What options exist if you want to move away from mod_python?
If you are only using mod_python as a means of hosting within Apache a distinct Python web framework or application and it supports the WSGI interface, then the obvious candidate is to move to mod_wsgi instead.
If you are using mod_python to implement custom access, authentication or authorization handlers, then you may also be able to get away with using mod_wsgi. You may have to make compromises though as mod_wsgi doesn't currently allow you to write full blown Apache style handlers and instead only implements the Apache authentication and authorization provider interfaces. This actually makes it easier to do most things, but you loose the ability to do some more complicated stuff which depends on using different error status values or custom error pages. You can partly get away with using ErrorDocument directive to return custom error pages, but not always.
Although proper support for Apache style handlers could be added to mod_wsgi, and a lot of work has been done in that direction already through the implementation of SWIG bindings for Apache, whether the remaining work to allow the actual hooking of handlers into mod_wsgi will be done will really depend on interest in it. Up till now, there hasn't been sufficient interest to justify doing the final bit of work and there has actually been some resistance put up to the idea of extending mod_wsgi too far beyond the core goal of providing WSGI hosting.
If you are not using the basic handler mechanisms of mod_python and are instead using the CGI handler, the publisher handler or PSP handler, then there aren't really any options at this point except for rewriting your application on top of a WSGI framework. If you have to do such a rewrite, but like the low level that one works at when using mod_python, then would strongly recommend you perhaps look at Werkzeug andFlask.
If you are using mod_python input or output filters there simply isn't any replacement. Frankly though I always thought that writing input or output filters in mod_python was a really bad idea. Yeah it may work, but it wouldn't exactly be efficient. You would be much better writing a proper Apache module in C to do what is required, certainly if performance is an issue.
Finally, the ability to use Python code with Apache server side include mechanism also has no real equivalent. But then, not sure anyone ever actually used that feature anyway. Something similar could possibly be implemented in mod_wsgi but not sure there would really be a point. If you are only using ability to include Python code, you would be much better off using a proper templating system that works with a WSGI framework.
So, the writing is on the wall so to speak and if you are using mod_python, you really should be starting to plan how to move away from it as eventually it will likely not be an option you can use if you want to keep up to date with Apache and/or Python.
Could it yet be saved by a white knight. Well, yes it could as the Apache Attic does allow projects to be resurrected or forked with it then being maintained outside of the ASF. If someone does do the latter though, you would need to be mindful of the name as the ASF in some respects has rights over the mod_python name. As such, you would likely need to rename the project when you take it over.
If you fork mod_python, you would also want to think about capturing all the details of the significant number of still open bug reports for mod_python in its issue tracker, as am not sure what will happen to that and whether it will be made read only or whether it will be completely closed down.
Anyway, will be interesting times ahead. I should point out though that according to Google trends(currently borked), searches on WSGI finally overtook those for mod_python recently. Searches for mod_wsgi haven't yet, but not far off occuring. It is also the common belief that WSGI is the way to go for Python web applications now, so perhaps it is simply time to just move on from mod_python. If we could only just get newbies, who even now keep using mod_python even though better options exist, to understand this, then maybe it can finally be left to die in peace.
MonoDevelop 2.4 is out
The Mono project is an open source clone of. NET framework Microsoft. Its director, Miguel de Icaza has announced the arrival of his MonoDevelop Development Environment 2.4, consistent with Linux, Windows and Mac OS X. Many new features make their entry. Note the arrival of a engine and a new navigation bar and search function autocompletion.
Listed tools, MonoTouch (for developing applications for iPhones) has better support. To be fair, talking about MonoDroid (for developing applications for Android),. Due to its late onset, the tool is still in beta.
The UI has also been reviewed in depth.
Finally, side language, support for Vala has greatly improved. Vala is a programming language compiled. Its syntax is based on that of C # but it requires no runtime environment. Vala is transformed into C code, itself compiled into native machine code.
What can "produce software that requires less memory and run faster. Furthermore, the transition from step C makes it possible to use C libraries with interfaces defined in the files Vapi" (from Wikipedia).
These are just a few innovations from among the long list of improvements to the IDE.
MonoDevelop 2.4 download
Source : developpez.com
MonoDevelop website
TYPO3 4.4.0 RC1 available
Today, the TYPO3 community released the first Release Candidate of TYPO3 4.4. The final version will be released on June 22nd, 2010 as planned. Since the last 4.4 release of beta3, three weeks ago, there have been changes to Caching Framework, which got some updates from its counterpart in the TYPO3 Phoenix project, updates to the Rich Text Editor and the icons and styling of the TYPO3 Backend.
Read full post here
Download it here
