Philipp von Weitershausen schrieb:
Roger Ineichen wrote:
class LanguagesVocabulary(SimpleVocabulary):
    """... languages from a translation domain."""

    implements(ILanguagesVocabulary)

    def __init__(self, context, domain='zope'):
        terms = []

        # collect languages from translation domain
        trans_domain = getUtility(ILocalTranslationDomain, domain)
        languages = trans_domain.getAvailableLanguages()

        for lang in languages:
            terms.append(SimpleTerm(lang, lang, lang))

        terms.sort(lambda lhs, rhs: cmp(lhs.title, rhs.title))
        super(LanguagesVocabulary, self).__init__(terms)


You can, of course, leave this as it is and implement the 'tiks'
vocabulary as:

def tiksLanguagesVocabulary(context):
    return LanguagesVocabulary(context, 'tiks')

and then register that as a regular IVocabularyFactory utility, in case
you're keen on saving lines in Python or just hesitant to create classes.

I need to do this in python for each "language vocabulary".
So we defently loose the ZCML as a compoent registration layer
and need a additional layer called python for registering a component!

I think you didn't understand what this means? Are you realy think it's a better option to have a mix of python and ZCML for register components?

I could live with that, but I don't understand why I loose additional
to this the reusablility and also the readability in ZCML?

I think

  <utility component=".tiksLanguagesVocabulary" name="Tiks Languages" />

reads quite well.

Why should I do this in ZCML if I have to do the first part of a
configuration in python. There is realy no reason to define this
in ZCML if I have to define the factory. It will become a YAGNY
and developer start to do this:

def tiksLanguagesVocabulary(context):
    return LanguagesVocabulary(context, 'tiks')

factory = tiksLanguagesVocabulary()
provideUtility(factory, name="Tiks Languages")



I'm not sure what do you think. Do you think it's a way we should go
or not? I think that's defently no way to go.

Philipp can you tell me why this is better if we loose the concept for
quick adding a new utility providing kws like the 'domain' attribute in
example.

I explain this in the proposal:

  "First, it is the only directive to take arbitrary arguments and by
  this it defies one of the initial aspects of ZCML (which is being
  restricted to a certain set of directives and parameters)."

That's no true,

The <vieletManager> uses this pattern too.

And the base pattern which makes it possible is well known in python.
(args, kws). Do you also mean this isn't a good concept?

I gree with you if you saying that arbitary arguments are to magic in ZCML.
But another option then remove this is to document it. Isn't that the real problem? Is ZCML only to magic and hard do understand becaus of to less documentation and samples?

(off Topic)
I realy don't understand that people can understand and work with Plone
and say that ZCML is to magic? But perhaps this is because Ploen is well documented and ZCML directives are not;-)

So this means if I need another LanguageVocabulary utility for a new
domain, I have to write new factory, just for use another
domain='foobar' attribute.

Should we add the vocabulary directive to a higher level namespace

What is a "higher level namespace"? Either way, I'd rather reduce the
amount of namespaces we have (perhaps to just the 'zope' one and 'browser').

Reduce the namespace is welcome. I vote for a single namespace called
"zope" and merge the browser:view and zope:view to one.

But the problem is you removed a hole concept called vocabulary directive.

This concept contains:

- reduce lines of python code,

- Offers a understandable (informative) name in form a of a directive

- Makes vocabularies resuable without write additional python code



The big problem we have is, we have a different meaning what ZCML
should be. I think ZCML supports registration and python supports
everything except configuration. I like a strict separation if possible.
Now you are going in a direction where we mix both concept with each other. Which will end in a chaos and is not easy to support.

Let me explain this a little more.
The following pyhton class defines the vocabulary:

class LanguagesVocabulary(SimpleVocabulary):
    """... languages from a translation domain."""

    implements(ILanguagesVocabulary)

    def __init__(self, context, domain='zope'):
        terms = []

        trans_domain = getUtility(ILocalTranslationDomain, domain)
        languages = trans_domain.getAvailableLanguages()

        for lang in languages:
            terms.append(SimpleTerm(lang, lang, lang))
        terms.sort(lambda lhs, rhs: cmp(lhs.title, rhs.title))
        super(LanguagesVocabulary, self).__init__(terms)


And now we have(had) two ways doing the configuration:

pure ZCML:

<vocabulary
  name="Tiks Languages"
  factory=".tiksLanguagesVocabulary"
  domain="tiks"
  />

then new concept requires a mix from python and ZCML:

def tiksLanguagesVocabulary(context):
    return LanguagesVocabulary(context, 'tiks')

<utility component=".tiksLanguagesVocabulary" name="Tiks Languages" />


Can you understand that I think this is not a good way to go.
Do we realy need such a complex configuration layer?

Note, your proposal simplifies the configuration process only
durring development of the "first" original vocabulary.

The use case to reuse such a vocabulary is not nice reflected
in this new concept.

--
Regards
Roger Ineichen
_____________________________
Projekt01 GmbH
www.projekt01.ch
Boesch 65
6331 H├╝nenberg
phone     +41 (0)41 781 01 78
mobile    +41 (0)79 340 52 32
fax       +41 (0)41 781 00 78
email [EMAIL PROTECTED]
_____________________________
END OF MESSAGE
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to