[Typo3-dev] FE edit concepts

[Daniel Thomas]

Hi Christian,
and Robert

thanks for your reply. Your script already does a lot of the things I 
think are necessary for a general approach with fe-editing.

Let's have a look at a featurelist and see what is already there and 
how things that aren't should be implemented, after considering one 
general question. Your designed your script to be an API for other 
extensions. In order to give fe-editing to an extension the calls must 
be implemented in the extension code. I think it would be better to 
design the whole thing as a plugin of its own. The plugin is given the 
tablename and some TS-config and off you go. No need to change a single 
line in the code of the extension.

Features:
Multilang-support
Automatic field generation for defined TCA fields
Input validation by JS
Input validation by PHP
Templates for the main screens of the create/edit routines

If you agree that a plugin solution is the right idea, I think it would 
be cool to take your script make it part of a frontend plugin and 
extend it to meet the points mentioned above where necessary. And try 
to further the functionality of the script together from then on.

>> I would be interested in hearing your opinion about and discussing
>> A. what kind of workflow-integration a FE-edit function should provide
>> B. where the actual HTML should come from in rendering the FE-edit
>> processes
>> and
>> C. what the best technical solution for an integrated framework usable
>>
>> for future extensions could look like.
>
> Personally I think that an BE-extension providing this
> functionality, based on feEdit API is pretty good approach. This will
> allow for the genreal rendering / DB-handling stuff to be available 
> both
> for BE and as an ext-API.
>
>

I don't quite get the point of that. What would such a BE-extension do?

>
>> problems
>> how to deal with all those entry-wizards which are definitely not
>> accessible in the frontend?
>
> That might be a bit ambitious IMHO. First of all, most wizards are
> hardcoded to be rendered in the BE. And so you will need to recode all
> the stuff in order to have flexible rendering of it. Secondly, most of
> them, I think, will not make sense in the frontend. In other words if
> they need a wizard, they need a BE-login.
>

Same opinion. Wizards are BE-stuff.


Greetings
Daniel