[Grok-dev] Re: Recipe for "egg-like" reuse?

[Martijn Faassen]

Sebastian Ware wrote:
> 8 apr 2008 kl. 17.33 skrev Uli Fouquet:
>> If you want your AddApp to be registered completely, edit buildout.cfg
>> and register your additional app in the [app] section::
> 
> 
> I have come to the point where I can create an instance of my MasterApp 
> in the grok admin interface. However, the application won't find the 
> views I have in my AddApp, eventhough the application class of MasterApp 
> has inherited from a class of AddApp for which these views should be 
> registered (through grok.context).

I don't see evidence of this in your example: the Edit view is attached 
to the ProtonCMS model, which doesn't inherit from Navicast at all.

> MasterApp:
> 
> class Navicast(grok.Application, ProtonCMS):
> [snip]
> 
> AddApp:
> 
> class ProtonCMS(grok.Container):
> [snip]
> 
> class Edit(grok.EditForm, protonbase.ProtonEdit):
>     grok.context(ProtonCMS)
>     [snip]
> 
> And I would expect to be able to access the edit view through:
> 
>   http://localhost:8080/application/edit
> 
> But I get a "The page that you are trying to access is not available"

If you want to *extend* the MasterApp program from your AddApp program, 
you need to either share the class you extend, or the interface. You'll 
have to do either one of these:

AddApp:

from masterapp.app import Navicast

class Edit(...):
     grok.context(Navicast)

Or alternatively it might be time to start definining an interface in 
MasterApp and then expand that:

MasterApp:

from masterapp.interfaces import INavicast

class NaviCast(....)
     grok.implements(INavicast)

from masterapp.interfaces import INavicast

class Edit(...)
     grok.context(INavicast)

Grok has to know that you're extending the original application in some 
way. This can be done because you hook up things to the same interface 
or class. At some point, using explicit interfaces may start to be a win 
here, as you can explicitly define how your core can be expanded by an 
extension. In both cases your extension needs to know about your core 
(at least about its interfaces), but that's pretty natural since you're 
going to add views to it.

If you really want to start getting abstract you could create a third 
package that just defines the interfaces, then have your core implement 
it, and your extension expand them. They then don't need to explicitly 
refer to each other. As long as your extension only uses things defined 
in the interfaces, you can replace the core with another implementation 
with the same interface without having to change the extension at all. 
All this is probably overkill right now, though.

Regards,

Martijn