var_export bug Fatal error: Nesting level too deep - recursive dependency? [Workaround]

When doing var_export() on nested arrays/objects with recursive dependency, you'll get an error:

Fatal error: Nesting level too deep - recursive dependency? in /some/script.php on line 123

The workaround is:

ob_start();
var_dump($data);
$dataDump = ob_get_clean();

Bug report (but is incorrectly marked as Bogus): http://bugs.php.net/bug.php?id=30471

Dependency Injection in PHP vs Java

How to do Dependency Injection in PHP vs Java.

Plain PHP:

$helper_sales = new HelperSales();

Magento proprietary SPI:

// no type information!
$helper_sales = Mage::helper('sales');

Java / CDI :

@Inject
private HelperSales helperSales;

Java / get bean from Spring context :

HelperSales helperSales = appCtx.getBean(HelperSales.class);

The Java examples apply to Scala as well, of course.

Still envy PHP?

Displaying AJAX Tables in PHP vs Java EE: ZFDataGrid and PrimeFaces DataTable

While developing with PHP + Zend Framework + Doctrine I missed an easy way to display/edit data using a grid/table.

A very useful component I found is ZFDataGrid.

Here's a sample code of how to use ZFDataGrid:

    function simpleAction()

    {         //Zend_Config         $config = new Zend_Config_Ini('./application/grids/grid.ini', 'production');                 //Grid Initialization         $grid = Bvb_Grid::factory('Bvb_Grid_Deploy_Table', $config, 'id');                 //Setting grid source         $grid->setSource(new Bvb_Grid_Source_Zend_Table(new Bugs()));                 //CRUD Configuration         $form = new Bvb_Grid_Form();         $form->setAdd(true)->setEdit(true)->setDelete(true);         $grid->setForm($form);                 //Pass it to the view         $this->view->pages = $grid;         $this->render('index');     }
It looks pretty good too.

Check the ZFDataGrid Live Demo here.

However, working with data grids using JSF 2.0 and PrimeFaces felt much more natural and easier.

Here's a sample code using PrimeFaces' DataTable :

<h:form>

    <p:dataTable var="car" value="#{tableBean.lazyModel}" paginator="true" rows="10" lazy="true"
                 paginatorTemplate="{RowsPerPageDropdown} {FirstPageLink} {PreviousPageLink} {CurrentPageReport} {NextPageLink} {LastPageLink}"
                 rowsPerPageTemplate="5,10,15"
                 selection="#{tableBean.selectedCar}" selectionMode="single"
                 onRowSelectComplete="carDialog.show()" onRowSelectUpdate="display">
        <f:facet name="header">
            Displaying 100,000,000 Cars
        </f:facet>
        <p:column headerText="Model">
            <h:outputText value="#{car.model}" />
        </p:column>
        <p:column headerText="Year">
            <h:outputText value="#{car.year}" />
        </p:column>
        <p:column headerText="Manufacturer">
            <h:outputText value="#{car.manufacturer}" />
        </p:column>
        <p:column headerText="Color">
            <h:outputText value="#{car.color}" />
        </p:column>
    </p:dataTable>

    <p:dialog header="Car Detail" widgetVar="carDialog" resizable="false"
              width="200" showEffect="explode" hideEffect="explode">
        <h:panelGrid id="display" columns="2" cellpadding="4">
            <f:facet name="header">
                <p:graphicImage value="/images/cars/#{tableBean.selectedCar.manufacturer}.jpg"/>
            </f:facet>
            <h:outputText value="Model:" />
            <h:outputText value="#{tableBean.selectedCar.model}"/>

            <h:outputText value="Year:" />
            <h:outputText value="#{tableBean.selectedCar.year}"/>

            <h:outputText value="Manufacturer:" />
            <h:outputText value="#{tableBean.selectedCar.manufacturer}"/>

            <h:outputText value="Color:" />
            <h:outputText value="#{tableBean.selectedCar.color}"/>
        </h:panelGrid>
    </p:dialog>

</h:form>

The above code may look verbose, but it packs a lot of functionality and it's very easy and intuitive to customize.
When you click a row it displays a nice dialog with a picture. Furthermore, it's actually lazy loading 100,000,000 rows!! (yes, ONE HUNDRED MILLION ROWS)

Here's how it looks:

You can see for real the PrimeFaces DataTable Lazy-loading Live Demo here.

It's very easy to add lazy-loading support to DataTable:

        lazyModel = new LazyDataModel<Car>() {

/**
* Dummy implementation of loading a certain segment of data.
* In a real application, this method should load data from a datasource
*/
@Override
public List<Car> load(int first, int pageSize, String sortField, boolean sortOrder, Map<String,String> filters) {
logger.log(Level.INFO, "Loading the lazy car data between {0} and {1}", new Object[]{first, (first+pageSize)});

                //Sorting and Filtering information are not used for demo purposes just random dummy data is returned

List<Car> lazyCars = new ArrayList<Car>();
populateLazyRandomCars(lazyCars, pageSize);

return lazyCars;
}
};

        /**
         * In a real application, this number should be resolved by a projection query
         */
        lazyModel.setRowCount(100000000);

Not to disrespect PHP or ZFDataGrid in anyway (I still need to use them for some of my work), but the experience with JSF 2.0 and PrimeFaces wins hands down. I think it's more because of PrimeFaces than JSF 2.0, but they're such a powerful combo (compared to if you use PrimeFaces with JSF 1.2).

I do hope that PrimeFaces provide a utility class that implements LazyDataModel for a Hibernate/HQL or JPA/JPQL query, but for now I can live with the above.

Fix CDATA Bug on WordPress 3.0.1's WXR Export

Today I migrated one of my client's website from WordPress 3.0.1 to Drupal CMS 6.19.

I used WordPress's export function to create a WXR backup/dump file and imported it to Drupal using WordPress Import module.

Unfortunately the WXR export file is unreadable/broken because it is non well-formed.

Some investigation reveals that WordPress export doesn't escape CDATA content properly, i.e. content containing "]]>" is left unescaped.

]]>

