[TYPO3-hci] Combine page and list module into one module

Franz Koch typo.removeformessage at fx-graefix.de
Wed May 14 13:23:22 CEST 2008


Hey Dmitry,

>> It isn't. Why should every extension provide it's own way of managing 
>> records? This is the worst you can do and truly doesn't reflect the 
>> sense of a content management system. The CMS itself has to provide a 
>> default, easy to use way for managing records. In TYPO3 the only way 
>> to do this is the list module. Unless there won't be provided a better 
>> solution by default - this module should be enhanced to be userfriendly.
> 
> No, it is wrong. Because extension is the only one who knows how to 
> present its records best. For example, news should not be edited like 
> records, they should be created using wizards and modified as news not 
> as database records. Gallery images may have graphical controls to 
> resize or crop them or add effects. User records should be shown in a 
> better way. For example (sorry, not in English):
> 
> Edit user: http://www.calis.lv/lietotaja-centrs/cforum/edit/571/
> View user info: http://www.calis.lv/lietotaja-centrs/cforum/info/571/
> 
> We usually have it in FE and similar should be in BE. "Records" is not a 
> user-friendly approach.

I agree that the list module is not really a good way for editing 
records - but there is nothing else provided by core. And you're right 
that some records need special treatment and visualization for better 
handling - but if BE would f.e. provide a MVC style module (or service 
based) for editing records, where each record-type (model) could have 
it's own view subset (like how it looks like in list mode, in preview 
mode,...) and could set some configuration options of default view types 
(like how many items should get listed in one row, or whatever) - there 
would be a consistent way of editing records while each record-type can 
have it's own specialization. But as long as nothing of this exists, we 
have to deal with the list module and at least try to make it a bit more 
user friendly.

>> Who said that is has to be hardcoded? Provide a TS option to configure 
>> it and everybody is happy.
> 
> Option already exists. You can hide unwanted tables. Read TSConfig.

sorry - haven't seen it.

>> sorry - I can't agree here by any means. Only because you got used to 
>> something it doesn't mean that you like the way it is, nor that you 
>> won't be much happier if it would work in a different, better way.
> 
> I do not see it as better way. You can't remove functionality if it is 
> used by people until you provide truly better alternative. So far you 
> didn't.

Maybe I should clarify my statement to the original posting - as I just 
dropped in without explaining my point of view.
I haven't said that I fully agree with the original suggestions, but I 
agree that a combined view (meaning a view that is automatically 
switching from page to list module for pages and sys-folders) is a 
improvement in usability for the average editor. I don't agree to make 
it default or to remove list-module completely. So what I'd like to see 
is a new module (or some TS-configuration for the pagetree) providing 
the functionality of a "combined view".

>> And it should not be implemented, just because we can. It should be 
>> done in terms of usability - which if I might remember you is the goal 
>> for the 4.x branch. And the decision whether it's useful or not should 
>> not be done by geek-devs. Surely devs know how to use this - but not 
>> the average editor - and that's the reason why there has to be done 
>> something. If everybody would be a geek - we wouldn't need a CMS.
> 
> This is not usability - this is limiting people without any real reason. 
> If you do not want use List module - don't use it. Or hide tables that 
> *you* do not want to see there. But don't tell me to go your way. I do 
> not want.

I totally understand your point - and you should not have to. It should 
be optional/configurable (see above).


-- 
kind regards,
Franz Koch


More information about the TYPO3-team-hci mailing list