[TYPO3-core] RFC: TCA Sections
Bernhard Kraft
kraftb at kraftb.at
Tue Apr 25 17:44:45 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi !
I had a discussion with Kasper about a so called "Section elements" feature for TYPO3
TCA tables.
Currently sections are availble by default when you use Flexform - they are also known
as "Repeatable content element" ...
I implemented this feature for traditional SQL tables instead of XML by using a
1:n relation which currently is not really used/implemented in TYPO3 - of course there
are things like comma-separated lists but those are suboptimal for the task.
If you would like to know how such sections look like you can either try it yourself -
as I released an extension implementing this feature via a TCA userFunc as extension
"kb_tca_section"
You can also take a short look at the manual - in the beginning there is a screenshot.
I'll post this to the list as I would like to introduce this feature to the core if not
any of you completly disagrees with it.
I'll attach already happend discussion between me and Kasper at the bottom of this message.
Kasper Skårhøj wrote:
> - If you want to introduce a "parent" field so records can be children
> of other records, just like all records has "pid" field connecting it
> to a page: This I can only allow as long as the usual "pid" field is
> the authoritative pid and the "parent" field is just a standardized way
> to point out a field that is a parent pointer. Such a thing could be
> used to make the Web > List module able to display eg. a category table
> as a tree.
I made the name of the "parent" field configurable via the 'ctrl' section of the table which
shall get used as section (*ups* I think I missed to document that - will update docs right
after this mail)
It is of course fully independent of the "pid" field of TCA tables.
About a tree-list view :
http://think-open.org/kraftb/index/tree_list.png
(This is no fake or just design - already running on my dev box :)
> My main concerns are:
> - Supporting that records inside of TYPO3 can avoid having a "pid"
> field and do with only a "parent" field pointing to a parent record
> from the same table is such a foundational change that affects
> everything down to rights management. I wouldn't touch it with a ten-
> foot pole (before we have maybe an object oriented structure that can
> make it a secure alternative).
I wont touch the "pid" after all. I think this field should stay as it is - when somebody
places two records which are in a parent-child relation on two different pages it's his
own fault and he will not see them nested in the "tree-list view":
> - Supporting even an official "parent" field for such as a category
> table includes changes to eg. sys_refindex and integrity check
> routines. That is possible to accept.
No it wont. As I say I have all this running on my box and as the "parent" field is a simple
"type => select" TCA element references are counted properly :)
> "group" and "select" relation types:
> - We have both comma-separated lists and MM-relations as options. The
> APIs generally take care of this transparently so the argument about
> usage in SQL is really not on the higher level but what you prefer
> underneath the hood.
I agree ... It should be possible to use either comma-separated lists or
MM-relations or ... as I would prefer it "1:n" relations as they exactly
express the relation.
With MM you can have
Main Record Sub Record
123 344
123 655
123 576
321 576
As you see the last sub-record (576) "could" get assigned to two different main
records - and that should not be an option.
I mean you did also not introduce a "pages_pages_MM" table and create the relations
between parent-child of pages via a MM table but rather via a 1:n relation (letting
the child point to the parent - more childs can point to one parent)
(AFAIK those are really called N:M not M:M ... M:M would suggest that both elements of the relation
MUST have the same number of realtions - which is not true - N:M shows up that left/right part of
the relation can have different amount of related elements ... but we should not change the TCA
field "MM" to "NM" before T3 version 6.0 :) doesnt make much sense at all but is rather cosmetical
again.
See:
http://de.wikipedia.org/wiki/Schl%C3%BCssel_(Datenbank)#Fremdschl.C3.BCssel_und_Beziehungstypen
"Fremdschlüssel und Beziehungstypen"
(Only in german tough - the english version is still incomplete
> "section" records:
> In my eyes the idea itself is independant of whether group and select
> relations are comma lists or MM relations and even the "parent" idea of
> yours does not affect it. The main idea of what you suggest is that the
> list of related records that is normally shown as a selector box could
> instead/additionally be shown as these records editable inside the main
> record. I think that is a fine idea. But please don't invent new
> relation types to do it - simply implement it for those we have!
Yes. Your idea of showing "group/select" boxes just "directly" inside the record
has a nice touch ... I rather tought about some database-correct way instead of
practical - which is surely one of your strengths !!
I will implement the possiblity to either have "normal" relation-fields shown directyl
inside the form and also the possiblity to have the "reverse-linked / 1:n / child contains
parent-pointer" version.
The rest of our discucssion:
***********************************************************************************************************
> On Apr 24, 2006, at 17:13 , Bernhard Kraft wrote:
>
> Kasper Skårhøj wrote:
>
>>>> I don't mind if you work on this, I'm sure many people would like it.
>>>> However, its important that the records you edit inside the TCE forms
>>>> are referred to by a normal "group" or "select" field - that is how I
>>>> imagine that you do it; simply offer to render the "select" or "group"
>>>> field as real records...
>
>
> What we talk about here is a 1:n relation. One record (the main one
> you choosed
> to edit) contains more (n) "section" records it refers to ....
> I think we should settle to call those records "section" record when
> we talk - this term
> was already used for the synonym TV feature.
>
>
> You can create a n:m realations just when you have an extra table
> defining the connections
> of two tables :
>
> Table A <-- n:m table --> Table B
>
> Now when you want to create a 1:n relation you can either do that
> like it is "usual" in
> TYPO3 by having one field in Table A which contains some relations to
> records in Table B:
>
> Table A (comma-list field "childs") --> Table B
>
> The problem here is that you have a comma separated values list and
> you can in no way use
> that directly in SQL (i.e: Selcet all "connected" records of a "main"
> record via a JOIN).
>
> To achieve this you would have to use the following structure
>
> Table A <-- (field "parent") TableB
>
> So rather a structure like the "pid" field of the pages table which
> point's to it parent.
>
> The same as with the page's pid field those "parent" fields are only
> allowed to hold ONE (!)
> reference to it's parent - so not more than one parent.
>
> The 'parent' field of course is a real TCA field which is of kind
> "select" with a "foreign_table"
> property pointing to the main-table ... with "maxitems" and "size"
> set to 1. The database type
> is "integer" (no need for lists :)
>
> It is in the opinion of the adminstrator/extension author who set's
> up a site (the TCA) if he
> wan't to show the "parent" field inside the "section" records or not.
> Showing the field allows an Editor to "move/reassign" such a section
> record from one main record
> to another.
> As "exclude" fields fully work with my solution you can also show
> this field for one user and hide
> it for others .
>
>
>
> Final conclusion:
> I did not want to put anything into the TYPO3 core if you do not want
> it - so this is why I asked you
> as this is not only a bug-fix but a completly new feature.
>
> I made an extension which works completly without XCLASSes and makes
> this feature possible.
>
> I will publish the extension and check if people are interested in it
> - if there is reasonable
> interest I will do some work to get a core-patch ready.
>
>
>
> greets,
> Bernhard
> --
> - ----------------------------------------------------------------------
> "Freiheit ist immer auch die Freiheit des Andersdenkenden"
> Rosa Luxemburg, 1871 - 1919
> - ----------------------------------------------------------------------
> - kasper
> "A contribution a day keeps the fork away"
> -------------------------------
> kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej | gizmo:
> kasper_typo3
***********************************************************************************************************
Hi Bernhard,
(Sorry for sending a ´blank reply).
I have watched the video although I couldn't hear the sound.
Your idea is actually old - Jan Hendrik Heuing has been suggesting it some years ago and he had an implementation which never made it to the core though.
I don't mind if you work on this, I'm sure many people would like it. However, its important that the records you edit inside the TCE forms are referred to by a normal "group" or "select" field - that is how I imagine that you do it; simply offer to render the "select" or "group" field as real records...
- - kasper
On Apr 14, 2006, at 16:21 , Bernhard Kraft wrote:
> Hi Kasper !
>
>
> How is your "family" ? I think I can say that now ;)
>
>
> I have something nice which you would like to look at probably ....
>
> http://think-open.org/kraftb/kb_shop.avi
>
> It's a demo video of my shop extension ... It features a complete new way of defining
> extension tables in the BE ... currently you have statical tables which can only get modified by
> editing .sql files etc. (the kickstarter is no option as it removes every custom code of pi1/ mod/
> class files when updating an extensino)
>
> With this extension you define "properties" as records in a "normal" table and the order and hierarchy
> of this properties defines the fields of a table "products" .... additionally you can have different
> "categories" which show or not show specific fields/properties (you assigned).
>
> Everything is done fully T3 conform. So for example the switch of fields using the category selector is
> done using TCA "types" fields ...
>
> You can put some properties in a sub-folder of the main-property container which will result in getting
> TCA "Tabs" using the divider2tabs feature ... so the forms look mostly like flex-forms but are "real" tables
> with "real" fields ... now XML here :) (but properties use flexforms)
>
>
> And the reason why I want to show you this after all is a nasty little feature which I have added to
> TCEforms via a userFunc field ... i call it: "TCA sections" ... well you can guess ... it implements the
> "sections" paradigm of flexforms (having a variable number of "subfields" in a record). Again real tables
> are used. Each "section" table just has to have a parent pointer to the record which it is attached to ...
> sorting and labels of section tables are again dynamic....
>
>
> but before I start to write a book just have a look at the video ... it's about 12min (120MB ... sorry I do not
> own a MAC with good encoders) .... you can also replace the .avi postfix by ".mpg" (21 MB) or ".wmv" (31 MB)...
> but if bandwidth is no prob for you rather go with the .avi as it doesn't show such strange looking artefacts.
>
>
> After all I would like to know if it would be a good idea to implement those "TCA Sections" into the core ...
>
>
> PS: Today I bought a pacifier for Amelie. But I'm sad to say I just bought it in a local supermarket so it will be
> a rather usual one ... I hope that's ok.
>
>
>
> greets,
> Bernhard
> --
> ----------------------------------------------------------------------
> "Freiheit ist immer auch die Freiheit des Andersdenkenden"
> Rosa Luxemburg, 1871 - 1919
> ----------------------------------------------------------------------
- - kasper
"A contribution a day keeps the fork away"
- -------------------------------
kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej | gizmo: kasper_typo3
***********************************************************************************************************
greets,
Bernhard
- --
- ----------------------------------------------------------------------
"Freiheit ist immer auch die Freiheit des Andersdenkenden"
Rosa Luxemburg, 1871 - 1919
- ----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFETkPsIl4dkVkDMFkRAj2pAKCI/ZUiLdM9yiDVnwy8Q5C38HkRHwCbB0aR
br4i8S4x+L8nzLKOADwqHsA=
=pkeH
-----END PGP SIGNATURE-----
More information about the TYPO3-team-core
mailing list