[Typo3-dev] General records strategy

[Kasper Skårhøj]

On Fri, 2004-12-10 at 09:20, Jean-David Gadina wrote:
> Thanx for the answer Kasper,
> 
> I totally agree with the philosophy behind the general storage folder. It's a very good option to store some elements by that way. It's logical for development and administration purposes. But for the non-admin users, it may be a little confusing. That's why I don't like the idea of too much different elements in such a folder.
> 

That is a problem that can be solved by a "layer" over the list module.

For any given site a module could find what the current storage folder
is an present an interface with nice soft icons that show what overall
objecst there are on the site. This will be fe-users, templavoila items,
etc. The user clicks an icon can a list with beautiful soft icons appear
with whatever information is specially useful for that kind of element.
This is just an example of why TYPO3 doesn't have to be hard or unhandy
just because we use some generic underlying principles. We just need
someone to do this!

BTW, let me also point you are two other things:

For a storage folder, try to set this value in the Page TSconfig field:

	mod.web_list.listOnlyInSingleTableView = 1

Let me know what you think.

And; For a thing like TemplaVoila: Did you ever click the
"Web>TemplaVoila" module? This is a tailor made overview of all
TemplaVOila building blocks from a storage folder; a layer on top of the
raw data. 

What about it?


> I understand very well the complexity of implementing multiple PIDs, or recursivity. I also agree with the limitation to a unique folder in GRSP. Recursivity for that unique folder, and inheritance from previous top pages should be well enough, from my point of view.
> 
> Maybe a solution would be another function like getStorageSiterootPids(), which will return recursive information. Or maybe just an argument in that previous function, to allow that. By that way, ###STORAGE_PID### will remain untouched, and it shouldn't conflict with current applications. It's just an option in a core method, that could be activated if needed.
> 

Instead of this; What is the real reason for wanting more storage
folders anyway? Considering the tools and visions I have casted above?
Does it still make sense to say "it's nicer to have elements in various
places"?

- kasper