Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-26 Thread Chris McDonough
Chris McDonough wrote:
 Iain Duncan wrote:
 On Sat, 2009-09-26 at 01:42 -0400, Chris McDonough wrote:
 Iain Duncan wrote:
 If I could get the 'one-registry-to-rule-them-all' loaded in middelware
 on ingress, is there at least a reasonable way of forcing the bgf app to
 use that registry as it's site manager? 
 Nope.  BFG hooks this hookable thing when it loads a ZCML file to put 
 it in 
 its own registry, and unhooks it when loading is done.  On every request, 
 it 
 pushes that registry into a place where it can be found by the global API 
 and 
 pops it off when the request is done.  The global registry is never 
 populated 
 or consumed.

 Like, I managed to stash the
 middleware created site manager in the environ, and get at it
 successfully from bfg, but it means I'm manually querying adapters like
 so:

 sm = environ['dram.sm']
 sm.queryAdapter( yada yada )
 If you've got that far, good on ya.  Any solution you come up with will 
 smell a 
 lot like that, so you may have already won. FTR, this is what all 
 interaction 
 with any ZCA registry *should* look; the global API is for the birds. ;-)
 Hmm, wondering about bfg's look up of views though. Would it be feasible
 for me to replace the site manager that bfg uses to look up views, given
 that they are named multi-adapters under the hood. ( see I've been
 reading! ha ha )
 You can do this, it's just essentially replacing the registry attribute 
 of 
 the BFG router app that represents the application.  Sort of.  BFG 
 actually 
 uses a subclass of the registry (see registry.py).  So you have to replace 
 it 
 with one that has the same methods.  You can probably do this in a 
 subscriber 
 to the WSGIApplicationStartedEvent, which receives the router object as an 
 argument.  Thereafter, the registry placed on the stack will be the one you 
 placed there.

 I'd advise against it, though.  It smells real bad.
 Hmm, I agree, but I feel like there is a smell either way. ;-)

 It seems to me I can either:

 A) - create a duplicate of the the same registry in my abstract model
 middleware by using zope.configuration.xmlconfig( same_file_as_bfg ) and
 then know that any utility/adapter queries will get the same things  
 
 This seems like it might be the lesser of two evils.. although I'd be asking 
 myself these things:
 
 a) Does the middleware really need a component registry?
 
 b) If so, does the middleware really need to use the *same* registry as the 
 applications its in front of?
 
 c) If so, why is this thing middleware and not part of the application? 
 (Answering my own question: because there's more than one app, I understand).
 
 2 - find a way to make bfg use the same registry I make in the
 middleware

 A) also smells bad to me because I am duplicating the registry, but
 perhaps if I am only programatically *reading* from the registry the
 rest of the time it's the lesser of the two evils? I intend for the
 registry to get populated on startup and then stay static.

 In this context, the call chain is my model middleware, pylons, and bfg
 at the end, the bfg app basically acting as a configurable crud thing. I
 realize this is kind of a bent use of bfg, but on reading the bfg docs
 it seemed like the bfg router and views accomplished a whole ton of
 stuff I was just doing badly from scratch in my initial attempts.
  
 I'd be interested in hearing your thoughts on pros/cons of each and why
 in particular you think hijacking the bfg registry with one created in
 middleware would be bad, but I appreciate you no doubt have your own
 stuff to work on!
 
 To be honest, if there's less than, say, 3K-4K lines of code in the Pylons 
 project, I'd be tempted port the Pylons code to BFG and just make it all one 
 BFG app.  I assume you've considered and rejected this idea.
 
 Failing this, maybe you could proxy the Pylons app via the BFG @wsgi_app2 
 decorator on some very generic view.  At this point, the BFG registry will be 
 current wrt the global ZCA API, so calls in the Pylons apps will get the 
 right registry.

That's this, to be clear:

