Working with Symfony and the CLI tools on the GitHub 2.3 branch

[Dan Field]

I'm new to Symfony and AtoM but not PHP. I'm trying to write a plugin which will require some supporting db tables, forms and addition of a button or 2 to the templates. I figured forking the 2.3 branch https://github.com/Surfrdan/atom would be a sensible place to start and then I started on the plugin docs http://symfony.com/legacy/doc/jobeet/1_4/en/20?orm=Propel. 

So far, I've created a dir plugins/nlwCirculationPlugin and in there I have a config subdir with a nlwCirculationPluginConfiguration class, routing.ml and schema.ml but any attempts to use the symphony CLI tools are failing me e.g. even on a fresh checkout of the qa/2.3 branch, I can not run build-forms

Dans-Mac-mini:atom dof$ php symfony propel:build-forms

>> propel    generating form classes

                                                              

  Unable to find the model dir name (model) in the package .  

                                                              

Is there anything I need to do to the github branch before running CLI tools? I tried building the package with phing. This required me changing a grep command from -P to -E in order to support extended regex on OS X in the line <exec command="cat apps/qubit/config/qubitConfiguration.class.php | grep VERSION | grep -Eo '\d\.\d\.\d'" outputProperty="package.version"/>

but Other than that, the project is untouched from the github branch.

Any documentation on working within the AtoM project itself would be useful. The IRC channel seems to have been empty for weeks or I'd have asked there first.  

[Dan Field]

For completeness sake, I tried with the 2.2 download tarball and had the same result:

Dans-Mac-mini:atom-2.2.0 dof$ php symfony propel:build-forms

>> propel    generating form classes

PHP Warning:  constant(): Couldn't find constant QubitAclGroupI18n::PEER in /private/tmp/atom-2.2.0/vendor/symfony/lib/plugins/sfPropelPlugin/lib/generator/sfPropelFormGenerator.class.php on line 90

PHP Stack trace:

PHP   1. {main}() /private/tmp/atom-2.2.0/symfony:0

PHP   2. include() /private/tmp/atom-2.2.0/symfony:14

PHP   3. sfSymfonyCommandApplication->run() /private/tmp/atom-2.2.0/vendor/symfony/lib/command/cli.php:20

PHP   4. sfTask->runFromCLI() /private/tmp/atom-2.2.0/vendor/symfony/lib/command/sfSymfonyCommandApplication.class.php:76

PHP   5. sfBaseTask->doRun() /private/tmp/atom-2.2.0/vendor/symfony/lib/task/sfTask.class.php:97

PHP   6. sfPropelBuildFormsTask->execute() /private/tmp/atom-2.2.0/vendor/symfony/lib/task/sfBaseTask.class.php:68

PHP   7. sfGeneratorManager->generate() /private/tmp/atom-2.2.0/vendor/symfony/lib/plugins/sfPropelPlugin/lib/task/sfPropelBuildFormsTask.class.php:72

PHP   8. sfPropelFormGenerator->generate() /private/tmp/atom-2.2.0/vendor/symfony/lib/generator/sfGeneratorManager.class.php:113

PHP   9. constant() /private/tmp/atom-2.2.0/vendor/symfony/lib/plugins/sfPropelPlugin/lib/generator/sfPropelFormGenerator.class.php:90

... <snip>lots more undefined constants and finally:

[Jesús García Crespo]

Hi Dan,

It seems that our project stopped working with Propel's form generator, we should probably fix that at some point. We haven't noticed because we don't use its form generator at all, instead we build our own forms inside the controllers, e.g. check how StaticPageEditAction builds its own form with the help of DefaultEditAction. You can try to mimic that once you start working on the controller layer.

So try to ignore that step where you run `propel:build-forms`, it's not needed. But you definitely need `propel:build-model` and `propel:build-sql`. Once the SQL has been generated, run `tools:purge --demo` to populate the new schema in the database. This command assumes that AtoM has already been set up using the web installer, as the installation populates some important files like config/config.php or apps/qubit/config/settings.yml that are going to be needed by the CLI tools as well.

If you are in qa/2.3.x, you are going to run in the following error when running `tools:purge --demo` after building the model classes: Unknown record property "events" on "QubitInformationObject". That's a known bug (see https://projects.artefactual.com/issues/8784). The following illustrates how to solve it:

$ php symfony propel:build-model

$ php symfony tools:purge --demo

 Unknown record property "events" on "QubitInformationObject"

$ git status -s lib/model/om/BaseInformationObject.php

 M lib/model/om/BaseInformationObject.php

$ git checkout -- lib/model/om/BaseInformationObject.php

$ php symfony tools:purge --demo 

 Purge complete!

We are hoping to fix that before AtoM 2.3 is released.

Let us know how it goes and don't hesitate to ask more questions.

[Dan Field]

On Monday, 28 September 2015 17:06:50 UTC+1, Jesús García Crespo wrote:

Hi Dan,

It seems that our project stopped working with Propel's form generator, we should probably fix that at some point.

No problem. Thanks for confirming that. 

 

We haven't noticed because we don't use its form generator at all, instead we build our own forms inside the controllers, e.g. check how StaticPageEditAction builds its own form with the help of DefaultEditAction. You can try to mimic that once you start working on the controller layer.

I'll take a look at those now.  

 

So try to ignore that step where you run `propel:build-forms`, it's not needed. But you definitely need `propel:build-model` and `propel:build-sql`.

I've just tested and both work flawlessly. 

 

If you are in qa/2.3.x, you are going to run in the following error when running `tools:purge --demo` after building the model classes: Unknown record property "events" on "QubitInformationObject". That's a known bug (see https://projects.artefactual.com/issues/8784). The following illustrates how to solve it:

$ php symfony propel:build-model

$ php symfony tools:purge --demo

 Unknown record property "events" on "QubitInformationObject"

$ git status -s lib/model/om/BaseInformationObject.php

 M lib/model/om/BaseInformationObject.php

$ git checkout -- lib/model/om/BaseInformationObject.php

$ php symfony tools:purge --demo 

 Purge complete!

That worked perfectly, thanks for stepping me through this. 

 

We are hoping to fix that before AtoM 2.3 is released.

Let us know how it goes and don't hesitate to ask more questions.

I will. I'm hoping to work on this for the next week or two. Thanks again.

Dan Field