[TYPO3-dev] [TYPO3-ect] Re: wich frontend libary to chose for cutom extensions

[Elmar Hinz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Edwin de Jong schrieb:
> Op donderdag 26 januari 2006 11:47, schreef Michael Scharkow:
> 
>>Evaluations should be maintained separately and only mixed in with a std
>>hook. We do have an eval API (although only rudimentary), and we should
>>use *only* that for field validation.
> 
> 
> Well, that would also be my first guess. There are however quite some 'basic' 
> form types that needs to do checking. Eg. if I were to add a 'Date' field 
> where people could either enter 3 numbers or select it from an applet, I want 
> to be sure the information I get back on the server is indeed a valid date. 
> Nevertheless, I wouldn't want my application logic to be bothered by that: my 
> application gets a good date, or it gets nothing.
> 

Hmmm, evaluations happen on different levels, if it is cleanly done. On client
side in JavaScript and on server side on different levels. On server side there
should be first the direct evaluation of the form data. In Java Struts HTML
Code, JS evaluation, the server side form data and checks make a bean, living in
a session. All that is still counted to the view.

On the level of the model (the application logic) input errors can be discoverd,
too, that are worth to be reported to the user. An example would be a username
registration where the username is already used. That can only be checked by the
model. Both the form errors and the model errors should give feedback by a
common error reporting system to the user.

> 
>>Since we have had this topic more than once (and I am still very
>>sceptical about making it happen), keep the requirements down and make
>>the thing modular. What do we have OO programming for?

Geschenkt!

> 
> Absolutely agreed, I see some people already coming with implementation level 
> ideas on the wiki. It's best to keep at design right now.
> 

Do you think of my proposal how to integrate the forms library with the MVC
project? That is not a definition of classes, but an overall structure.

A discussion about the interface of both projects is necessary. We find two
projects comming from two different sides, but both tend to cover the full stuff.

Have a look into so_mvc as an example:
<http://typo3.org/extensions/repository/search/so_mvc/details/?tx_extrepmgm_pi1%5BDATA%5D%5BshowFile%5D=gui_controls%2Fclass.tx_somvc_ctrl_check.php>

There you find a full directory of gui_controls.

> 
>>Some thoughts about real re-usability:
>>
>>1. A basic *low-level* form API that does nothing but render a form
>>element, just like the form helpers in rails:
>>
>>class FormItem {
>>	name = "";
>>	value = "";
>>	attributes = "";
>>
>>	function render()
>>	...
>>}
> 
> 
> I would say this needs to be a component of a larger system. Also, I'd like to 
> see this part to make somewhat more complex widgets as well, such as (again) 
> a date enty field or 'panel' (or sections, or whatever you want to call 
> them). Also, these widgets need to be part of a Listener pattern to be 
> effectively used in an MVC framework.
> 

I also see the advantage to have different levels of the API. I still don't see
that Michaels proposal needs a listener.

> 
>>class StringItem extends FormItem
>>
>>etc.
>>


>>2. A higher-level API that
>>* groups form items into fieldsets, multiple pages, etc. +
>>* provides controller functionality (submit, paginate, redisplay)
>>* adds a hook to the eval/sanitizing API
>>* returns the data
> 
> 
> What is a fieldset? Well, I agree that this should be a seperate component, 

<form>
<fieldset>
<legend>Text<legend>
[... labels ... ][ ... inputs ....]
</fieldset>
</form>

> but this is just the C in MVC. It is indeed the controller of our view. 

Why the controller?

> 
> 
>>This class will also help with
>>* prefixing the field names
>>* filling in default or submitted values
>>* applying the TS configuration to the low_level constructs
>>
>>3. Finally, we need a class that does the above automagically for a
>>defined model (=$TCA table definition), and adds some BE or FE-specific
>>functions,
>>
>>so that you can essentially write code like this
>>
>>$address = new TCAobj('tt_address');
>>if ($address->loadData($params['address']) && $address->save()){
>>	return "Saved data";
>>else {
>>	return $address->renderForm;
>>}
> 
> 
> Yeps, this was almost the level we had during the development of the Cocoon 
> Forms:
> DataModel m = new WhatEverModel();
> Form f = new AutoForm(m);
> try {
> 	f.show();
> 	m.serialize();
> } catch (lotsa exceptions) {}
> 
> But, on a sidenote, your input is really valuable. It would be great to see 
> some of that on the wiki page.
> 
> Greets,
> 
> Edwin
> 
> (ps. this project needs a coordinator, otherwise things start falling apart 
> because people have different views)

Without a coordinator it will not get far. Somebody needs to decide to take up
that position.

Without there will be done some conception in the wiki and then it stops. But a
conception is alread of a value itself as Kasper mentioned. You or others can
take it up again any time you like.

Regards

Elmar


- --
Climate change 2006 is killing people: floods in California, drought and fires
in Australia, Texas, Sahel, Oklahoma, South Africa. The Bush administration is
responsible for corruption of the Kyoto Protocol. The US majority is responsible
to the world for reelection of a convictable [...censored by Echelon...].
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD2b4DO976RNoy/18RAjv7AKClr67q0AvmbYZodMhS/Vpv8NsurwCeNBIS
5XM3zCTrh5Hh3RTOgcfZ2RI=
=w7fS
-----END PGP SIGNATURE-----