should be escaped as

]]]]><![CDATA[>

I've reported this bug as Ticket #15203 on WordPress Trac.

I've also provided a patch as below:

diff --git a/wp-admin/includes/export.php b/wp-admin/includes/export.php
index a9e8f22..cd3a9d4 100644
--- a/wp-admin/includes/export.php
+++ b/wp-admin/includes/export.php
@@ -138,6 +138,7 @@ function export_wp( $args = array() ) {
                        $str = utf8_encode( $str );

                // $str = ent2ncr(esc_html($str));
+               $str = str_replace(']]>', ']]]]><![CDATA[>', $str);
                $str = "<![CDATA[$str" . ( ( substr( $str, -1 ) == ']' ) ? ' ' :

                return $str;

This fixed export functionality. However I think the import functionality is still affected, as it doesn't use a proper XML Parser (see WordPress Trac Ticket #7400).

With WordPress WXR fixed I can import WordPress contents to Drupal successfully.

P.S. WordPress Import module v6.x-2.1 for Drupal fails under PHP 5.3. Solution: Use the latest WordPress import module v6.x-2.x-dev.

Fix CDATA Bug on WordPress 3.0.1's WXR Export

Today I migrated one of my client's website from WordPress 3.0.1 to Drupal CMS 6.19.

I used WordPress's export function to create a WXR backup/dump file and imported it to Drupal using WordPress Import module.

Unfortunately the WXR file is unreadable because it is non well-formed.

Some investigation reveals that WordPress export doesn't escape CDATA content properly, i.e. content containing "]]>" is left unescaped.

        ]]>

should be escaped as

]]]]><![CDATA[>

I've reported this bug as Ticket #15203 on WordPress Trac.

I've also provided a patch as below:

diff --git a/wp-admin/includes/export.php b/wp-admin/includes/export.php
index a9e8f22..cd3a9d4 100644
--- a/wp-admin/includes/export.php
+++ b/wp-admin/includes/export.php
@@ -138,6 +138,7 @@ function export_wp( $args = array() ) {
                        $str = utf8_encode( $str );

                // $str = ent2ncr(esc_html($str));
+               $str = str_replace(']]>', ']]]]><![CDATA[>', $str);
                $str = "<![CDATA[$str" . ( ( substr( $str, -1 ) == ']' ) ? ' ' :

                return $str;

This fixed export functionality. However I think the import functionality is still affected, as it doesn't use a proper XML Parser (see WordPress Trac Ticket #7400).

With WordPress WXR fixed I can import WordPress contents to Drupal successfully.

P.S. WordPress Import module v6.x-2.1 for Drupal fails under PHP 5.3. Solution: Use the latest WordPress Import module v6.x-2.x-dev.

Drupal 7.0 beta 1 Released [Announcement]

Our final Drupal 7 alpha version was released about three weeks ago. Today, we're proud to announce the first beta version of Drupal 7.x for your further testing and feedback!

The jump between alpha to beta means the following:

• We think that we have resolved all critical data loss and security bugs in Drupal 7.
• We think that our APIs are now frozen enough so that contributed module and theme authors can start (or pick up again) their #D7CX pledges.
• We think that we have caught and fixed most of the problems with the upgrade path. We were able to successfully upgrade a copy of the Drupal.org database to Drupal 7.

That said, we definitely still have some bugs to shake out, and we need your help to find them! Especially new folks who haven't taken Drupal 7 for a spin yet. So please, do so, and let us know what bugs you find in the "Drupal core" issue queue (Please search incoming issues before filing).

What's new? Tons of stuff! A revamped user interface, a new admin and default core theme, image handling in core, fields (CCK!) in core, module and theme upgrades from within the browser, an automated testing framework with over 24,000 tests, improved security and scalability, revamped database, AJAX, and file systems, jQuery 1.4, jQuery UI 1.8, RDFa, and literally gazillions of other things! Please see CHANGELOG.txt for a comprehensive list of all improvements in Drupal 7.

Updating from previous versions The upgrade path from 6.x => 7.x is actually working reasonably well right now. We need people to test this like crazy! Most of the security issues in Drupal 7 have now been addressed, but the beta should still only be installed for testing and new development or working on migration from 6.x. If you are a module or theme developer, and you haven't started porting your modules and themes to 7.x yet, now is the time! Please report anything you find so that we can be sure to support your contributions.

Always make backups of your data and never do testing on your live site. This is to make sure you keep all of your information intact even if something goes wrong.

So when does 7.0 get released? The release version of Drupal 7.0 will be ready after (a) there are no more critical bugs and (b) we've had at least one release candidate (RC) without adding any more issues to the list.

When will that be? Well, it depends entirely on how many people chip in and help out! The more people help, the faster we can find and fix bugs, and the faster 7.0 gets released. The faster 7.0 gets released, the faster we can start adding new features to Drupal 8.0. So help out where you can, and let's make this the best and most solid release of Drupal yet! :)

How do I help test the beta? Start by either installing a new Drupal site or upgrading an existing one running on a previous version (see INSTALL.txt or UPGRADE.txt in the package). When setting up a new site, you can use the Development module to generate some test data (content, users, etc) to help you start testing quickly. As with everything still in development, we do not recommend running pre-releases on a live site. Also, always make sure to backup of your data before performing an upgrade or start testing.

New Drupal Users Are you completely (or relatively) new to Drupal? Or do you know just enough to be dangerous? Are you used to working with other content management systems and willing to lend your perspective in improving the way Drupal works? If so, you're a perfect candidate to help with usability testing and improving documentation! As you're going through Drupal 7, take notes on things you find difficult or confusing, and translate those notes into an issue which will show up in the issue tracker. Make sure to be as clear as possible about what the problem was and provide suggestions on how to improve it -- this makes it easier for developers to help!

You can also help by testing the D7 Install Guide and noting any mistakes on the issue for this.

Testers Do people often congratulate you on your ability to break things? Are you a creative individual who likes to experiment in unconventional ways to see what happens? Do you enjoy looking over other peoples' work and picking nits in order to make it as good as it possibly can be? If any of these apply to you, you could make a great tester! We need testers both to try out different aspects of Drupal itself, as well as take a look at the issue queue, checking bugs to see if they're valid and testing patches to verify they work properly. Read more about setting up a testing environment and applying patches.

Module and theme developers There is no better way to shake out any lingering bugs with the API and to ensure that your modules and themes will work with the new version of Drupal than to update your modules and update your themes! Make sure to file any bugs that you find! And try coding some upgrade routines to help make the process smoother for the next person!

Drupal Ninjas and Ninjas-in-training If you're adept at Drupal hacking, or are eager to learn, a great place to start is with the bug tracker or the patch queue. Even if you don't have a full solution for a problem, often even a step in the right direction can be enough for another developer to take it home! Read up on how to create patches.

Drupal interface translators The interface strings of Drupal 7.0 are mostly frozen. The days of major changes to the UI strings are over, but we still are changing texts to fix bugs or to lend clarity in the interface. Around release candidate 1, a formal "string freeze" will be declared at which point it should be safe to start translating.

Source: http://drupal.org/drupal-7.0-beta1

Relational DBMS vs Object-oriented DBMS vs Document-oriented databases issue is moot when you're already using multiple data stores!

The issue of:

1. Relational databases (RDBMS) e.g. MySQL, PostgreSQL, SQLite, JavaDB, HSQLDB... versus
2. Object-Oriented databases (OODBMS) e.g. db4o... versus
3. Document-oriented databases e.g. MongoDB, Apache CouchDB...

...is probably because many developers (including me! :) are not aware that the application is already using multiple data stores at once.

Note: Practically all data stores, except OODBMS, will require some form of roundtrip serialization, object-mapping and code generation to be conveniently usable inside an application, accessible not only via framework/library API but also via domain model objects and classes.

By the way even if you use an OODBMS, if you use features that require specific language support (e.g. Weaving traits and behaviors, like soft deletes, timestampable, nested sets) and the language (e.g. PHP, Java) doesn't support it, you'll still need to do either code generation, manual coding, or be content with dynamic proxying (say goodbye to IDE code hints!)

Why pick just one data store and debate?

A few I have in mind right now is:

1. Key-value stores.
The application INI configuration file.
Cache storage, be it file-backed, memcached-backed, or even RDBMS-backed! (you're just abstracting/implementing a key-value store on top of a relational schema).
Translation/localization data is sometimes also stored using this store.
Web application Session data also uses key-value (though it does automatic de/serialization).

2. Hierarchical data store / Object store.
XML file.
A hierarchy of folders, subfolders, and files.
In the case of Zend Frameworks's Zend_Config, also INI files.
JSON file.
YAML file.
CSS file (surprising, eh? Though it's only two levels deep.)
I think there's no such thing as an "object store". What exists is a data store that acts like an object repository, that does automatic de/serialization of objects, that stores its data in a hierarchical store or content/document store or hybrid.
How an object is serialized/its serialization representation (i.e. "should a GeoPoint instance be embedded or linked?") should be specifiable through some form of metadata/configuration/annotations.
The object graph, by itself, does not contain sufficient information to be managed as a data store.

3. Content/Document store.
A content store doesn't always restrict a type to a schema. It allows arbitrary properties to be attached to a content node.
Some content stores also allow nesting (hierarchical content stores).
The filesystem (fixed standard schema), but some filesystems support additional metadata.
The node API in Drupal (implemented on top of RDBMS).
The EAV tables in Magento (implemented on top of RDBMS).
Natively: the JCR (Java Content Repository) in Alfresco & Jackrabbit (Java), MongoDB, Apache CouchDB, Persevere.

4. Binary/BLOB store.
It's basically a key-value store with support for huge values and block/partial access.
The filesystem.
S3.

5. Structured markup.
HTML. Wiki format. Markdown. Textile.
All fits in one string.

6. Full text index store.
Apache Lucene.
Zend_Lucene.

7. Search store.
Apache Solr.
The search/faceted navigation index in Magento (built on top of RDBMS).

Did I miss something?

Diem Content Management Framework: How does it compare to Drupal?

Replying to Aviblock's article : Diem, my new CMS of choice :

I’m also very impressed when I found Diem CMF.

I’m a bit torn here, I quite like Drupal, especially due to its popularity and choice of modules.

However looking at the description of Diem it really looks like it fits my “style” as you say it. I haven’t yet worked with Symfony, I only worked with Doctrine + Zend Framework but I already liked the way things work. (and I believe Symfony is much more convenient than Zend Framework)

Drupal’s architecture leaves a lot to be desired… but de facto it’s one of the most popular CMSes nowadays (along with Joomla and WordPress), with lots of PHP developers familiar with it.

Setelah debugging 3 jam ruwet, ternyata kesalahan terletak pada bug Zend_Loader_Autoload::getClassAutoloader() ! ah, Zend Framework kauuu membuatku...

Setelah debugging 3 jam ruwet, ternyata kesalahan terletak pada bug Zend_Loader_Autoload::getClassAutoloader() !

ah, Zend Framework kauuu membuatku...

For RIA in JavaScript, GWT is the most sane option

I just tried again coding a rich web UI with:

- Dojo (and DojoX and Dijit, including dojox.data)
- Ext JS by Sencha (including the data store)
- Prototype

The conclusion is: I missed Google GWT.

JavaScript OOP is such a complex beast that pretty much you have to do it by memory: IDE's won't help much (if at all) on this.

Since a GWT app is written in Java programming language, it comes with all the goodies a good Java IDE (Eclipse) can provide, and that is excellent code completion, refactoring, and error checking support.

Other JavaScript toolkits will require an additional "minification" phase. In GWT it's part of the build process: the app is guaranteed to be small & optimized.

Java does have its limits, such as its static-ness. Projects such as DWR can generate Java stubs. But when you play by Java's rules (including autogenerating stubs) you get back the nice IDE features and sometimes easier debugging. Oh joy. :)

For non-RIA type pages though, either jQuery, Dojo Core, or Prototype rocks. (though I am biased to jQuery due to ubiquity)

Assemble Route URL inside Zend_Form

If you want to assemble a route URL inside a Zend_Form (or any other object where you don't have access to the URL View Helper), get an instance of the router and call the assemble method like this:

class Abispulsa_Deposit_Claim extends Zend_Form {

  public function init() {
    $router = Zend_Controller_Front::getInstance()->getRouter();
    $url = $router->assemble(array('module' => 'deposit', 'controller' => 'index', 'action' => 'claim'));
    $this->setAction($url)->setMethod(self::METHOD_POST);
    ...

    Hope this is useful.

Cannot write output to stream ... error on Zend_Log logger

I got a "Cannot write output to stream ..." when using Zend_Log and Zend_Log_Writer_Stream.

I have been frustrated by this problem for several long hours, and the cause is because I created a new logger instance in a local variable inside a method of a lot objects. If that sounds confusing, this is the example problem:

class Car {   public function drive() {     $logger = Zend_Log::factory(/*some config*/);     ...   } }

To solve the problem, I had to do this:

class Car {   protected static $_logger;            protected static function getLogger() {     if (!self::$_logger)       self::$_logger = Zend_Log::factory(/*some config*/);     return self::$_logger;   }   public function drive() {     $logger = self::getLogger();     ...   } }

Annoying, but that's the workaround that works. If I have the choice I definitely prefer SLF4J.