[TYPO3-hci] BE vs FE

[Ernesto Baschny [cron IT]]

Waldemar Kornewald schrieb am 31.07.2006 12:46:

> Why is there a separation between frontend and backend users? Can't
> there just be a flag telling whether a user gets access to the
> backend?

This has historical reasons, maybe the "partner framework" will enhance
that part so that TYPO3 has more "community" features where this is a
requirement.

As Michael already wrote, most TYPO3 sites don't require frontend users
at all, because they are not community sites, and if they do, those
users mostly have nothing to do with the content editors.

> Everyone should get access to the frontend. We want users to
> register themselves to get access to additional services. For example,
> we use Trac for bug-tracking and we want single-sign-on, so our CMS
> should manage the user accounts. Or we want to restrict who can access
> certain pages. In that case, our backend users must browse the
> frontend.

Those all sound like FE-users, and this is what they are there for already.

> I think that we should finally get rid of this "backend" concept. AJAX
> makes this possible. Backends are more difficult to understand. What
> speaks against only having a frontend and showing simple "Edit",
> "Items", and "Admin" buttons in a simple bar at the top of every web
> page? Instead of the current scheme where your page consists of
> individual "segments" everything could become WYSIWYG-based. You could
> add forms and plugins right into the editor and configure them
> visually. Pages should become the central concept.

As TYPO3 is "just" a framework to access database records, you might
also have records that have no representation in the "frontend". To edit
those we have powerful capabilities in the backend. And how do you want
to admin users, extensions, see the logs, edit typoscript or have access
to other modules/extensions that have no real FE-output?

I think the separation makes sense, and we only need FE-administration
of a small sub-set of the tasks being done, which is content editing,
which is already possible with FE-editing. So we might try to improve
the FE-editing a bit.

> I understand that a page tree is a nice abstraction, but manipulating
> your site in-place is even better because there is no need to abstract
> anything. Also, the current "items" concept (page list-view) is nice,
> but isn't normally a plugin needed to store items? In many cases it's
> probably better to allow plugins to add special actions to the website
> (when logged-in) and let plugins manage items. For example the news
> plugin could add a "manage news" button and take care of all news
> items. Where this data is actually stored should not be exposed to the
> user, but you should still be able to say that your news plugin should
> use the same data store as the news plugin on some other page (so you
> can have a news summary on the front page and a separate archive
> page).

The data records has to be stored somewhere, and I think TYPO3 wouldn't
be so great if every extension has to do everything on their own. TYPO3
already takes care of data records, so a "usual" FE-plugin doesn't
require any BE-programming, just to set some TCA configuration and you
are done and can program the FE-plugin.

Its up to the site admin to simplify the life of its users by minimizing
the interface based on their specific requirements. For news generation
there is the often unknown "actions", which provide some easy shortcuts
for your content editors.

> The biggest problem of today's CMSes is that they expose their
> implementation details to the user. IMHO, all tasks should be
> performed *directly* and *in-place* instead of splitting them accross
> implementation details like folders/containers. E.g.: why do you
> separate news items from news plugins? One can't live without the
> other, anyway. If something belongs together then it should be put
> together.

Well, in case of the news, we could say the opposite: There is a news
source and there are hundreds of plugins on multiple sites where they
are being used/displayed (some filtering by category, others displaying
a LIST view, others the LATEST in a side bar, etc).

Why would a news author have to know exactly on which pages they want
the news to be displayed, if he could just create the news in the
SysFolder destined for it and have that automatically be displayed in
all places where it might be relevant? Create a single "action" for
doing that and a new news can be added with one click without the user
having to know where it is stored.

And if you want the news stored in the same folder as your (maybe only)
plugin, you can also do that, its a matter of setting up tt_news.


Cheers,
Ernesto