[Typo3-dev] Re: The future of Typo3

[Michael Zedeler]

Hi everybody,

It seems that people are still willing to talk to me. I'll put all 
answers in this single mail.

Hannes Schmidt wrote:

>Actually, the separation between FE and BE is what Typo3's flexibility is
>based on. As a rule of thumb, separation is generally a good thing. Besides,
>separation doesn't make code reuse cumber-some, as you say.
>
I haven't said that it was the case in general. Only with regard to what 
I have seen of typo3.

>As an example
>from OO-programming, take two separate classes derived from the same base
>class. They are separate and yet share code. In general, separation of
>design entities forces developers to make clear distinctions and define
>precise interfaces. And this is what makes code maintainable and flexible. I
>think Typo3 has it's weaknesses (documentation, consistency), but what you
>are criticizing as a weakness is one of it's greatest strengths.
>
I think we agree. In my first posting I wrote something along the lines 
"away with the backend". I think that I didn't do a very good job at 
explaining my intentions then, because it is not to be understood 
literally.

Please let me point out once and for all: the backend as logically 
separate application is nice. Rebuilding it to work as it is today on 
top of a large amount of shared libraries would be nice. What I don't 
like is two different codebases that only have the database in common. 
Take a look at this figure: michael.zedeler.dk/typo3-modules.png

When I write "thin" I mean really, really thin. Basically just two 
different index.php-files residing in different directories taking up a 
few hundred lines each. To perverts like me, it means that I would 
easilly be able to transfer nice functionality from one "end" to another.

>BTW, paradigms cannot be dead. If it's a paradigm, it is by definition
>immortal. 
>
Sorry paradigms :-)

Thomas Svenson writes:

>Even if everyone is stored in the same table(s), it is easy to identify
>certain standard roles.
>
>For example:
>  - Main Administrators (those who will have access to everything)
>  - Section/Department Administrators
>  - Developers
>  - Content Editors
>  - Members
>  - Anonymous
>
>New roles must be easy to create. It should also be possible to make one
>role a member of another role.
>
This is the sort of stuff that I would be really happy to see in typo3.

Many of the mechanims for most of what you write is already there - you 
can add what assigns the role-specific rights to the typoscript 
configuration of a group and the just let people be members of that 
group if they are supposed to have that role. Implementing stuff that 
looks in the typoscript configuration for permissions is another story 
that has not been made. The same goes for nested group memberships.

>BackEnd/FrontEnd
>----------------
>I have noted in the thread that there are different opinions about if it's
>best to have a BE/FE or just one integrated system. I very much favour the
>BE/FE model. I agree that code/features can be shared between them.
>
Please note my comments regarding this subject above. I believe in a 
separation towards the users and to the degree that the two applications 
can be deployed independently.

>>
>>> One thing is interdependent modules another thing is modules using the
>>> same libraries. I hope it is clear that what I was writing for is the
>>> latter, not the first.
>>    
>>
>
>That is exactly what Daniel Thomas is proposing and has already created much
>of it. The RFC and the extension wilol be published soon.
>
Thank you for the information.

>
>Again, I agree that a more complete, rather than generic (?) concept is
>needed. I am for it because it is needed, however I do not draw the same
>conclusions, like one table for all users, etc.
>  
>
I may be a little slow, but it seems that I have completely missed the 
reason why separating the two kinds of users is supposed to be a good 
idea. What I have heard so far is:

    * Sheer volume. There may be thousands of front end users and only a
      few back end users. Finding the back end users becomes difficult.
    * Security. Putting the two kinds of users in different tables
      provides extra security.
    * Purposes/separation. The two kinds of users will almost never
      overlap and are used for entirely different purposes.

I don't subscribe to any of theese standpoints. Which ones do you 
subscribe to, and have I missed some?

My arguments against each of the points are:

    * Volume.
      Not a problem if using better filtering and searching in backend.
    * Security.
      Relative increase in security is not _substantial_ by using
      different tables and I doubt it ever will be.
    * Separation.
      I subscribe to a different paradigm. I want to put much of the
      power of the backend in the hands of front end users.

Didier Geheniau writes:

>Re-think the concept of authentication and authorization.
>
>A user is one person, this person can access the front-end and the
>back-end. By login in with a user account he is authenticated as the
>right person.
>
>Groupmemeberships gif him the authorization to do things. It doesn't
>matter if you split the backend and the frond end. You can always define
>backend groups with backend rights and frond end groups with front-end
>rights.
>
I couldn't agree more.

Regards,

Michael.