[TYPO3-dev] $this->pi_exec_query doesn't work correct with workspaces?

[R. van Twisk]

Martin Kutschker wrote:
> R. van Twisk schrieb:
>   
>>>   
>>>       
>> maybe workspace development should be stopped in favor of 5.0 developments.
>>     
>
> Will 5.0 have no more workspaces? What are the ideas
>   
Basicly what i was trying to say is re-think about workspaces, because I 
do think it's a great idea,
but there are currently to much problems with it (from what I see here, 
other people might disagree).
I think with 5 on the design table it would be a great time to use 
workspaces as part of the
core storage/retreival enginal (to get and store content).

>   
>> In 5.0 there will be a method for storing and retrieving data,
>> I truly hope that in 5.0 we never have to do any SQL query at all from
>> anything outside of the core. but we just use data retrieval methods.
>>     
>
> The whole concept of this Java-API-thingy makes me shudder. Maybe I'm 
> old-fashioned but I like to do my SQL statements. Then I know what goes 
> on and how I can tweak things.
>   
Actally I was not talking about java.. I was just talking about a engine 
that can
store and retreive data on a core level.
> Maybe I can convinced/impressed but I don't think I'll work with a 
> system where I cannot get DB access when I want to.
>   
A CMS system should manage content. This is a task of the CMS, this 
means that
any extension should not worrie about where content comes from, or how 
it is
stored, the extension should just worrie about how to retreive the content.

For example when I retreive a page on the net my browser doesn't worry about
how the content comes in, may by on the other end they use apache, or 
lighthttpd,
maby teh content is retreived from LDAP, or SQL... who cares... the browser
shurly doesn't


So from a extensions perspective,
it should use an API to get content, basically ask the core CMS prevered
using a message passing method (but I don't want to go in detail).

A extension can do this to a core for example

GET:/some_domain/some/file/path/with_file.jpg

This means something like:
Get me the file 'with_file.jpg' from 'some_domain' stored in the path
'/some/file'.

This can go in a great extend ofcourse, and care should be taken to keep 
the speed
and all that sort, but that is up to core implementation!

You can image a PUT method to store images, files and other content.

The problem might be related records ofcourse.... But this should beable to
be solved one way or a other.


Now if the core handles ALL content and ALL content is passed through
some API then the core can index ALL files properly.

And by using a API and a message bus we can catch all messages
passing in the system, so other extension can 'hook' into the bus
catch messages, modify them as need etc etc.

Also if we use a storage engine like that it is much easer to connect
it to different database systems (I still don't like it that I cannot
use postgresql easly with typo3). maybe store content in LDAP,
should theoretically be possible...

Now a concept in practice:
Think of file systems, we have EXT3, ext2, xfs and many more.
 From the programs perspective he doesn0t care what file system it is
stored, and the program just uses the file API (fileopen, fileclose etc)
to store files. A similar concept is needed in a CMS.

 From teh extensions point of view it should not care about where it is 
stored,
or how, or how it is indexed... it should just use the get/put API's.

When it IS using the API, teh core can handle user authentication,
eg it knows when a user does have access or not. OR it
can be used with workspaces, because teh core knows what
workspace is active...

About DB access:
I have seen already to many extensions that use propriatry SQL
calls known on mysql only... which renders it un-usable
on any other DB.

The downside of a such a API might be that speed can be a issue.



I have seen one CMS system (specialized in storing 3D data),
that you can ask all possible and impossible questions to it.
You could even ask to find objects in 3D space similar
to other objects in 3D space, how cool is that!!!!)

We really need to think outside of the scope of tables and databases,
we need to start thinking on objects and meta data,
storing objects and retrieving objects (in any form). Storing
array of objects and related objects.


regards,
Ries





















> Masi
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
>   


-- 
Ries van Twisk
Freelance Typo3 Developer
=== Private:
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/freelance-typo3.html
skype: callto://r.vantwisk
=== Work:
email: ries at livetravelguides.com
web:   http://www.livetravelguides.com