[Typo3-dev] FE edit concepts

[Daniel Thomas]

Hi Robert,
thanks for your detailed reply.

> Hi Daniel,
>
> Daniel Thomas wrote:
>> 1. comprehensive
>> we need a solution which will pretty much mirror the possibilities of
>> the forms in the backend. Fields which are defined for the backend
>> must be editable in the frontend as well. I am not exacty sure where
>> we stand here with regard to fe_adminLib and julle_feedit. Does
>> someone know the exact status (especially in terms of how input
>> evaluation is integrated in fe_adminLib)? Otherwise I will try to
>> come back to this myself in the near future.
>
> I didn't work with julle_feedit yet. It's true that fe_adminLib 
> provides
> some
> nice functions to render certain fields automatically. And a nice 
> thing is
> the
> evaluation routines. They are meant for the original task of this 
> extension,
> frontend
> user administration. However you can easily expand the features or 
> include
> userfunctions for pre- / post-processing, evaluation and such.
>
> But I only see some parallels, some functions you might use. I wouldn't
> extend
> this extension in order to get a sophisticated frontend editing that 
> you
> plan.
> You won't want to configure every field with TS but rather take the TCA
> configuration for the backend fields, right? (or both)
>

sure. in order to be applicable in many applications the information 
about what a field is for and what its restrictions are must come from 
the TCA.

>> 2. workflow
>> the fe_adminLib has some kind of workflow integrated by the
>> emailnotifications with commandlinks. That works very well. However,
>> it is not the most transparent solution. I mentioned fe_news above
>> because it integrates the publication of news added in the frontend
>> into the task manager of the admin user. In my opinion this is the
>> better solution.
>
> I wouldn't call the functions in fe_adminLib a workflow. Basically 
> it's only
> about
> sending infomails and getting authentification - although you may 
> provide
> userfunctions
> here and there.
>

you are right. workflow is a bit pompuous for what I mean. But still. 
FE-edit needs the option that new entries are reviewed by some 
authorized user before they are actually published. And with regard to 
this I do not think that the email-way is the best solution. do you?

> Comparing the fe_adminLib and fe_news is a bit like comparing apples 
> and
> oranges,
> but what they have in common is some frontend editing functionality, of
> course.

Sure. I only brought the fe_news in, because it integrates the 
publishing mechanism with the task manager. Which I find appealing.

> However, the fe_news is nearer to a frontend editing solution 
> rendering TCA
> fields than the fe_adminLib.
>

? I don't find any reference to the TCA in the plugin class.

>> 3. templates
>> the fe_adminLib needs the calling application to provide an
>> HTML-template in order to render the forms. julle_feedit provides the
>> HTML for the forms formatted by the calling application's stylesheet,
>> right? Now, the first approach gives a maximum level of control over
>> the way things look; the second a more lightweigt access to the wanted
>> functionality.
>> There is a general question behind this: Do we need a designwise much
>> more flexible approach for creating forms in the frontend than in the
>> backend? Or: How likely is it that a somehow standardized approach
>> will cause a major problem because its look can not be fully adapted
>> to a given design?
>
> That depends, of course. But I personally see the neccesity for using
> templates
> (of whatever type the might be) since there are some special needs in 
> every
> projects. For me the FORMS cObj is a bit too restricted in it's
> possibilities.
> At least I'd like to have the choice: Template file or automatically
> rendered.
>

I agree. Undoubtedly, it is more work implementing. Maybe it can be 
rigged up to work with a comprehensive set of Standard-Templates which 
are adaptable if someone would like to adapt them. see more detailed 
below.

>> I would be interested in hearing your opinion about and discussing
>> A. what kind of workflow-integration a FE-edit function should provide
>
> If you want the backend forms in the frontend, you'd have to integrate 
> the
> workflow functions as well. But I see it as some task running in the
> background
> unless the fe user has the right to modify his workflow.
>

I am not thinking of having a workflow-mechanism running in the 
frontend. As above:
New item => task manager entry for a be_user => publish by be_user
Something like that.

> However, if you want to create an extension that renders any backend 
> forms,
> you can implement whatever you like. It's more a question about how to 
> use
> the
> TCEFORMS and TCEMAIN functions for the frontend output. That's no small
> task I guess.
>

No backendforms in the frontend. But, of course, the question of the 
templates is the question how an automatic form generator for the 
frontend could look like. In the backend the TCA gives access to two 
dimensions of field-arrangement. standard fields and palettes. the 
fe_adminLib just renders any given fields consecutively. From my 
perspective much could be gained by integrating a standard set of 
Templates into the fe_adminLib. Standard templates of two kinds:
screens - like a whole edit form, a whole create form, a list view ...
fields - a series of possible inputfields
because right now if I use the fe_adminLib in serveral extensions I 
have to rewrite a lot of more or less identical HTML-templatecode in 
each extension. Do you think that could be done? the fe_adminLib does 
not get the template but only the table and fieldname and some kind of 
magical process renders the forms with info from the TCA.

I think it necessary to consider the possiblities of form-design for 
the Frontend, because we have a much greater need of being able to 
enter information inbetween the formfields. be_user usually get an 
introduction to the backend-forms they will be using. the fontend only 
knows dummy users and entry-forms might need explanation. that's why I 
think there must be the possibility to add custom information to the 
form-fields which goes beyond the configuration and ordering of the TCA.

>> C. what the best technical solution for an integrated framework usable
>> for future extensions could look like.
>
> Well, I hope I understood you idea. You want to have an extension which
> renders
> Lany backend form for frontend editing. In my eyes that would be a 
> mixture
> of
> the backend form rendering functions and something like the 
> fe_adminLib (an
> approach to configure fields via TS).
> Additionally that extension could provide an API for other extensions.
>

Yes.

> -- 
> robert
>
>

already waxing your board?

daniel

--/

Daniel Thomas dpool

Hinderink und Thomas Partnerschaft IT-Berater und Projektmanager

Isartorplatz 5 | D-80331 München
t 08912018917 | m 01793918781 | eFax 02561959115820

http://www.dpool.net | http://www.typergy.com

/--