Agavi 1.0.2 RC3 is now available for download at www.agavi.org.
This release adds support for Propel 1.4 and introduces a new way to configure connection setting overrides for Propel; see the RELEASE_NOTES for details.
A couple of bugs have also been fixed, most notably an issue where the first element of a multi-dimensional array would be lost when exported from a validator.
PHPUnit and the timezone database have been updated to their latest versions.
As always, the CHANGELOG has the full list of changes in this release.
Unless there are any nasty surprises, a final release will follow next week.
Hello everybody,
Agavi 1.0.2 RC2 is now available for download at www.agavi.org.
A couple of fixes have been made since RC1, and PHPUnit and the timezone database have been updated to their latest versions.
We’re currently planning a final release next week, after another new version of the timezone database has been released.
Enjoy your weekend,
David
The fifth and final article in the series on Agavi over at IBM developerWorks has just been published.
This last part talks about handling of file uploads, storing data in sessions and writing custom validator classes. Go read it, rate it, blog about it and spread the word!
Agavi 1.0.2 RC1 is now available for download at www.agavi.org.
This maintenance release fixes a number of issues over Agavi 1.0.1 and brings a couple of minor enhancements.
The following fixes are worth mentioning:
- AgaviArraylengthValidator didn’t work with files.
- AgaviValidationManager::clear() didn’t clear validation errors.
- Multiple settings blocks and settings prefixes were not allowed in module configs.
- AgaviNumberValidator does not mutate invalid input anymore.
- Several ICU bugfixes have been ported.
Important Changes:
- Optional strict comparison of elements in AgaviInarrayValidator now possible.
- Validator shortcut “arraylength” now defaults to minimum of one element.
- Routing callback parameters are now set before initialize method is called.
- Lots of ICU bugfix and change backports to the date and translation system. As a result, custom time zones now have identifiers like “GMT+0200”.
- Namespaced class identifiers can now be used in all configuration files.
- AgaviValidator::getArgument() now accepts an argument identifier.
- Support for PHPTAL 1.2.
Bundle updates:
- The timezone database has been updated to version 2009m.
- PHPUnit has been updated to version 3.4.0RC3.
- ISO Schematron has been updated to version 2009-05-18.
Please refer to CHANGELOG for a full list of changes.
The fourth article in the series on Agavi over at IBM developerWorks has just been published.
The new part details Agavi’s Output Types and how to quickly implement alternative response formats. Go read it, rate it, blog about it and spread the word!
More often than not I want to create a new agavi project the “standard” way, that is:
- Change the projects name
- Change the projects prefix
- Use the defaults for all other options
Calling agavi project-wizard makes me answer all questions, one by one. Sure, pressing enter at every prompt works, but I value my time too much to press enter at every prompt. I’d rather go write a blog post about how not to press enter at every prompt.
Enter “yes”
“yes” is a small commandline utility that answers “yes” or any given string to any prompt given to it:
yes '' | agavi project-wizard
will create a project with all default values. Now the only thing that needs fixing is the project name and the project prefix - we can do that on the commandline[1]:
yes '' | agavi -D project.name "My little test project" -D project.prefix "MyLTP" project-wizard
This is not faster in any way than running through the wizard, but I can do other things during that time.
[1] Please note this bug that prevents passing parameters with spaces to the build system: http://trac.agavi.org/ticket/1137
The third article in the series on Agavi over at IBM developerWorks has just been published.
This part focuses on creating an administration interface and on securing it. Go read it, rate it, blog about it and once again spread the word!
Finally a nightly pdf build of the agavi guide is available. It’s based on trunk and can be downloaded from http://www.agavi.org/documentation-nightly-pdf.tar.gz. The tarball contains the pdf version of the guide and all stage tarballs.
The current build scheme is very simple and the file is replaced every night. The location may change if and when we decide to keep older versions of the guide around. Until then: Enjoy.
Some tasks are nice to have around in each and every project, such as the JSLint task I wrote about earlier today. However, we still don’t want that in each and every project - where’s the point in having a js-lint in a project that does not use any javascript at all like a pure service oriented project without any html output? So we don’t want that task in the core agavi build file but still in our standard project.
However, using agavi project-wizard copies the standard agavi buildfile, so we have to manually copy our changes over and over again. Tedious work. We might also have a customized set of templates to use with the latest output type generation feature and we’d like to use that from the start so that all views generated in the project wizard benefit from that as well. But hmm, agavi project-wizard uses the standard templates. So let’s go change that.
A custom template set
We start off by copying the standard template set - there’s a task for it:
Zodiacal-Light:Sites fgilcher$ mkdir agavi-build-templates
Zodiacal-Light:Sites fgilcher$ cd agavi-build-templates/
Zodiacal-Light:agavi-build-templates fgilcher$ agavi system-template-copy-all
Agavi > system-template-copy-all:
Output directory [/Users/fgilcher/Sites/agavi-build-templates]:
[copy] Copying 55 files to /Users/fgilcher/Sites/agavi-build-templates
Zodiacal-Light:agavi-build-templates fgilcher$
Now we modify the build.xml.tmpl to contain our JSL-Task:
<?xml version="1.0" encoding="utf-8"?>
<project name="%%PROJECT_NAME%%" basedir="." default="status">
<!--
Define project-specific or custom build targets.
-->
<target name="lint-javascripts" description="check all javascripts for validity">
<property name="javascript.lint.showWarnings" value="true" />
<jsllint showWarnings="${javascript.lint.showWarnings}" haltOnFailure="true">
<fileset dir="${project.directory}/pub/">
<include name="**/*.js" />
</fileset>
</jsllint>
</target>
</project>
We can also change or add any other template we might like at this point. From here on it’s a matter of passing the template directory to use to the agavi script:
Zodiacal-Light:Sites fgilcher$ agavi -D templates.directory /Users/fgilcher/Sites/agavi-build-templates project-wizard
...
Zodiacal-Light:Sites fgilcher$
Done. This project will use the modified set of build templates from now on.
Javascript errors are annoying and notoriously hard to track down due to limited IDE support and misleading error messages in browsers, but often it’s only a missing comma or a bracket in the wrong place. A linter helps by checking that your javascript is a least structurally sound. It’s the first check I run on any javascript that does not work, so having it right at my fingertips is important. I’ll show how to integrate that into any agavi project.
There’s a number of JS-Linters out there, I use http://www.javascriptlint.com/, primarily because there’s an existing phing task for it (1). As the agavi build system is based on phing integrating that task is a breeze. Each agavi project has a build.xml in the root directory that can be used to define project-specific targets. By default it’s empty and looks like this:
<?xml version="1.0" encoding="utf-8"?>
<project name="Sample" basedir="." default="status">
<!--
Define project-specific or custom build targets.
-->
</project>
Adding a JSL-Task is a matter of seconds:
<?xml version="1.0" encoding="utf-8"?>
<project name="Sample" basedir="." default="status">
<!--
Define project-specific or custom build targets.
-->
<target name="lint-javascripts" description="check all javascripts for validity">
<property name="javascript.lint.showWarnings" value="true" />
<jsllint showWarnings="${javascript.lint.showWarnings}" haltOnFailure="true">
<fileset dir="${project.directory}/pub/">
<include name="**/*.js" />
</fileset>
</jsllint>
</target>
</project>
And now it’s just a call to
Zodiacal-Light:~ fgilcher$ agavi lint-javascripts
That’s it. It’s trivial to extend the task-definition to pass some options to the linter - I’ll leave that to you.
(1) There’s a minor bug in the JSL-Lint Task that’s fixed on trunk. See http://phing.info/trac/ticket/349
