[TYPO3-dev] Dynamic Backend Editing

[Oliver Hader]

Hi Dave,

sorry for the long waiting time. First I'd like to say "thanks for your
encouraging feedback"! ;)

David Bruehlmeier wrote:
> Hi Olly,
> 
> Just one more thing that I think could/should be relevant regarding this
> initiative: If we are aiming towards some kind of great handling of
> complex data structures, I would very much like to see a feature to
> store additional attributes on the _relationship_ table, which is not
> possible today.
> 
> Example: tx_party_parties which stores all the parties,
> tx_party_addresses which stores all the addresses. If we assume the
> relationship between parties and addresses to be 0..n (i.e. addresses
> can be "re-used"), these relationships would be stored on a table like
> tx_party_parties_addresses_mm. On this table, I would like to be able to
> store attributes like the address usage or which address is the standard
> address for the partner.
> 
> It would be very nice if your approach would also include the handling
> of this kind of problem.

Well, I don't know how to handle this yet. There could be some different
approaches on that.


0) Postulate: We use a database structure of the mm-intermediate table
like the following:

uid_local int(11) unsigned
uid_foreign int(11) unsigned
sorting int(11) unsigned


1) We could add a field for storing additional data (attributes), add
make this field "big" enough (type "blob").

additionaldata blob


1.1) This field could store a serialized array representing your
attribute configuration like the following. I added a branch for one of
the related tables ('..._addressed') because the attribute possibly
should only affect the addressed, so we can also store this information.

[Array] (
	'tx_party_addresses' => (
		'isStandard' => true
	)
)


1.2) We could do the same using FlexForms or any XML-structure.


2) The fact, that we do not know how complex these attributes will be
and how much data is stored in this one single field, we could use
another table for storing attributes. So we add a uid-field to the
normal ..._mm-table to have an indexing value that we can use on the new
attributes table (e.g. "tx_party_parties_addresses_mm_attributes"):

uid int(11)
uid_mm int(11)
attributeName varchar(64)
attributeValue tinytext (possibly blob, but that wastes much storage)
affectsTable tinytext


So I tend to use 1.1 suggestion, but if there are many relations stored
(e.g. 10 addresses each party and some 10.000 parties) it would be not
funny to get the standard address of each party, so suggestion no. 2
would be better.

What do you think?


olly
-- 
Oliver Hader
http://inpublica.de/