I think people are afraid to give ZCML anymore traction than it already has. I for one find it intimidating and confusing. Not so much because of its format, or api documentation, but because it is unclear what and how all the names and attributes interrelate. It's taken me two books, a bunch of samples, and alot of trial and error to get me to a very basic level. It seems easy now that I know what I know, but I thought Zope3 was going to have a flatter learning curve. I blame ZCML and whatever it might be hiding. :)Jim Fulton wrote:Martijn Faassen wrote:
> Shane Hathaway wrote:
>> Jim Fulton wrote:
>>> Comments and volunteers welcome.
>> I like this proposal. It is likely to reduce the total amount of code.
>> However, I want to be sure that consolidating engines is the real
>> focus of the proposal. Converting XML files to ZConfig format doesn't
>> seem like an interesting change.
> If you don't convert your ZCML files to ZConfig format, you'll have to
> support the ZCML reader as well, so I think it'd lead to more code
> unless such a thing were done.
Huh? Geez, my proposal must have been really unclear. I'm not proposing
replacing ZCML files with ZConfig files. I'm proposing leveraging the ZCML
engine and especially the system for extensibility for handling ZConfig files.
This would require some new code, but would reduce the amount of code
overall. It would also reduce the number of configuration-file extension
mechanisms needed. Finally, it would make it a lot easier to extend ZConfig
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list
View this message in context: Re: RFC: ZConfig and other formats for ZCML
Sent from the Zope3 - dev forum at Nabble.com.
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com