TYPO3 Core

Hi Thomas,

I'm sorry but I cannot look at this. However if you write a patch, I would be happy to get back on it.

- michael

Hi,
on which version the patch should developed? The 3.8.0 or the 3.9.0dev? I will see how I can help...
Has anybody an idea what will be the best way of integration? Maybe via TYPO3-CONF_VARS!?

Please show me a direction how you would like to see it implemented. :-)

Greets,
Thomas

Hi,
it doesn't matter - you can do it as you like it. We take paches for 3.8 and CVS.
Greets, Sebastian

Hi,
Is just uploaded some patchfiles that implements this to TYPO3 Version 3.8.0. I don't know if this is the way it should be but it works for me so far. ;-)

I did it that way, that you have to configure your evaluation methods via TYPO3_CONF_VARS['EVAL']. The evaluation stuff itself is placed into an own class which returns the JavaScript the provides a method for validating when the tceform is saved.

I also uploaded an example implementation as extension. It would be nice if you can give some feedback on this. If it should be implemented in another way or if it is completely crap.
If you have any questions mail me at thomas (at) typo3-unleashed.net.

Greets,
Thomas

P.S.: I'm sorry that the code isn't indented with tabs. I'm using emacs here and I hadn't another editor for correcting the indentation. :-( Hope it's okay anyway...

Hi Thomas,
I just looked at your patch, this is is quite interesting! I just have some questions to make sure I understood it correctly: You have two parts for a custom eval function, one which is implemented in JS, and the other one which can be implemented in PHP, is this correct? Is it also possible to make a JS-only or a PHP-only evaluation?
I like that the evaluations for PHP and JS are in the same place here, I think this is really clean. Good idea :-)
Maybe your "hooks" need a small cleanup, one thing I noticed is that you called getEvaluationJS without checking if the function is available. This might not be needed, but it is more safe anyways.
How would you call your custom evaluation from TCA then? Just like tx_exampleextraevaluations_extraeval1 in the "eval" field of the TCA array?

Thanks for your effort, Sebastian

Hi Sebastian,

yes you're right. The build in evaluations also using two parts. If you enter a date, the corresponding JavaScript method converts it into a valid date format. And the PHP method reprocesses the data from the form field that it fit's the database. (Converting from date to timestamp for example)

Making PHP or JS only evaluations is currently possible through leaving the methods empty, or just return the input value. But checking the exitence of a method might be a good idea to make sure that no fatal erros occur.

The call in the TCA is likely the same as calling the normal evaluation methods. The only difference is that you have to prepend the method with the identifier you have defined in you ext_localconf.php seprated by ";".
Maybe it would be cleaner if we say, the identifier has to be the extension key of the extension that provides the evaluation method!? As an exmaple, you can call a user defined by adding "tx_myevalextension;myfancyevalmethod" to the eval field in the TCA.

I hope that makes it a little bit clearer. ;-) If xou have any question you can also reach me at thomas (at) typo3-unleashed (dot) net.

Greets and thanks for your interest :-),
Thomas

Hi Sebastian,

deine eval api klingt auf jeden fall sehr interessant...

Danke :-)

hältst du es für realistisch auch die bisherigen evaluations darüber zu
machen?

Vom technischen Standpunkt ist das kein Problem. Ich bin momentan aber
noch nicht ganz glücklich mit der aktuellen Implementierung des
JavaScripts. Wobei sich das leider kaum ändern lassen wird, fürchte ich.
Zur Zeit wird für jede Evalmethode eine JavaScript Funktion erzeugt, in
die dann das eigentliche JavaScript aus der EvalKlasse eingefügt wird.
Dieses Script wird dann bei der Ausgabe der TCEForm einfach mit ausgegeben.
Da dieses Aufrufen und Ausführen natürlich dynamisch bei jedem Aufruf
geschieht, werden natürlich auch die Systemressourcen entsprechend
belastet. Ich fände es daher taktisch eher nicht so klug die bereits
statisch eingebauten Methoden auf diesem Wege umzusetzen.

Achja, was mir noch einfällt: was passiert bei evaluations, die nur
serverseitig ausgeführt werden? Sowas gibt es IMO auch, oder täusche ich
mich da?

Also nur Serverseitig ausgeführte Methoden hätten ja kein JavaScript.
;-) Dann wird der Wert der aus dem Formular kommt, von den PHP Methoden
ausgwertet und eventuell verändert wieder zuürck ans System gegeben.
Dieses speichert den Wert dann in der Datenbank. Da dies beim neu laden
der TCEForm erfolgt, wird dann der neue Wert aus der Datenbank
angezeigt. Ich denke also nicht, dass es da irgendwelche Dinge zu
beachten gibt. Ich bin mir gerade aber auch nicht ganz sicher, ob es
bereits eingebaute Evalmethoden gibt, die nur Serverseitig ausgeführt
werden.

viele Grüße,
Thomas

