[Typo3-dev] FE edit concepts

[Robert Lemke]

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)

> 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.

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.
However, the fe_news is nearer to a frontend editing solution rendering TCA
fields than the fe_adminLib.

> 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 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.

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.

> 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.

-- 
robert