Sidnei da Silva wrote:
>On Mon, Sep 12, 2005 at 02:36:21PM +0200, Jean-Marc Orliaguet wrote:
>| >Still, the place to add indirection would be 'getToolByName'. As Tres
>| >said above, let's not invent another component architecture.
>|
>| I agree that the correct of doing it is through the equival
On Mon, Sep 12, 2005 at 02:36:21PM +0200, Jean-Marc Orliaguet wrote:
| >Still, the place to add indirection would be 'getToolByName'. As Tres
| >said above, let's not invent another component architecture.
|
| I agree that the correct of doing it is through the equivalent of a
| getUtility(IToolIn
Sidnei da Silva wrote:
>On Mon, Sep 12, 2005 at 02:03:24PM +0200, Jean-Marc Orliaguet wrote:
>| Hi Sidnei
>| the difference is that portal_catalog is both a tool and a catalog
>| instance (with its indexes, records...). Other CMF tools are just tools
>| and their path can well be hardcoded in CMF
On Mon, Sep 12, 2005 at 02:03:24PM +0200, Jean-Marc Orliaguet wrote:
| Hi Sidnei
| the difference is that portal_catalog is both a tool and a catalog
| instance (with its indexes, records...). Other CMF tools are just tools
| and their path can well be hardcoded in CMF since they provide only
| fun
Sidnei da Silva wrote:
>On Mon, Sep 12, 2005 at 01:46:00PM +0200, Jean-Marc Orliaguet wrote:
>| Julien fixed a bug. Only poorly designed software implements hardcoded
>| references to paths ('portal_catalog'). And he needed it to implement a
>| separate catalog for portlets. So let's move on
>
On Mon, Sep 12, 2005 at 01:46:00PM +0200, Jean-Marc Orliaguet wrote:
| Julien fixed a bug. Only poorly designed software implements hardcoded
| references to paths ('portal_catalog'). And he needed it to implement a
| separate catalog for portlets. So let's move on
Sorry, but I totally disagre
Julien Anguenot wrote:
> Chris Withers wrote:
>
> Well, let's explain what you wanna do then ? It's speculation at this
> stage. Note, we do *not* support multiple catalogs yet. This is
> something we *could* support if eventually some people here are
> interested to discuss it.
>
> >So I'm with J
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Julien Anguenot wrote:
>
>> The refactoring was obsious and harmless right ? Just removing hardcoded
>> references to portal_catalog and portal_workflow within the internals
>> of CMFCatalogAware.
>
>
> Well, that's not refac
Julien Anguenot wrote:
The refactoring was obsious and harmless right ? Just removing hardcoded
references to portal_catalog and portal_workflow within the internals
of CMFCatalogAware.
Well, that's not refactoring is it? You've added new functionality with
the intent of allowing a new featur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
>
> On 8 Sep 2005, at 13:52, Julien Anguenot wrote:
>
>> Thoughts ?
>
>
> Why do you ask for feedback after committing? Surely the correct
> procedure would be to ask forst and commit later..?
The refactoring was obsious and
On 8 Sep 2005, at 13:52, Julien Anguenot wrote:
Thoughts ?
Why do you ask for feedback after committing? Surely the correct
procedure would be to ask forst and commit later..?
jens
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.z
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I did a small refactoring on the CMFCatalogAware in changesets [38390]
(1.5) and [38391] (trunk)
The CMFCatalogAware class definition defines now 2 new methods,
_getCatalogTool() and _getWorkflowTool(), that are used internaly while
looking up fo
12 matches
Mail list logo