http://docs.repoze.org/bfg/current/api/wsgi.html#repoze.bfg.wsgi.wsgiapp2


 
 - C
 
 ___
 Repoze-dev mailing list
 Repoze-dev@lists.repoze.org
 http://lists.repoze.org/listinfo/repoze-dev
 

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-26 Thread Iain Duncan
  
  Hmm, I agree, but I feel like there is a smell either way. ;-)
  
  It seems to me I can either:
  
  A) - create a duplicate of the the same registry in my abstract model
  middleware by using zope.configuration.xmlconfig( same_file_as_bfg ) and
  then know that any utility/adapter queries will get the same things  
 
 This seems like it might be the lesser of two evils.. although I'd be asking 
 myself these things:
 
 a) Does the middleware really need a component registry?
 
 b) If so, does the middleware really need to use the *same* registry as the 
 applications its in front of?
 
 c) If so, why is this thing middleware and not part of the application? 
 (Answering my own question: because there's more than one app, I understand).

Well, as you guessed, I'm trying to move the domain model and all domain
specific code and configuration out into one place so it can be used by
multiple engine-apps. It also seems to me to be a good way of hedging my
bets on *how* the persistence is handled. What I'm happy about is that
now the pylons code and bfg code don't care what the domain model uses,
sqlalchemy, zodb, xml, whatever. They just get the model off the wsgi
env and call it's methods, and I can retool the model really easily to
be used in other contexts and applications. It seems to be doing what I
want, so I think I can live with the duplicate but identical registry
smell if it's an acceptable evil, at least for now. =)

snip

 To be honest, if there's less than, say, 3K-4K lines of code in the Pylons 
 project, I'd be tempted port the Pylons code to BFG and just make it all one 
 BFG app.  I assume you've considered and rejected this idea.

Not rejected, more keeping my options open. There are a lot of bits of
Pylons I find useful, though I really like bfg's architecture. Really
I'm hoping for Pypes to make this all academic, and I guess right now
I'm just trying have my cake and eat it too. There is also a matter of
some 'developing-clients' wanting to be able to add their own read-only
controllers and views, and I think giving them access to the domain
model in simple pylons controllers is easier than having them try to
understand my bfg code. So the admin code uses my bfg code, but I want
them to be able to make extra views easily without knowing bfg.

 
 Failing this, maybe you could proxy the Pylons app via the BFG @wsgi_app2 
 decorator on some very generic view.  At this point, the BFG registry will be 
 current wrt the global ZCA API, so calls in the Pylons apps will get the 
 right registry.

This is kinda what I'm doing, but the other way around. ( There's a
pylons controller that calls my bfg wsgi callable ). Maybe I did it
backwards. I'll have to think on that. Maybe it wouldn't matter who did
what first. hmmm. 

