[Typo3-dev] FE edit concepts

[Christian Jul Jensen]

Hi Daniel, list

Let me just throw it a couple of comments regarding the feEdit api.

First of all it's an API for extesnion programming, not a BE-ext for
rendering tables FE.

I have considered though, and I think it would be fairly easy to write
an extension doing this, using the API.


On Fri, 22 Aug 2003 09:21:51 +0200, Daniel Thomas <dt at dpool.net> wrote:

> julle_feedit - <comprehensive?>, <no workflow>, <script gets styles  
> from calling script>


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

This is definetely the ambition for the feEdit API, the extension uses
the same js-evaluation as the backend. But does not support all
TCA-types yet. File upload, probably beeing the most needed. And the
handling of MM-relations need to be revised.

The extension has been developed in a pragmatic way, extending
functionality with the needs for them.

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


Again it's not a backend ext. The API supports editing in the frontend
from login or email-link validation, or of course submitting without
auth. (actually a style pretty similar to the da_newsletter_subscription
ext)

If you want a true workflow, I think it would be wisest to build this on
the upcoming versioning in the core, since you need to have several
versions of the records, in order to have to have some kind of
backend-validation of the submitted data.

When that is done, it will be fairly to include some kind of workflow
'watching' records editted from FE.


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

True. Personally I hate working with HTML-templates. I know that Kasper
had some ideas on how to resolve this matter generally, and that will be
easily adapted into the API. I can't tell you more right now, sorry.


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

Stuff like this is always a balance between pragmatiscm and generalism.
Of course we all want make things as general as possible, but sometimes
that simply results in something so complex, that few people benefit
from it. But aas I said, I think this specific matter will be resolved
soon.


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


On Sun, 24 Aug 2003 21:54:09 +0200, Daniel Thomas <dt at dpool.net> wrote:

> Validation:
> I think validation would need to be based on the eval information 
> already given the TCA. Additionally, I think validation would need to 
> be done by JavaScript. That would be elegant and best from the 
> userperspective. In the end, this would mean to replicate the 
> TBE_EDITOR_... JavaScript parts of the backend for the frontend. I am 
> not that experienced with JavaScript controll functionality. If
> someone would like to support me there, it would be greatly
> appreciated.

I think I answered this already.

> Workflow:
> new entries should be publishable through the taskmanager. I will try 
> to do something in that direction and get back with more ideas.

That would be fairly easy, in the API you can force values on specific
fields ie. hidden.  My julle_externallinks actuaslly features a
BE-module doing exactly this.

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

-- 
Christian Jul Jensen
Freelance webprogrammer
TYPO3 typehead Denmark