[TYPO3-mvc] Extending an existing model and adding fields

[Franz Koch]

Hey Zoran,

>> What do you mean? I suppose your model belongs to a fe_user and you're
>> not sure how to set up everything to use your fe_user model instead of
>> the default one?
>
>
> I'm sorry if it wasn't clear.  I want to inherit from
> Tx_Extbase_Domain_Model_FrontendUser so objects of my model can be used
> as fe_users.
>
> Also I want to add fields only to my model not to the fe_user in general.

If I got you right, that's not possible. If your model should extend 
FrontendUser and use the fe_users table for authentication etc. you also 
have to add the new fields to the fe_users table. You can't map your 
model to the fe_users table but save certain properties in a different 
table. This will only work if the related properties are objects on 
their own, but still you would need at least one additional field in the 
fe_users table storing the relation (id) to that object (that's what 
Typo3 needs and expects).

> I think an example helps clarifiying this.
>
> The administrator model only inherits from FrontendUser, it doesn't add
> anything.  I'd like to have a model - let's call it Customer - which
> inherits from FrontendUser but also has member variables like for
> example an address.
>
> I can now add a member variable address and a getter and setter to my
> Customer model.  What I don't know is how to make this persistent.

The magic words are single table inheritance. Different models using the 
same table for data storage and each having shared but also different 
properties available. Isn't that an option for you?

>> I see two options here:
>>
>> a) use single table inheritance by adding a new option to the
>> tx_extbase_type field of the fe_users and make it default for all of
>> your users. This only works as long as you don't have to extend the
>> fe_users from a second extension also.
>
> With this I'd change the fe_user, right?  I don't think this is what I want

yes, but the new properties would only be available in models where you 
defined those, so only in your customer model.


>> b) directly assign and use your extended fe_user model throughout your
>> extension. To get this working all you have to do is to also create your
>> own repository to fetch the user objects (probably extending the fe_user
>> repository) and provide a mapping information via TS:
>>
>> config.tx_extbase.persistence.classes {
>>      // name of your own fe_user class name
>>      Tx_YourExt_Domain_Model_User {
>>          mapping {
>>              tableName = fe_users
>>              columns {
>>                  lockToDomain.mapOnProperty = lockToDomain
>>              }
>>          }
>>      }
>> }
>
>
> yeah this would map the whole table to the fe_users table.  In the
> database I need a table for my model to save the model-specific data,
> though.

Ok, so you really don't want to touch the fe_users table. The only 
possibility I see then is to do the implementation upside down. I'd then 
create a customer table and model, and add a property "credentials" or 
"login" to that model, where this would be the relation to the 
FrontendUser. The FrontendUser itself would only be used to save the 
credentials as well as the usergroups. That's what I did in a current 
project, but this also has quite some downsides if you have to interact 
with foreign extensions. You really get in trouble with those ones 
relying on fe_user data like first_name or last_name, which would not be 
available in the fe_users table as you store this information in your 
own table then. So if you need this information also in the fe_users 
table, you either have to map your getters and setters to fetch/save the 
data directly in the FrontendUser or keep the relevant data in both 
tables in sync. I'm currently still struggling on how to do it best - 
either have a clean domain model and redundancy or a working solution 
but scattered data.

Another downside is that you can't easily use directmail with 
personalization then unless you modify it to be able to fetch the 
userdata from your custom table (that's also a issue I have to deal with 
currently).

-- 
kind regards,
Franz Koch