[TYPO3-hci] BE vs FE

Tapio Markula tapio.markula at dnainternet.net
Mon Jul 31 16:56:13 CEST 2006


Waldemar Kornewald wrote:


> What we're after is not necessarily a community CMS. All we need is a
> way for users to create an account, so they can access our bug tracker

because typo3 community has that feature, that should be possible to 
create also for your site

> and possibly be granted access to special website sections and maybe
> the backend. 

that can be done with some plugin,which can give fe-users also right to 
edit backend

We don't need people posting to our blog and we don't
> insist on allowing users to add comments, though it would be nice,
> sometimes.
> 
>> 1. If you need a system to manage web pages in many languages, with
>> flexbible templating, on-the-fly image manipulation and all that, then
>> TYPO3 is for you.
> Yep, that's what we need.

Then Typo3 is good - but you must accept that users can put contents
in the same place into sevaral places. Honestly splitting contents into 
smaller junks is good because they can be easily moved using backend 
drag'n drop feature or copy/cut/paste -method.

http://t3test.xetpoint.com/media/development/backendediting5.png
(without text among icons possible with some other plugins too)

It is possible to build for Typo3 tailored frontend - but it misses at 
this moment AJAX and copy/cut/paste -method moving contents.
If I would have enough skills I would add them. Moving content elements 
from place to place in frontend could be better.

> We only need user-registration for single-sign-on.

there should be an extension for this task

> The question is: how much flexibility is actually reasonable? Many
> people want more than they need and most projects can't stop adding
> new features because they think they have to make those 0.001% with
> very uncommon needs happy.

well in some project I must have done quite many content area - 
advertisement bureous made me quite complex layouts, which needed
up to five different content areas in a page with different content 
types. The flexibility is really needed!

  > This still doesn't explain why you should separate them. That's bloat.
> A simple flag or role could definitely do the same. And there is
> definitely no reason to disallow BE users from accessing the FE

Certainly is, if some page section is only for certain FE groups.
Those pages should be restricted accessing both frontend and backend users.
Disallowing *must* concern both pages in fronend and backend!

> disallowing FE users from logging to the BE makes sense, but this can
> easily be solved using permissions instead of building a whole new
> concept. The point is that it's a lot more complicated than it has to
> be.

you are right here

>> 6. In-place (or FE) editing might sound like a good idea for small
>> sites, but it sucks for everything that has no direct representation in
>> the page, and it sucks for training of editors. Unless the structure of
>> content input is trivial (like in Wordpress), there's no use in mixing
>> your site layout with content input.

> Yes, that's a good point, but the real problem is that it gets more
> difficult to create a skin if you have to support FE-editing. It's not
> impossible, though.

skins are in Typo3 only for backend - it doesn't even support skinning 
for frontend editing icons (this is however easy to fix and using one 
extension it is possible to define your own frontend editing icons).

Because typo3 has huge number of icons, there is just few skins for backend.

You can however put into frontend
basic editing features + links to Web > List module to edit such
records, which don't direcly relate with frontend editing.
(toolbar has that link as default and it is in the admin panel).

You can easily edit all content elements in frontend . If there is in 
some page news etc. you can add also easily news, address records and 
calendar items from frontend. Also banners can be edited from frontend.
In principle it is possible to edit any record, which can be shown in 
frontend using frontend editing capabilities. Many plugins have those 
capabilities, but not all or the support is very limited. Plugins could 
in overall support more frontend editing (I have added frontend editing 
into some plugins).

> But I'd be fine with a backend for editing content as long as it works
> without me having to think about it.

what you think about this
http://t3test.xetpoint.com/media/development/backendediting5.png
what you want to change?
What you want add/ take off?


>> 7. News, forums, blogs are *not* the first thing I'm installing in TYPO3
>> because they are more complicated to set up and have less features than
>> most dedicated frameworks.
> 
> 
> Yes, they are too complicated to set up. 

there has been discussion about this - it would be possible to put 
fields for necessary configuration, when the plugin could work 
immediately after installation (some simple plugins work really 
plug-and-play).

tt_news don't never work immediately - but it would be possible to make 
a switch, that it would work immediately after defining basic 
configuration - or it would be possible to setup it later.
The issue is that designers don't thing issues *both* at the sight of 
newbees *and* advanced users.
This is just an issue of proper plugin development.



More information about the TYPO3-team-hci mailing list