Hi Ralph It depends on what you do in your application and how.
If you do lots of custom rendering, have written your own CForms Widgets, stuff like that, then yes, it will probably have an impact. If your application uses the standard rendering pipelines, standard widgets etc. then the impact is likely to be nil, or small.
The most likely effect it will have is on forms where the user has specified a specific dojo widget in their template, instead of having the rendering pipelines produce it for them. They'd have to add the correct namespace prefix.
Some of the newer widgets like CFormsRepeater, CFormsDragAndDropRepeater etc. do not have XSLT that generates them from CForms stylings.
eg.
<ft:repeater id="contacts">
<div dojoType="CFormsRepeater" orderable="true"
select="select">
. . .
would become :
<ft:repeater id="contacts">
<div dojoType="forms:CFormsRepeater" orderable="true"
select="select">
. . .
IMHO this is a small price to pay for the advantages the new codebase
will bring.
regards Jeremy On 3 Jan 2007, at 01:20, Ralph Goers wrote:
Jeremy,Does this break binary compatibility? Some of the changes sound like users who upgrade from 2.1.10 to 2.1.11 may have to modify their application? If so, I see that as a problem.Ralph Jeremy Quinn wrote:Hi All A lot of work is being done on CForms for the 2.1.11 release.It may be a bit disruptive temporarily to users' projects, but IMHO it will be worth it.What if all you do is write a few simple forms and use the standard form-processing pipelines and xslt? There will be very little to do to move to cocoon 2.1.11 as most of the changes are handled by those built-in resources.
smime.p7s
Description: S/MIME cryptographic signature
