Godefroid Chapelle wrote: > Balazs Ree wrote: > >>> My suggestion is to just to leave them in kss.core so that we can >>> deprecate them at some later time. >>> >> The AddHtmlParam and AddStringParam, besides implementation reason that >> may occur differently in the case of kss.base, have a very important >> function. We do not only handle these parameter types disctintly from >> each other because we marshal them disctinctly on the kss command payload >> (which we may change in the next implementation), but precisely because >> we want to check and sanitize the parameter content on the server side. >> This altogether improves the quality of applications based on top of kss, >> and enables earlier caching of certain application errors. >> >> So the question that is raised: I offered some reasons above why I find >> this functionality important and to be kept. Do we have any reason to >> drop this functionality in the next release (based on kss.base)? >> According to you two things are handled by BeautifulSoup. One is validation and the other is automagically "fixing" data. I am against anything which tries to fix my HTML without my intervention, ss you might have guessed from me calling it automagic. This could lead to all sorts of weird problems which would take an app developer some serious time to figure out. I guess if they where anything like me they would be very displeased to find out that KSS was doing more than just sending the data over the wire.
The other thing you mentioned is checking. Checking implies that we know what is correct. It does seem a bit pretentious though to know what is valid. If I send some partial paragraph (<p> without an end) because a wysiwyg editor stored it like that should KSS explode on me? Even though for the application I am developing it would be fine? How do we handle new / upcomming tags or entities? Do we know in advance how a tag for a new HTML 6 (speculation) tag must be closed? This also brings me to question the actual necessity of this validation. Plone and most other web tools / frameworks seem to be perfectly fine with not sanitizing or checking the generated HTML. Why would KSS be different? > Definitely no reason. I agree that html sanitizing and unicode nicety > need to be kept. > > And that they should go to kss.base. > The unicode is something different again. I think it would be o.k. to check for this in kss.base (in case it is not done ex- or implicitly already). _______________________________________________ Kss-devel mailing list [email protected] http://codespeak.net/mailman/listinfo/kss-devel
