Cocoon Forms rock - but - Most of my customers need
- the multipage-form: Moving applications from deprecated Cocoon 2.0 XMLForm to CocoonForms/ ControlFlow would be very easy then. - datatypes repository: there is a strong need for a central datadictionary. Most of the time you won't invent things for your own but have to integrate existing backends. In such situations you mostly have carved your types into stone and would just import them into your web environment (Cocoon). - calculated fields (virtual fields): even the shopping chart has to deal with the situation that depending on two values that go somewhere into an ordering system need in a displayed webpage a calculated field - default values: yes of course, and you need to distinguish between global default values and user default values - distinguish between edit and view mode: some design guides force you to make extra buttons to get into edit mode. - authorization of edit: not all users are allowed to edit all fields or even edit a a record. It mostly depends on the role of a user what is allowed and what not. Ok, thats what comes to my mind now. Some things I couldn't find on the wiki. Regards, Michael -- HoHoHo! Seid Ihr auch alle sch�n brav gewesen? GMX Weihnachts-Special: Die 1. Adresse f�r Weihnachts- m�nner und -frauen! http://www.gmx.net/de/cgi/specialmail +++ GMX - die erste Adresse f�r Mail, Message, More! +++
