P4A 3 starts roaring

Back from the weekend in Dublin it’s time to write an update on my nightly coding sessions on P4A 3.

Well, a bunch of things were already done, porting to Zend Framework seems to be easier than what I expected, I’m working hard (you know time is always low) and I still have many many things to do but things start working and this is really exciting.

Here you have a changelog of what I did in the past weeks:

– Zend Framework 1.0.3 was added
– Database connection now relies on Zend_DB PDO adapters
– check_configuration.php was ported to Zend_DB to check the database connection
– P4A_DB_Source was ported to Zend_DB (not completely done and tested, check the TODO list)
– P4A_DB_Source::setFields() syntax was changed, now you must provide only fields from the main table and not from joines ones
– P4A_DB_Source::addJoin() syntax was changed, join type param was dropped and now you have a third param to pass the columns you want to extract from the joined table (default extracts all columns)
– P4A_DB_Source now has many methods to add joins: addJoinCross(), addJoinFull(), addJoinInner(), addJoinLeft(), addJoinNatural(), addJoinRight()
– P4A_I18N does not manage charset anymore, only UTF-8 will be supported from now on
– P4A_I18N numbers format/normalization now relies on Zend_Locale
– P4A_I18N dates format/normalization now relies on Zend_Date and Zend_Locale
– P4A_I18N::getCountry() was renamed to getRegion()
– P4A_I18N::autoFormat() was renamed to format()
– P4A_I18N::autoUnFormat() was renamed to format()
– P4A_Number format/normalization class was removed
– P4A_Date format/normalization class was removed
– all P4A i18n format definition files were removed
– translation messages files were reorganized and renamed
– days and months translations were removed from translation messages files (now they’re provided by Zend_Locale)
– yes/no translations were removed from translation messages files (now they’re provided by Zend_Locale)
– boolean normalization works much better now (eg for italian language: it detects “sì” or “si” or “s” without case difference and the same engine works for every language)

and a TODO list of what I need to keep in my mind:

– “time” format/normalize
– “currency” format/normalize
– move translations to Zend_Translate (in progress)
– check db_source with multivalues
– check db_source for aliases
– make ui.datepicker.js work with our date format definitions
– rename constructors to __construct

Many of you would like to know what we’ll do with the graphic layer… actually we’ve decided to stop experiments on extjs and other javascript frameworks, they’ve been too time-consuming and we found bugs and limitations thus, at the moment, we’re keeping the old rendering layer. Being real, I think that P4A 3 will still generate the HTML markup but we’ll rewrite the CSS from scratch without relying on javascript frameworks that seem to not fit our needs.

Stay tuned! ;-)

3 thoughts on “P4A 3 starts roaring

  1. Pingback: P4A 3 continues growing « Fabrizio Balliano

  2. Mr. Mechano

    About this feature.

    – P4A_I18N does not manage charset anymore, only UTF-8 will be supported from now on

    What about if the data on database has different charset and/or collation?
    Does p4a execute translation between the web representation and the database’s data?

    Sincerely.
    Roberto (Mr. Mechano)

  3. Fabrizio Balliano

    @Mr. Mechano: databases can easily be converted to utf-8, we can’t continue supporting something like mysql 3 cause we’ve not enough resources to do that. anyway having different charsets it’s not possible because you should convert p4a translation files from utf-8 to your charset before using a non-utf8 encoded database. this is something i wouldn’t suggest to no one. another thing is that p4a 2 has charset support but no one uses that and it’s actually unsupported so… the best thing you can do is provide supported features, everyone should migrate to uft-8 because that’s the future and it’s just a matter of an iconv line of code :-)

Leave a Reply

Your email address will not be published. Required fields are marked *