Symfony 1.2.4: Build-All Bug? Cannot fetch TableMap…
So, I have been recently trying to get back into Symfony. I had taken a break from it for a while to concentrate on Music Review Zone.
I bought a domain recently that I’d like to develop a Symfony application for and since my current knowledge base is with Symfony 1.0 – I thought I’d use it. Then I noticed the benefits of Symfony 1.2.4 and couldn’t pass it up.
So I started creating my project in the usual way:
php symfony init-project <name of project>
php symfony init-app front
I then setup my databases.yml file and completed my schema.yml file. I then ran:
php symfony propel:build-all
… and got the following output:
symfony propel:build-all
>> schema converting "C:/wamp/vhosts/private/config/schema.yml" to XML
>> schema putting C:/wamp/vhosts/private/config/generated-schema.xml
>> propel Running "om" phing task
>> file- C:/wamp/vhosts/private/config/generated-schema.xml
>> file- C:/wamp/vhosts/private/co...enerated-schema-transformed.xml
>> autoload reloading autoloading
Phing was run before and used many custom classes that might conflict with
your model classes. In case of errors try running "propel:build-forms" and
"propel:build-filters" alone. This is due to a PHP limitation that cannot be
fixed in symfony.
>> propel generating form classes
Cannot fetch TableMap for undefined table: location. Make sure you have the
static MapBuilder registration code after your peer stub class definition.
[?php
/**
* User form base class.
*
* @package ##PROJECT_NAME##
* @subpackage form
* @author ##AUTHOR_NAME##
* @version SVN: $Id: sfPropelFormGeneratedTemplate.php 12815 2008-11-09
10:43:58Z fabien $
*/
class BaseUserForm extends BaseFormPropel
{
public function setup()
{
$this->setWidgets(array(
'id' => new sfWidgetFormInputHidden(),
'username' => new sfWidgetFormInput(),
'location_id' => new sfWidgetFormPropelChoice(
I am beat as to why this is occurring.
My schema.yml file creates a user and location table, among others. Each user has a location which I state in the YAML as :
user:
_attributes { phpName: User }
id: ~
username: { type: varchar(50), required: true, index: unique }
location_id: ~
I also define the location table as:
location:
_attributes { phpName: Location }
id: ~
name: varchar(50)
created_at: ~
So I do not know why ‘symfony propel:build-all ‘ is failing.
When I run each of the commands that makes up the ‘build-all’ option – each succeeds. i.e:
- build-schema
- build-sql
- build-model
- build-filters
- build-forms
So is this a bug or are your fresh eyes noticing something that I am missing?
Tags: symfony, symfony 1.2.4, tablemap
Categories: Programming, symfony
Symfony 1.2.4: Build-All Bug? Cannot fetch TableMap…
So, I have been recently trying to get back into Symfony. I had taken a break from it for a while to concentrate on Music Review Zone.
I bought a domain recently that I’d like to develop a Symfony application for and since my current knowledge base is with Symfony 1.0 – I thought I’d use it. Then I noticed the benefits of Symfony 1.2.4 and couldn’t pass it up.
So I started creating my project in the usual way:
php symfony init-project <name of project>
php symfony init-app front
I then setup my databases.yml file and completed my schema.yml file. I then ran:
php symfony propel:build-all
… and got the following output:
symfony propel:build-all
>> schema converting "C:/wamp/vhosts/private/config/schema.yml" to XML
>> schema putting C:/wamp/vhosts/private/config/generated-schema.xml
>> propel Running "om" phing task
>> file- C:/wamp/vhosts/private/config/generated-schema.xml
>> file- C:/wamp/vhosts/private/co...enerated-schema-transformed.xml
>> autoload reloading autoloading
Phing was run before and used many custom classes that might conflict with
your model classes. In case of errors try running "propel:build-forms" and
"propel:build-filters" alone. This is due to a PHP limitation that cannot be
fixed in symfony.
>> propel generating form classes
Cannot fetch TableMap for undefined table: location. Make sure you have the
static MapBuilder registration code after your peer stub class definition.
[?php
/**
* User form base class.
*
* @package ##PROJECT_NAME##
* @subpackage form
* @author ##AUTHOR_NAME##
* @version SVN: $Id: sfPropelFormGeneratedTemplate.php 12815 2008-11-09
10:43:58Z fabien $
*/
class BaseUserForm extends BaseFormPropel
{
public function setup()
{
$this->setWidgets(array(
'id' => new sfWidgetFormInputHidden(),
'username' => new sfWidgetFormInput(),
'location_id' => new sfWidgetFormPropelChoice(
I am beat as to why this is occurring.
My schema.yml file creates a user and location table, among others. Each user has a location which I state in the YAML as :
user:
_attributes { phpName: User }
id: ~
username: { type: varchar(50), required: true, index: unique }
location_id: ~
I also define the location table as:
location:
_attributes { phpName: Location }
id: ~
name: varchar(50)
created_at: ~
So I do not know why ‘symfony propel:build-all ‘ is failing.
When I run each of the commands that makes up the ‘build-all’ option – each succeeds. i.e:
- build-schema
- build-sql
- build-model
- build-filters
- build-forms
So is this a bug or are your fresh eyes noticing something that I am missing?
Tags: symfony, symfony 1.2.4, tablemap
Categories: Programming, symfony
Symfony Session Timeout Annoyance…
I have recently found that symfony doesn’t attempt to properly maintain the user’s session after logout.
This is a tad annoying as any attributes that have been set during a valid login session will still be set when the user is communicating with the server. It is also a security risk.
Symfony provides the basic building blocks for creating an application, and session management is a part of that. The myUser class contains paramter, attribute, credentials classes as well as some variables like culture (for internationalisation), authenticated and timedout.
The ‘authenticated’ variable’s use should be pretty obvious – when the application is processing the users login it should set the authenticated variable to ‘true’ :
$this->getUser()->setAuthenticated(true);
The ‘timedout’ variable is set automatically be symfony when … alas … the users session has expired/timed out – pretty self explanatory.
The problem comes when your application sets any parameters or attributes during the sessions lifetime. For example, in my application when the user logs in I set a session variable ‘nickname’ so that I can reference/identify the user during any subsequent requests :
$this->getUser()->setAttribute('nickname', $user->getNickname());
This is pretty basic and normal functionality.
This attribute should die along with the session, when it times out – but it doesn’t. There are some perfectly valid reasons why this happens e.g The ‘Validated User’ and the ‘Browsing User’ are two different things to the system but the contents of the shopping cart are not. Another example would be website tracking software. It monitors where users are and what they are looking at – a very good tool for marketing. This type of software doesn’t have to care whether the user is logged in order not as its only concern is where they are and what they are doing. This information needs session data to follow the user. If all session data were cleared after the user logged out – then the monitoring software would be thinking a new user arrived – which would be wrong.
What is needed in this situation is a trigger or a test that determines if the session has expired and if it has – then action something appropriately.
The only way that I have determined to do this is by editing the myUser.class.php file for the application (and every other application) in your project.
As the myUser class is instantiated before any actions we can alter/clean up the session before any proper processing is done :
class myUser extends sfBasicSecurityUser
{
public function initialize($context, $parameters = array()) {
parent::initialize($context, $parameters = array());
if($this->isTimedOut()) {
$this->getAttributeHolder()->remove('nickname');
}
}
}
If you don’t like the idea of having to do this for all your applications – then you can create a new class and make the myUser class extend it instead (you must ensure that the new class also extends sfBasicSecurityUser. That way you have one central place to update when you need to clean up your session.
Hope this helps…
If you have any better ways of doing this – please let me know. I’d be interested to hear your take on it.
Categories: Programming, symfony