Thanks for all the food for thought!
Iain


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-26 Thread Chris McDonough
Iain Duncan wrote:
 Hmm, I agree, but I feel like there is a smell either way. ;-)

 It seems to me I can either:

 A) - create a duplicate of the the same registry in my abstract model
 middleware by using zope.configuration.xmlconfig( same_file_as_bfg ) and
 then know that any utility/adapter queries will get the same things  
 This seems like it might be the lesser of two evils.. although I'd be asking 
 myself these things:

 a) Does the middleware really need a component registry?

 b) If so, does the middleware really need to use the *same* registry as the 
 applications its in front of?

 c) If so, why is this thing middleware and not part of the application? 
 (Answering my own question: because there's more than one app, I understand).
 
 Well, as you guessed, I'm trying to move the domain model and all domain
 specific code and configuration out into one place so it can be used by
 multiple engine-apps. It also seems to me to be a good way of hedging my
 bets on *how* the persistence is handled. What I'm happy about is that
 now the pylons code and bfg code don't care what the domain model uses,
 sqlalchemy, zodb, xml, whatever. They just get the model off the wsgi
 env and call it's methods, and I can retool the model really easily to
 be used in other contexts and applications. It seems to be doing what I
 want, so I think I can live with the duplicate but identical registry
 smell if it's an acceptable evil, at least for now. =)

Passing an API directly down through middleware to apps is the topic of much 
hand wringing:

http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html

It's still convenient, and ultimately your call, though.

 
 snip
 
 To be honest, if there's less than, say, 3K-4K lines of code in the Pylons 
 project, I'd be tempted port the Pylons code to BFG and just make it all one 
 BFG app.  I assume you've considered and rejected this idea.
 
 Not rejected, more keeping my options open. There are a lot of bits of
 Pylons I find useful, though I really like bfg's architecture. Really
 I'm hoping for Pypes to make this all academic, and I guess right now
 I'm just trying have my cake and eat it too. There is also a matter of
 some 'developing-clients' wanting to be able to add their own read-only
 controllers and views, and I think giving them access to the domain
 model in simple pylons controllers is easier than having them try to
 understand my bfg code. So the admin code uses my bfg code, but I want
 them to be able to make extra views easily without knowing bfg.

Grain of salt and all, considering the source, but I'm pretty sure that BFG is 
a much better fit for developing clients with no prior experience with Pylons 
than is Pylons, all other things being equal.

This is because BFG has a mechanism for your clients to add and override views 
from an external package without forking your code, particularly when traversal 
is used.  (It's still possible to override and add views that use url 
dispatch (aka routes) in a BFG app, but because routes need ordering, it's not 
always possible to do this without cutting and pasting *all* the routes (ZCML) 
into a customer package and having them add/change them there.)

See also http://docs.repoze.org/bfg/1.0/narr/extending.html

 Failing this, maybe you could proxy the Pylons app via the BFG @wsgi_app2 
 decorator on some very generic view.  At this point, the BFG registry will 
 be 
 current wrt the global ZCA API, so calls in the Pylons apps will get the 
 right registry.
 
 This is kinda what I'm doing, but the other way around. ( There's a
 pylons controller that calls my bfg wsgi callable ). Maybe I did it
 backwards. I'll have to think on that. Maybe it wouldn't matter who did
 what first. hmmm. 

This seems like it might be the sanest path.  Sorry I didn't think of it 
earlier.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-25 Thread Chris McDonough
Iain Duncan wrote:
 Ok, so I figured out that if I get the zope.component.globalSiteManager
 in my model middleware on ingress, that in bfg I can indeed query it for
 registered adapaters and get at that. But in the bfg app, the global
 site manager is empty and the siteManager has the stuff from my zcml
 file.
 
 So, I think I could do what I need if I knew how to:
 
 - fill the global site manager in middleware from the zcml file
 - get bfg to either use that site manager or fold it's contents into the
 one that is actively used

Apologies, I think you may be on your own.  It's definitely possible, but the 
zope.component ZCML loading design and the general there can be only one 
registry design of the global ZCA API hurts badly here, as *any* use of 
globals does.  It's just an awful design.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-25 Thread Iain Duncan
On Sat, 2009-09-26 at 01:04 -0400, Chris McDonough wrote:
 Iain Duncan wrote:
  Ok, so I figured out that if I get the zope.component.globalSiteManager
  in my model middleware on ingress, that in bfg I can indeed query it for
  registered adapaters and get at that. But in the bfg app, the global
  site manager is empty and the siteManager has the stuff from my zcml
  file.
  
  So, I think I could do what I need if I knew how to:
  
  - fill the global site manager in middleware from the zcml file
  - get bfg to either use that site manager or fold it's contents into the
  one that is actively used
 
 Apologies, I think you may be on your own.  It's definitely possible, but the 
 zope.component ZCML loading design and the general there can be only one 
 registry design of the global ZCA API hurts badly here, as *any* use of 
 globals does.  It's just an awful design.

Well I feel better about feeling confused... but not so encouraged. ;-)

If I could get the 'one-registry-to-rule-them-all' loaded in middelware
on ingress, is there at least a reasonable way of forcing the bgf app to
use that registry as it's site manager? Like, I managed to stash the
middleware created site manager in the environ, and get at it
successfully from bfg, but it means I'm manually querying adapters like
so:

