Jump to content
Larry Ullman's Book Forums

Chapter 5 Questions: Requiredvalue, Scenarios, Passwords, Enum, Attributelabels, Relationships, Syntax


KeepLearning
 Share

Recommended Posts

Here are some questions that crossed my mind while reading Chapter 5 (Version 0.5)

 

 

Page 86
The book states, "If you also set a requiredValue attribute for the item in question, your error message can indicate what the required value is via {value}."
My question: Larry, could you please provide an example showing how the value of {value} would be set?
 
Page 91
Please show the code I would need to "create user-related scenarios for changing passwords".
Also, in which circumstances would I set a scenario on an existing instance, as opposed to creating a new user?
 
Page 93
Why is it necessary to write "filter" twice in this code: 'filter', 'filter'=>'strip_tags' ?
 
Page 94
Wouldn't declaring search terms as safe be a security risk?  Here is the code from the book:
array('id, user_id, live, title, content, date_updated, date_published', 'safe', 'on'=>'search'),
 
Page 95
Why would we need to compare passwords if the user is only just registering? How would he/she already know a password? Quoting from the book:
// Password must match the comparison:
array('pass', 'compare', 'compareAttribute'=>'passCompare', 'on'=>'register'),
 
Page 95
I have read a credible article on the Internet stating that ENUM fields are "evil". If I prefer to avoid using an ENUM field, and instead use a separate table of "types" which lists these values 'public','author','admin' etc, and the table has a one to many relationship with User.type, how would I obtain the values from the types table for use in this rule? Here is the code from the book:
array('type', 'in', 'range'=>array('public','author','admin')),
 
Page 97
The book states: "Also, when you have a model that’s not based upon a database, you’ll need to add the attribute names and values to the attributeLabels() method yourself."
How do these attribute labels end up being incorporated into various HTML forms?
 
Page 101
Quoting from the book: $this->user_id = Yii::app()->user->id;
My question: I understand the relationship, but aren't there many user.id values to choose from? How does the framework know which id is the correct one?
 
Page 102
Here's a syntax question:
'date_entered'
in the first example becomes
$this->created
in the second example. How can these refer to the same table field?
 
Page 102
Can you please provide an example how I could "return false in the event handler method"? Quoting from the book:
"As a final note on this concept, if the event that’s about to take place shouldn’t occur–for example, the model should not be saved for some reason, just return false in the event handler method."
 
Thanks.
 
Link to comment
Share on other sites

First, it's probably best to do individual threads for unrelated questions. Easier to maintain and search that way.

 

 

Here are some questions that crossed my mind while reading Chapter 5 (Version 0.5)

 

 

Page 86
The book states, "If you also set a requiredValue attribute for the item in question, your error message can indicate what the required value is via {value}."
My question: Larry, could you please provide an example showing how the value of {value} would be set?
 
In a rule, you assign a value to "requiredValue", and that becomes the value of the {value} placeholder. It may help your understanding if you were to experiment with some code for yourself.
 

 

 
Page 91
Please show the code I would need to "create user-related scenarios for changing passwords".
Also, in which circumstances would I set a scenario on an existing instance, as opposed to creating a new user?
 
I don't have any code readily available. I would recommend you take a crack at it yourself and then let us know if you have problems with it. As for your question, there might be a scenario for updating a user (i.e., an existing instance), in which case the password rules may apply (e.g., to compare two passwords), but those rules wouldn't apply when using an existing instance to login.
 

 

 
Page 93
Why is it necessary to write "filter" twice in this code: 'filter', 'filter'=>'strip_tags' ?
 
The first "filter" identifies the validation tool to use. The second identifies the actual filtering function.
 

 

 
Page 94
Wouldn't declaring search terms as safe be a security risk?  Here is the code from the book:
array('id, user_id, live, title, content, date_updated, date_published', 'safe', 'on'=>'search'),
 
I don't understand what you're asking here.
 

 

 
Page 95
Why would we need to compare passwords if the user is only just registering? How would he/she already know a password? Quoting from the book:
// Password must match the comparison:
array('pass', 'compare', 'compareAttribute'=>'passCompare', 'on'=>'register'),
 
This is a standard registration approach, which you've probably seen a million times. That rule confirms that the "confirm password" input's value matches the password value (i.e., the two password fields match). The user sets her password when she registers. So she knows it, because it's her password and she's creating it. 
 

 

 
Page 95
I have read a credible article on the Internet stating that ENUM fields are "evil". If I prefer to avoid using an ENUM field, and instead use a separate table of "types" which lists these values 'public','author','admin' etc, and the table has a one to many relationship with User.type, how would I obtain the values from the types table for use in this rule? Here is the code from the book:
array('type', 'in', 'range'=>array('public','author','admin')),
 
There are definitely arguments against ENUM. If you where to use a separate table, you'd use an "exist" validator for that value to confirm that the provided value exists in the related table.
 

 

 
Page 97
The book states: "Also, when you have a model that’s not based upon a database, you’ll need to add the attribute names and values to the attributeLabels() method yourself."
How do these attribute labels end up being incorporated into various HTML forms?
 
You create the code that does it. You'll see examples if you look at any form pages in the view files of a site you've created, or once you get to the chapter on forms.
 

 

 
Page 101
Quoting from the book: $this->user_id = Yii::app()->user->id;
My question: I understand the relationship, but aren't there many user.id values to choose from? How does the framework know which id is the correct one?
 
Yii::app()->user->id always refers to the current user accessing the site (i.e., executing that code).
 

 

 
Page 102
Here's a syntax question:
'date_entered'
in the first example becomes
$this->created
in the second example. How can these refer to the same table field?
 
That may be a mistake on my part.
 

 

 
Page 102
Can you please provide an example how I could "return false in the event handler method"? Quoting from the book:
"As a final note on this concept, if the event that’s about to take place shouldn’t occur–for example, the model should not be saved for some reason, just return false in the event handler method."

 

return false;

Link to comment
Share on other sites

 Share

×
×
  • Create New...