[TYPO3-dev] New doktype: automatic BE page tree for record attributes

[David Toshack]

Elmar Hinz has some great ideas about this sort of thing, as mentioned
in the following ECT post:
http://lists.netfielders.de/pipermail/typo3-team-extension-coordination/2006-September/001007.html

Just thought you might be interested in furthering the discussion over
there.

Cheers,
David

Zorik wrote:
>> Well, let me know what do you think.
> 
> I think that "usability" in BE is a waste of time. Records should be created
> fast by a person who knows how to create them. Interface should not
> be "intuitive" and the process not necessarily must be "easy".
> 
> However, at the FE this is a necessary thing to exist in many cases.
> Once I had to create navigation menus "on the fly" - it was a travel agency
> where menus were slices of DB table "packages" by fields:
> 1. menu 1 - unique locations
> 2. menu 2 - unique package type (flight, tour, hotel)
> 3. menu 3 - unique airline
> 4. menu 4 - unique guide
> but the problem here is a DB architecture and not processing (at my
> experience). So creating an extension will not "do the trick".
> 
> 
> 
> I've heard some folks have created a class which acts as a database. It lays
> between application and DB. Working with it - is pure PHP - no SQL queries.
> (pardon me - dont remember the name)
> This layer would provide the missing flexibility to TYPO3 in ways of
> organizing data.
> But this should be done in core, so I do not think it would ever be
> implemented. 
> 
> 
> 
> As for extending "pages" and "tt_content" in general.
> Those tables are overloaded with all kinda junk already from various
> extensions. Search on them is slow. Architecture is hard to understand.
> I would rather join them with my extension's table, than extend them (or use
> them).
> 
> 
>