sm = environ['dram.sm']
sm.queryAdapter( yada yada )

Guess I'll muck about and post any progress, but if you have any more
thoughts I'd be happy to hear them.

thanks anyway!
Iain


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-25 Thread Chris McDonough
Iain Duncan wrote:
 On Sat, 2009-09-26 at 01:04 -0400, Chris McDonough wrote:
 Iain Duncan wrote:
 Ok, so I figured out that if I get the zope.component.globalSiteManager
 in my model middleware on ingress, that in bfg I can indeed query it for
 registered adapaters and get at that. But in the bfg app, the global
 site manager is empty and the siteManager has the stuff from my zcml
 file.

 So, I think I could do what I need if I knew how to:

 - fill the global site manager in middleware from the zcml file
 - get bfg to either use that site manager or fold it's contents into the
 one that is actively used
 Apologies, I think you may be on your own.  It's definitely possible, but 
 the 
 zope.component ZCML loading design and the general there can be only one 
 registry design of the global ZCA API hurts badly here, as *any* use of 
 globals does.  It's just an awful design.
 
 Well I feel better about feeling confused... but not so encouraged. ;-)
 
 If I could get the 'one-registry-to-rule-them-all' loaded in middelware
 on ingress, is there at least a reasonable way of forcing the bgf app to
 use that registry as it's site manager? 

Nope.  BFG hooks this hookable thing when it loads a ZCML file to put it in 
its own registry, and unhooks it when loading is done.  On every request, it 
pushes that registry into a place where it can be found by the global API and 
pops it off when the request is done.  The global registry is never populated 
or consumed.

 Like, I managed to stash the
 middleware created site manager in the environ, and get at it
 successfully from bfg, but it means I'm manually querying adapters like
 so:
 
 sm = environ['dram.sm']
 sm.queryAdapter( yada yada )

If you've got that far, good on ya.  Any solution you come up with will smell a 
lot like that, so you may have already won. FTR, this is what all interaction 
with any ZCA registry *should* look; the global API is for the birds. ;-)

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-25 Thread Iain Duncan

  If I could get the 'one-registry-to-rule-them-all' loaded in middelware
  on ingress, is there at least a reasonable way of forcing the bgf app to
  use that registry as it's site manager? 
 
 Nope.  BFG hooks this hookable thing when it loads a ZCML file to put it in 
 its own registry, and unhooks it when loading is done.  On every request, it 
 pushes that registry into a place where it can be found by the global API and 
 pops it off when the request is done.  The global registry is never populated 
 or consumed.
 
  Like, I managed to stash the
  middleware created site manager in the environ, and get at it
  successfully from bfg, but it means I'm manually querying adapters like
  so:
  
  sm = environ['dram.sm']
  sm.queryAdapter( yada yada )
 
 If you've got that far, good on ya.  Any solution you come up with will smell 
 a 
 lot like that, so you may have already won. FTR, this is what all interaction 
 with any ZCA registry *should* look; the global API is for the birds. ;-)

Hmm, wondering about bfg's look up of views though. Would it be feasible
for me to replace the site manager that bfg uses to look up views, given
that they are named multi-adapters under the hood. ( see I've been
reading! ha ha )

thanks again
Iain


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-25 Thread Chris McDonough
Iain Duncan wrote:
 If I could get the 'one-registry-to-rule-them-all' loaded in middelware
 on ingress, is there at least a reasonable way of forcing the bgf app to
 use that registry as it's site manager? 
 Nope.  BFG hooks this hookable thing when it loads a ZCML file to put it 
 in 
 its own registry, and unhooks it when loading is done.  On every request, it 
 pushes that registry into a place where it can be found by the global API 
 and 
 pops it off when the request is done.  The global registry is never 
 populated 
 or consumed.

 Like, I managed to stash the
 middleware created site manager in the environ, and get at it
 successfully from bfg, but it means I'm manually querying adapters like
 so:

 sm = environ['dram.sm']
 sm.queryAdapter( yada yada )
 If you've got that far, good on ya.  Any solution you come up with will 
 smell a 
 lot like that, so you may have already won. FTR, this is what all 
 interaction 
 with any ZCA registry *should* look; the global API is for the birds. ;-)
 
 Hmm, wondering about bfg's look up of views though. Would it be feasible
 for me to replace the site manager that bfg uses to look up views, given
 that they are named multi-adapters under the hood. ( see I've been
 reading! ha ha )

