[Typo3-dev] General records strategy
Kasper Skårhøj
kasper2004 at typo3.com
Thu Dec 9 22:47:34 CET 2004
Jean-David is right below,
> GRSP and Starting Points are two things very different. We just need both of them, each one for a particular purpose.
>
> The starting points are related only to a single *content* element. It's not possible to use that with TV, for instance, as it needs to be available for the whole system. So it's really two different things, and not another way of doing things. But I thinks there's a lot of confusion about this point.
>
> The starting point field can take multiple sysfolders, and is recursive. What we need, and what we are talking about, is the implementation of a similar flexibility in GRSP.
>
The reason for the storage folder was in fact the vision of having ONE
single place for storage of all records that related to the whole site
and not individual pages. However it seems people prefer storing FE
users elsewhere etc. rather than by this method. I thought wrong.
The reason why it takes only one folder and cannot easily be extended to
recursivity or multiple folders is mainly that that SQL lookups can be
done on the storage folder by using a marker in eg. foreign_whereclause
values. Example is "AND pid=###STORAGE_PID###" where storage pid will be
substituted wit hthe storage folder. Changing this will require that
ALL places this is used we also change SQL to "AND pid IN
(###STORAGE_PID###)" - but of course we might just introduce
###STORAGE_PID_LIST### instead that is a list of UIDs. However, that
will not be a friend of the guys on the other list that argue to reduce
TYPO3 complexity and options :-)
Another aspect for your information is that fe_users are forced to hvae
unique usernames within a single page. Allowing multiple storage folders
and using them for FE logins means that the same username could
potentially be found in two different folders which are both used for
the authentication lookup, resulting in one of the users not being able
to login of course.
Finally; Applications currently expect that the storage_pid value from
the page header is an integer - what will happen if we set out to change
this to a list of integers? What will break?
See, it is not so simply. Is it worth the cost? Or can we invoke other
means to solve the inconveniences you are experiencing?
- kasper
More information about the TYPO3-dev
mailing list