--On Donnerstag, August 07, 2008 11:53:39 +0200 Daniel Nouri
<[EMAIL PROTECTED]> wrote:
Martin Aspeli writes:
Carsten Senger wrote:
[...]
* 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.
z3c.macro lets you define macros in a template, look them up via the
component registry with 'use-macro="macro: macroname"'. Then one can
override the macro with an adapter. The downside is that it's an additional
dependency and concept.
Nevertheless I think we should support some common needs with the default
templates. Adding many optional attributes to the form can get unclear
fast, but it's a far more direct way to influence the default templates
than adding more views, adapters and interfaces.
[...]
* 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?
I have rewritten the code to use zope.i18n directly.
* 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 had read the thread and I'm all for ditching IAdding. For me it was
annoying to handle the different context when I started to use formlib and
plone.app.form. But I don't want to overwrite folder_factories.
If I find time I try to write some tests and documentation.
* 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?)
I used plone.theme (not in the current project) but was not aware that it's
not inherited by Plone's default skin. Sometimes I get stuck in the
component registry that I capitulate and look for another way :-(.
If the patches are ok I apply them to plone.app.z3cform
+1. Go ahead Carsten. And thanks for your efforts.
Thank you for plone.*z3cform.
..Carsten
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
