[Product-Developers] Re: kss/macros/IAdding in plone.app.z3cform

[Daniel Nouri]

Carsten Senger writes:

> --On Donnerstag, August 07, 2008 11:53:39 +0200 Daniel Nouri 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.

z3c.macro sounds interesting.

> 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.

Sounds reasonable.  I'm just a bit worried that the default template
will become so unwieldy and complicated that people are discouraged to
make custom templates.

Of course, this is not so much about your particular change, but more a
general observation.

> [...]

>> 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 :-(.

I think this should be fixed in plone.theme then, no?


-- 
Daniel Nouri
http://danielnouri.org