[TYPO3-hci] BE vs FE

[Tapio Markula]

Waldemar Kornewald wrote:
> On 7/31/06, Tapio Markula <tapio.markula at dnainternet.net> wrote:
> 
>> > This is not a big problem, is it? I could break HTML or wiki tags in
>> > any other system
>>
>> if you have [news] how you would configure it?
> 
> 
> For example:
> [news:item_count=5:mode=summary]

ok - but this needs for normal users skills of admin users
and can offer to be reasonable quite limited config

>> 1) Adminstartor could have any possibilities to control,
>> what users can put, if they use markers - users needs just to know
>> available markers and then they could put anything to any place
>> - also places, where should not be any content


> But this is restricted to the page level, not the skin level. I.e.:

ok - in priciple possible to delete afterward markers

> you can't remove the navbar if it's not part of the page.

but if it is - if nav bar is needed in the *middle* of the content areas
or between two contents.
content - navbar - content
I have had this kind of situation!

> Also, the
> system could check which markers existed before and disallow removing
> and adding markers.

> Another possibility is to have a more powerful editor which is *only*
> WYSIWYG and which can make some parts of your page non-editable for
> some users, etc..

I can't see that possible if everything is *one* record.
If template has several content areas restrictions are possible.

> Alternatively (as a short-term solution), you could still split the
> page into a layout (with a nice visual table editor) and then put
> WYSIWYG content into each individual cell or choose to add a module
> into that place, instead. At least, with a nice table editor this

> would not be as unintuitive as with records. The number of different
> record types should be kept as low as possible:

it is possible in Typo3 - you can limit quantity or record types.


> That should be all. Anything else can be implemented with modules.
> By default, every cell is of type text and the default page has only
> one big cell, so you can get started immediately.

layout disigners would not like that

> The skin itself is a layout, too, so you can show the navbar on every
> page or override the default layout by choosing from a list of other
> layouts or defining your new layout in-place.

but I can't see a way that everything is in one record

>> 2) If all is in a one content record users could *totally* destroy
>> the template - including navigations, if navigations is among contents
>> (for example in the middle and left). Layout designers loose the whole
>> control!
> 
> 
> Normally, content like the navbar is not part of your pages, but
> belongs to the skin or main layout.

not necessarily - I have done many implementations, where navigation is
in several places. In pratise you sheme allows quite limited 
possibilities. Basically one content area, which you just divide how you 
want - that is not in many cases enough!


> 
>> 3) Impossible to configure individual plugins (generic configuration and
>> page level possible but not for indidividual plugins).

> In my suggested scheme it's possible. Skeletonz and MODx do it that way.

vulnerable - and in practise offers quite limited configurations.
The most serious issue is just vulnerability and limited possibilities.