Hi,
you had some concerns about the way the current JS functions are added in the eval API. What do you think about generating a JavaScript file with PHP, implementing all custom evaluations? Currently, we include jsfunc.evalvield.js in the HTML body with script tags... Why not include a new PHP file called jsfunc.evalfield.php as JavaScript? (So the PHP generates the JavaScript...) As JavaScript is mostly cached by the browser, there shouldn't be performance implications.
I don't like having two different implementations available for the evaluations, IMO it would be a lot nicer to have them in one place...
One more thing I just thought of - maybe it should be possible as well to provide multiple evaluations per file/per class, to make it easier to implement the current evaluations without needing lots of eval classes.
I'm interested to hear your thoughts about this!
Greets, Sebastian

Hi,
I think that would be good idea. A js-evalfunc.php would make it much easier to implement the evalAPI JS stuff. ;-) I will see how this could be done. Or if you have any hints, contact me. :-)

Currently it's possible to have more than one evalclasses in one file. To have various eval methods in one class the patch needs some modifications but I think that shouldn't be a big problem. :-)

And you're right. Implementing one thing in different ways isn't a good thing at all. I will make a patch that implements all the current eval stuff with the eval API.

Greets,
Thomas

I just added version 2 of the patch which moves the evaluations from inside the system to a system extension (evaluations).
The System can now handle some more things than in the first version. (More than one method per class and inserting of basic JS for a class)

The file t3lib/jsfunc.evalfield.js is not longer needed because it is provided by extension "evaluations".

Greets,
Thomas

Hi guys,

this one looks like a really useful feature I have been waiting for a
long time.

I just looked at the patch and tested it briefly.

Here are some comments.

----------------------------------------------------------------
instead of...
$TYPO3_CONF_VARS['EVAL']['myext']['extraeval1'] and accordingly
"myext;extraeval1"

...make it:
$TYPO3_CONF_VARS['EVAL']['tx_myext_extraeval1'] and accordingly
"tx_myext_extraeval1"

...because it makes it simpler and doesn't have any disadvantage

Sysext "evaluations" should be called "formeval" because it then
explains that it is about
form evaluations.

Files in the config array should be referenced using
EXT:myext/class.tx_myext_evalcalss.php syntax resolved using
t3lib_div::getFileAbsFileName().

I would like to remove the hack for evals from the sysext "evaluations"
because if we have a workaround for the old evaluations, we could just
as well have left them in their original place. I think they should work
exactly like any other evaluation using the API.

So I'd remove this chunk of code:
+ } else {
+ // eval methods from sysext "evaluations"
+ if (!t3lib_extMgm::isLoaded('evaluations')) continue;
+ $classPath =
t3lib_extMgm::extPath('evaluations').'class.tx_evaluations_methods.php';
+ $className = 'tx_evaluations_methods';
+ }

The only difference between evals of the "evaluations" sysext will be
that they don't have
a prefix like tx_evaluations_trim but will be called just e.g. "trim".

$TYPO3_CONF_VARS['EVAL']['trim'] = array(
'file' => 'EXT:evaluations/class.tx_evaluations.php',
'class' => 'tx_evaluations',
'method' => 'trim'
);

Kickstarter should be able to create new evals (it should have a new
section "Form evaluations").
Those new evaluations should directly be selectable for fields of the
"New Database Table" and "Extend existing table" section of the kicki.

OK, that's if for now.

Keep up the good work!

cheers,
Ingmar

Hi Thomas,
I got some suggestions on the topic, and I hope you can implement this.
That would be great!
Thanks, Sebastian

I just uploaded a new version, with some of the changes that where proposed by Ingmar.

Please have a look at the exampleevaluations extension. I made some changes in the registration (see ext_localconf.php).

Greets,
Thomas

Hi guys,

I just committed a rewritten version of the patch to TYPO3 4.0 CVS, so you'll find the eval API in TYPO3 4.0RC1 and later versions.

cheers,
Ingmar

You can download an example extension here:

http://typo3.org/fileadmin/dl/T3X_example_extraevaluations-0_4_0-z-200603260125.t3x

We tried this today, and it seems the returnFieldJS() is never called - it doesn't even work with the test extension as downloaded from typo3.org (version 0.4.0). Can anyone confirm this as working with the test extension? Or did we do something wrong?

I just tried the example extension on a TYPO3 4.0.1 Installation and it worked just great.

I entered the value "test" in the field and the result was "test [added by JS] [added by PHP] ".

Karsten, just have a look at my patch attached to this bug in order to see at which point returnFieldJS() is called!

cheers
Ingmar

Hi, I just checked and it worked for me with the test extension. We'll dig further into the problem to see why it doesn't on the other machine... :/

Thanks for the info!

cheers
Ingmar

We tracked it down, there is an incompatibility with erotea_date2cal - if that is installed, the eval API breaks, probably because that extension overrides a/the method where returnFieldJS() is called...