Martin Aspeli writes: > Carsten Senger wrote: >> Hi there, >> >> I could not find a bugtracker for plone.app.z3cform and plone.z3cform. >> I have some patches for plone.app.form: > > plone.app.form and plone.app.z3cform are different. I assume you meant > plone.app.z3cform? > > I think the product-developers list would be more appropriate than the > KSS one, by the way. > >> * kss-Validate fields in groups/fieldsets: >> >> I would like to extend Z3CFormValidation to handle groups. > > Please! > >> At the moment the kssattr-formname is not set if has_groups is true >> (macros.pt:60). This ends in bad requests for >> kss_z3cform_inline_validation/validate_input because the attribute >> formname is missing. >> The validationview itself uses the kssattr's formname and fieldname. >> That's not enough to also check all groups enough cause there can be >> more than one field with the same name and the kss-command >> replaceInnerHTML makes funny things with the dom. >> The two ways I see are: >> >> * include the group into kssattr-fieldname. >> * include an other kssattr in a parent of the widget (e.g. the >> filedset). >> >> I implemented the latter. It doesn't change the api for css and has >> to inspect on widgetset. But im uncertain if it has any siteeffects. >> A patch is attached. > > This sounds sensible. Can you just commit it, preferably with a test?
+1. I'm CCing Jean-François, who might want to have a look at the commit since he implemented this. >> * Make it possible to disable tabbing in forms with groups. >> Tabbing is automaticaly enabled with groups. But normal webusers can >> miss the tabs or dont't understand them which leads to a frustrating >> userexperience. I attached a patch that adds an optional attribute >> enable_tabbing to the form. This is not very elegant but works. > > You mean it turns off the fieldset tabs? I'd ask Daniel Nouri if he's > happy to take that. Personally, I think it'd be better to just use a > custom template if you don't want the semantics of the default > template, rather than introduce too many switches. I think the patch is okay. Generally, I wish we could separate concerns a bit more in the macros.pt template. The idea is that you can customize some of the macros while reusing most of what's there to minimize the maintenance burden. Because you don't want a copy of macros.pt in your code. I think we've recently introduced a couple of interdependencies between macros that make this kind of thing hard. >> * Optional disable kss-validation >> I would like to add a second optional attribute enable_kss_validation >> to disable the validation > > +1. I think this needs to work on a per-field level. Some fields > behave funny when inline validated. Again, Jean-François might have a good idea here. >> * Translate Errors in kss-validation >> KSSCommands don't handle i18nmessageid's. We have to translate them >> before calling core.replaceInnerHTML. A patch is attached. > > Again, please commit if you can. Looks good. Out of curiousity: Can't we use the zope.i18n API to do the same? >> * What happend to the IAdding-View? I need it for plones contentmenu. >> plone.z3cform.add was removed shortly before I checked >> out plone.z3cform. Didn't know there had been some code I hacked >> together almost the same solution mixed from >> plone.app.content.browser.adding and Five.browser.adding with some >> small additions around the context-problems, and it works for me. Are >> there any specific problems or plans to support IAdding for plone >> 3.x? If it works for you today, I'm fine with adding back support for IAdding. But: 1) We should test the implementation and 2) add a note saying it's an interim solution. > We wanted to wait to release it because it's not quite ready. It > causes problems with things like Kupu. We're kind of going off > IAdding. In plone.dexterity, I am using add.py, but I plan to refactor > to use something different based on simple views. There was a long > thread about this no the zope-cmf list. Have a look there for details. > >> * I tried to overwrite ploneform-macros with my own view. >> Is there an easy way? > > You can register a per-form template, either via attribute or > adapter. See the z3c.form docs. > >> I tried to register for a more special layer interface, >> plone.theme.interfaces.IDefaultPloneLayer, that inherits from >> ICMFDefaultSkin, but my view isn't used. >> I tried to override the registration with an overrides.zcml but >> that's only picked up by five in products in the /Products-folder, >> which my product isn't. > > You need to tell your site.zcml (or your buildout.cfg) to use > this. This is not z3c.form specific. In buildout with > plone.recipe.zope2instance, you'd do: > > zcml = > my.package-overrides > >> I tried to use includeOverrides but realised that it does not work >> when included in my own configure.zcml. > > Mmmm... it probably should. > >> At the end I put a *-overrides.zcml in packages-includes. > > That's what the buildout snippet above does for you. > >> In any way I would like to dokument it somewhere for me dump plone >> user. Your first approach of defining the macros for the more specialized IDefaultPloneLayer seems best, and it should work. plone.app.z3cform overrides plone.z3cform macros by using a more specialized request layer, too. Are you sure that your request provides IDefaultPloneLayer? I know that it doesn't in a standard Plone install. (If that's so, maybe we can fix this?) >> If the patches are ok I apply them to plone.app.z3cform +1. Go ahead Carsten. And thanks for your efforts. -- Daniel Nouri http://danielnouri.org _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
