-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yuppie wrote: > Hi! > > > Godefroid Chapelle wrote: >> Tres Seaver wrote: >>> yuppie wrote: >>>> Godefroid Chapelle wrote: >>>>> Scenario 1+2 : >>>>> >>>>> The methods that depend on REQUEST are moved to browser views as >>>>> below instead of quickly fixed as in the scenario above. They can >>>>> then be deprecated on the tool. >>>>> >>>>> Once a tool has been fixed as utility and views, we should deprecate >>>>> its use as tool (this might be implicit in the scenario above). >>>> There are many tool methods that depend on REQUEST, but most of them >>>> take it as argument, not from the acquisition context. Separating all >>>> these methods cleanly in utility methods and views will mean >>>> replacing the tools by something new, not converting them to utilities. >>> Any method which already takes REQUEST as an argument can be left alone >>> for now. >> Right >> >> >>> I think Godefroid was arguing that methods which expect to be able to >>> acquire 'REQUEST' should be converted to view methods. >> Good : you clarify my thoughts. > > I agree this is the cleaner solution *if* someone does the necessary > work. But it's no useful approach if that means deferring the > tools-as-utilities changes indefinitely. > >>> Some methods are >>> "indirect" dependents (they call somthing which acquires REQUEST). I >>> think we'd handle those by turning them into view lookups (ideally), or >>> by continuing to call the deprecated API (see below), > > We only can continue to use the deprecated API if caller *and* callee > are no utilities.
A caller which can't be modified to use the REQUEST-passing API *cannot* be a utility method, period. >>> perhaps suppressing the message. >> suppressing which message ? the deprecation ? >> >>>>> Pros: migration achieves better separtion of concerns >>>>> >>>>> Cons: longer time to migrate away from tools (which will be long >>>>> anyway, as so many 3rd party products have some of those and the >>>>> understanding of the patterns will take time to percolate in the >>>>> community. >>>> I'm afraid we don't have enough volunteers to implement this >>>> scenario. Tools depend on each other and if your tool depends on a >>>> non-utility tool you can't make it a utility. The quick fix I propose >>>> makes it easy to start the migration - we can split off views later. >>>> And the pattern is very simple: Adding REQUEST arguments where >>>> REQUEST is used. >>>> >>>> A bird in the hand is worth two in the bush. >>> I think we have to leave existing REQUEST-acquiring APIs alone, but >>> deprecate them, and then implement them by calling *new* REQUEST-passing >>> APIs. I would rather add methods than add hackery around the default >>> REQUEST argument, as it keeps the deprecation story cleaner. >>> >> +1 > > The quick and dirty implementation would be adding basically the same > methods with different names and an additional REQUEST argument or a > required instead of an optional REQUEST argument. Is that what you > propose and prefer over adding a required REQUEST argument to existing > methods? > > Or do you know any volunteers for reviewing each method, replacing them > by better view or utility code and writing tests for those new > implementations? > > Or do you prefer to keep things as they are over a less clean switch to > utilities? Yes. I'd rather get 2.1 out, even with tools-which-can't-be-utilitiies as they are, then delay. Note that this problem is basically due to the desire to cache the aq_chain for utilities: if we punt on that, we can then defer this whole issue. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjVt2+gerLs4ltQ4RAhB5AKDFSkBdidQwPlAcy5l3eshZDQcJPACeNHr0 jOteDZZr1wQwds5PdhxcFtE= =CVaU -----END PGP SIGNATURE----- _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests