[Typo3-dev] thoughts on the FE lib

[Daniel Thomas]

Hi Martin,

> Hi Danie!
>
>> I assume that the context of this mail is the discussion on how to 
>> deal
>> with FE-edit functionality.
>
> Yes. I had the impressions that some guys (you?) are working on 
> something new, so I wanted to share my invaluable insights ;-)
>

Yes currently I am working on something.

>>> - Don't make the lib rely on Javascript or any other client 
>>> technology
>>> for form preview/submission.
>>
>> A good solution must include both.
>
> Nothing's wron with JS and eg form validation. I was referring to the 
> fact that FE-lib uses JS to *pass*on* data (it uses empty  HTML forms 
> and an "update" script code).

Ok. You are right. The solution I am working on right now provides a 
plugin wich dynamically produces the input forms for any given table 
and passes those as templates to an adapted fe_adminLib.inc. This 
relies on JS for passing on data. right. Changing the current JS update 
mechanism into writing values directly into the fields might be tricky 
but should be possible. I will not have the resources to push the 
development into this direction right now, unless a sponsor or a 
determined client comes along. Would you (or anyone out there!) be 
willing to cooperate on this one in thinking up a solution which does 
away with the JS update system? If so I would gladly give you access to 
my development version and give you a detailled description of what it 
does.

>
>>> - Have "display values" for "text fields" and "bitmask arrays", eg
>>> internal values 0/1 are displayed as male/female or value 5 is
>>> displayed as "yellow,blue" given that bit 0="yellow" and bit 
>>> 2="blue".
>>> *)
>>
>> I do not get the point.
>
> Example: a field stores the sex of a user, 1 means male, 2 female and 
> 0 no value given or not applicable (eg for organizations). In the 
> current FE lib ###FIELD_sex### would display the numeric value (given 
> that the user got a select box with these values). But for preview I 
> want of course a (localized) string value. So I introduced something 
> like this: ###SHOWFIELD_sex###, which will display for this example 
> "male", "female" or "".
>

Right. The version I am working on already does that. If you have a 
multiple select and choose 2+ entries you get the values of your 
selection comma-separated regardless of their coming from an LL-coded 
itemlist or a relation-table.

> Do you get the idea now?
>
>>> - Allow upload fields to be previewed and changed **)
>>
>> The first step would be solution to make upload fields editiable 
>> again.
>
> Not so hard. Just have an additional  temp. field for every upload 
> field. Just make sure that any stale temp. files get deleted  and the 
> right one stored in its final location.
>
> It probably gets tricky when the upload field may contain multiple 
> files.

Yes. It is tricky. I do not altogether like the system I designed right 
now. It works like this: Every "file"-field has one file-input field in 
the form. If there are files stored in that field they are automaticly 
displayed as checkboxes. Click the checkbox and the file will be 
deleted from the db. Add another file via the input field and you have 
two files in the db. Right now there is still the possiblity to upload 
files to the system which will neither be linked to a record nor be in 
the /temp dir of the system. And in some click-combinations of refresh, 
preview ... files are even lost. As above, I would be glad to have 
someone willing to cooperate on this.

>
>> would you share the code you have written? I am currently working on a
>> overall solution.
>
> Sure, that's why I have mentoined it. I'll send you or anyone 
> interested the file in private mail. I'll post the rather small 
> changes for the SHOWFIELDS on the list.

Thanks for your input.

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

/--