You can do this, it's just essentially replacing the registry attribute of 
the BFG router app that represents the application.  Sort of.  BFG actually 
uses a subclass of the registry (see registry.py).  So you have to replace it 
with one that has the same methods.  You can probably do this in a subscriber 
to the WSGIApplicationStartedEvent, which receives the router object as an 
argument.  Thereafter, the registry placed on the stack will be the one you 
placed there.

I'd advise against it, though.  It smells real bad.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] bfg site manager question ( another one )

2009-09-25 Thread Iain Duncan
On Sat, 2009-09-26 at 01:42 -0400, Chris McDonough wrote:
 Iain Duncan wrote:
  If I could get the 'one-registry-to-rule-them-all' loaded in middelware
  on ingress, is there at least a reasonable way of forcing the bgf app to
  use that registry as it's site manager? 
  Nope.  BFG hooks this hookable thing when it loads a ZCML file to put it 
  in 
  its own registry, and unhooks it when loading is done.  On every request, 
  it 
  pushes that registry into a place where it can be found by the global API 
  and 
  pops it off when the request is done.  The global registry is never 
  populated 
  or consumed.
 
  Like, I managed to stash the
  middleware created site manager in the environ, and get at it
  successfully from bfg, but it means I'm manually querying adapters like
  so:
 
  sm = environ['dram.sm']
  sm.queryAdapter( yada yada )
  If you've got that far, good on ya.  Any solution you come up with will 
  smell a 
  lot like that, so you may have already won. FTR, this is what all 
  interaction 
  with any ZCA registry *should* look; the global API is for the birds. ;-)
  
  Hmm, wondering about bfg's look up of views though. Would it be feasible
  for me to replace the site manager that bfg uses to look up views, given
  that they are named multi-adapters under the hood. ( see I've been
  reading! ha ha )
 
 You can do this, it's just essentially replacing the registry attribute of 
 the BFG router app that represents the application.  Sort of.  BFG actually 
 uses a subclass of the registry (see registry.py).  So you have to replace it 
 with one that has the same methods.  You can probably do this in a subscriber 
 to the WSGIApplicationStartedEvent, which receives the router object as an 
 argument.  Thereafter, the registry placed on the stack will be the one you 
 placed there.
 
 I'd advise against it, though.  It smells real bad.

Hmm, I agree, but I feel like there is a smell either way. ;-)

It seems to me I can either:

A) - create a duplicate of the the same registry in my abstract model
middleware by using zope.configuration.xmlconfig( same_file_as_bfg ) and
then know that any utility/adapter queries will get the same things  

2 - find a way to make bfg use the same registry I make in the
middleware

A) also smells bad to me because I am duplicating the registry, but
perhaps if I am only programatically *reading* from the registry the
rest of the time it's the lesser of the two evils? I intend for the
registry to get populated on startup and then stay static.

In this context, the call chain is my model middleware, pylons, and bfg
at the end, the bfg app basically acting as a configurable crud thing. I
realize this is kind of a bent use of bfg, but on reading the bfg docs
it seemed like the bfg router and views accomplished a whole ton of
stuff I was just doing badly from scratch in my initial attempts.
 
I'd be interested in hearing your thoughts on pros/cons of each and why
in particular you think hijacking the bfg registry with one created in
middleware would be bad, but I appreciate you no doubt have your own
stuff to work on!

thanks again,
iain


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev