[Typo3-dev] Re. The future of typo3

[Daniel Hinderink [TYPO3]]

> Daniel Hinderi(n)k writes:

Don't know where my darn n is getting lost on the way. Can you create a rule
inserting it automatically, Michael (Stucki)? :-)

> 
>>>>   * Sheer volume. There may be thousands of front end users and only a
>>>>     few back end users. Finding the back end users becomes difficult.
>>>    
>>> 
>> Not the worst of all points.
>>  
>> 
>>>>   * Security. Putting the two kinds of users in different tables
>>>>     provides extra security.
>>>    
>>> 
>> We all know that this is just one paramter.
>> 
> I am happy to see that we do agree on theese two points.

? I tried to say, that I do find these two factors relevant, while you
don't. I just don't find these two very important, but still valid.


>>>>   * Purposes/separation. The two kinds of users will almost never
>>>>     overlap and are used for entirely different purposes.
>>>    
>>> 
>> That's mostly true in real life business. There are may be less than 5% of
>> industries mingling visitors and users, and mostly this setup is really only
>> needed because one wishes to downsize the complexity for what would be pure
>> editors (=backend users) in specail cases.
>> 
> And then we're back to the purpose of the system. I probably expect it
> to do something that the developers didn't intend to use it for. To me
> it is a special case when the front end users do not "mingle" with the
> back end users.

Well, it is quite obvious that you are thinking in terms defined by a portal
application. I still don't believe the CMS and Portal-worlds have merged in
general and nor do major vendors in my eyes. (but may be they just like to
rather have tow product boxes on the shelves , instead of one).

TYPO3, like most CMS's offers a number of portal-like applications, but it
does have a different foundation for a reason, which is not only historical,
but on purpose.

I have often thought of Plone during this discussion, being a portal system
having (in my eyes) minor CMS-functionality, but built on the application
server ZOPE, which offers the kind of modularity you are looking for by
design.

However, you are investigating TYPO3 in some detail.

> 
>>>> I don't subscribe to any of theese standpoints. Which ones do you
>>>> subscribe to, and have I missed some?
>>>    
>>> 
>> I have hoped to argue on a more theoretical level. Revel, I am going to get
>> even more airy-fairy now.
>> Well you might have missed this:
>> 
>>  
>> 
>>>> On the general notion of creating a symbiotic frontend and backend user
>>>> concept, I am less enthusiastic about this.
>>>> The main reason is that the backend users and groups will have some fairly
>>>> static range of settings to make, basically the ones we have today, plus
>>>> backend menu and settings thereof and of course content types.
>>>> 
>>>> The frontend users logic is different: users might have access, own a
>>>> record
>>>> or some other association with a function or a record, but the form and
>>>> content will vary most widely.
>>>> Therefore the rather thin definition of the FE-User (basically the id) and
>>>> the
>>>> notion of attaching information about rights and ownerships to
>>>> records themselves, is much more flexible and extensible.
>>> 
> Yes. I missed it.  The first thing about symbiosis is something that I
> don't really get. I dont think that the two parts should be
> interdependent. (Se the illustration that I posted yesterday.)

I think there were some things not so clear when I wrote this.
I agree with you that useful functionality should be made available for use
everywhere in the system, front and backend.

I was just at the same time defending the logic behind not unifying the
actual users.

> 
> With regard to the rest of what you write - I don't see any problem in
> having a system where all user records are extended on demand,
> regardless of what their role (ie. fe/be/other) is. I know that the
> frontend users are more likely to be extended a great deal, but then
> you'll have to ask yourself: do we have a reliable system that handles
> extending the exisiting tables? I think that the answer is "yes", which
> solves the problem.

I think we don't need much extension in the backend, but other more
systematic but static improvements. Core work, if you will.

The frontend is much more dynamic and I would not like to bloat the backend
users system with attributes solely meant for the frontend.

> 
>> Please excuse for now, if I don't provide the bridge between your mode of
>> argumentation and mine, but here is my argument restated again in a more
>> abstract manner:
>> 
>> In terms of mathematical logic this means, that there are two places in our
>> equation eligible for being constants, or being challenged in this sense by
>> attaching attributes to either the actors (users) or the objects (records).
>> The question is: to which object in our formula do we attach variety, which
>> of those is more likely to produce systematically less variety, the frontend
>> (to infinty and beyond) or the backend (welcome to Kasper-land).
>> 
>> Sorry to restate the obvious, but for the sake of completing my case:
>> The more attributal variety an object theoretically carries, the less it can
>> possibly become a constant. If two decriptory types of a semantically shared
>> source (the user) differ substantially (!) that is the time to accept a
>> fork.
>> 
>> And even more sorry for being so theoretical. I hope it still is
>> decypherable.
>> 
> I think I understand. Doesn't it boil down to this: typo3 uses two
> different tables for users because the data there are used for very
> different things?

I wanted to point to a logic principle on the determination and influence of
variables on entities. Or in OOP: objects fork when the variety of their
properties becomes too important.
I did so, because there are several of these "objects" in question in the
scenario we are discussing. Records and functionality multiply all around
here.

And yes, one way in our case is to boil it down as you have above.

> 
> Clearly there is a real demand for using the two different data types in
> the same context. People have even written modules that tries to close
> the gap - I am referring to the module FEUser->BELogin.
> <http://michael.zedeler.dk/test/typo3-dummy/typo3/mod/tools/em/index.php?CMD%5
> BimportExtInfo%5D=2072>

True. That is what I was referring to, when I wrote that in some cases this
has been done for reasons of convenience or usability. Still I think a
transgression in this sense is a signal, that a project is really trying to
implement typical portal or application server logic with TYPO3.

In my first reply to you, I wrote that I am all for a more modular design,
that enables the use of functionality in the system on all levels.
I just think that integrating the users in some way, is the wrong place to
start.
Instead I would rather improve both user/group systems independently.

Again, I am still open for arguments prooving how an integration could
really work and not be bloated, despite all my practical and theoretical
doubts. I am ready to accept that may be my phantasy is not good enough to
envision a lean but powerful user/group-core engine serving all purposes.

Let that be an invitation :-)

> I would think it was really nice if I could write a plugin that can be
> plugged in at both sides - in the frontend or the backend, and made
> available to both kinds of users - or one kind if that was my desire.

Give me an example.

> 
> Robert Lemke writes:
> 
>> We had that discussion about roles several times yet.
>> 
>> Create a backend usergroup and name it "Editors".
>> Create a backend usergroup, name it "Content Editors" and add a sub
>> group "Editors".
>> Create a backend user being member of "Content Editors".
>> 
>> That's nested roles, isn't it?
>> 
> Yes. But I haven't found any evidence that groups can be nested in
> typo3. 

Backend yes, frontend not (yet).

>(Please don't answer this question if you feel that you are
> thereby giving me free support!)

Don't be silly. I find this discussion fruitful and I hope some more people
will follow this argument and let us know, what their ideas are about the
topics involved.

Cheers

Daniel


-- 
TYPO3 - get.content.right

Daniel Hinderink
Marketing, Press Relations, Strategy
http://www.typo3.com