[Zope-dev] possible bug in zope.app.publication

2010-06-21 Thread Gustavo Rahal
I'm trying to integrate lazr.restful into a Zope3 app and I was advised to
created my own publication factory. For that I did

  publisher
  name=LAZRWS
  factory=.root.WSFactory
  methods=GET POST HEAD DELETE
  mimetypes=*
  priority=5
  /

Priority is set to 5 as opposed to priority 10 of the standard BROWSER
declaration in zope/app/publication/configure.zcml

  publisher
  name=BROWSER
  factory=.requestpublicationfactories.BrowserFactory
  methods=GET POST HEAD
  mimetypes=*
  priority=10
  /

But although the RequestPublicationFactory class say:

The `priority` is used to define a lookup-order when multiple factories
are registered for the same method and mime-type.

the RequestPublicationFactory.lookup does not really take that into account.
So what I did on line 104 of
zope/app/publication/requestpublicationregistry.py

from operator import itemgetter
factory_lst = sorted(factory_lst, key=itemgetter('priority'))

Now it works as expected, calling canHandle of my factory and then falling
back to .requestpublicationfactories.BrowserFactory for non WS requests.

Is this really a bug or should I be doing something different?


Thanks
Gustavo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] New Zope 3 name: BlueBream

2010-01-06 Thread Gustavo Rahal
Em Qua, 2010-01-06 às 07:45 +0530, Baiju M escreveu:
 Hi All,
Thanks to all those who participated in this discussion so far.
 I will try to make baby steps for the project.  So, for time being
 I will focus on the getting started story (which is somewhat ready)
 then documentation, a small website ( http://bluebream.zope.org )
 and before 1.0 release, an upgradation path from Zope 3.4 KGS.
 
 I am fine with calling the project as Bream for short, however BlueBream
 will remain.  But all the framework specific packages will remain in
 zope and zope.app namespaces.  May be we can think about bream as a
 namespace in future.
 
 I remember the days when I started contributing to Zope project.
 Zope developers were eagerly started looking at the larger Python
 community with cool technologies emerging out of it like
 WSGI, egg, Paste and other web frameworks.  As a first step
 for adoption, eggification of Zope 3 packages was in radar for many
 contributors.  I am glad that I was able to accelerate the project
 by creating a proposal:
 https://mail.zope.org/pipermail/zope3-dev/2006-October/020858.html
 To further accelerate the eggification of zope.app packages,
 I implemented Jim Fulton's proposal:
 https://mail.zope.org/pipermail/zope3-dev/2006-December/021352.html
 (BTW, This is the greatest appraisal I ever received from a FOSS community)
 With all the contributors effort, Zope 3 packages became more reusable
 by other projects.  But the Zope 3 users were at a loss, they
 lost their main development discussion platform itself (zope3-dev list)
 and there was no releases.  Then Stephan Richter created Zope 3.4 KGS,
 that was a good move which helped the existense.
 
 For a sucessfull web framework, few packages maintained by
 people with different interest in not sufficient.  With BlueBream/Bream,
 I hope we will be able to bring together the framework developer community
 again. I appreciate all your support for this project.
 
 Regards,
 Baiju M


As a new comer in zope community (a few months), I appreciate this move
as well. The new name can also be seen as a excuse for a stronger and
more meaningful statement: There is value in zope3 web app part and we
want to continue it's development regardless of the other projects.
Having read and recommended to many people philiKON zope3 book I felt
all the work put into building a coherent and stable web framework was
going away.
Philipp, please consider a Web component Development with Bluebream in
the future :)


P.S - As a ibm employee, there is already too much blue going on in my
day to day work :) 
I would vote for Bream only.


Regards,

-- 
Gustavo Matheus Rahal
IBM Linux Technology Center


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] New Zope 3 name: BlueBream

2010-01-06 Thread Gustavo Rahal
Em Qua, 2010-01-06 às 19:00 +0530, Baiju M escreveu:
 On Wed, Jan 6, 2010 at 5:43 PM, Gustavo Rahal gra...@linux.vnet.ibm.com 
 wrote:
  P.S - As a ibm employee, there is already too much blue going on in my
  day to day work :)
 
 I am not a native English speaker. So, blue is used in more negative
 contexts ?
 
 Regards,
 Baiju M

Not native English speaker as well :)

But what I meant is that ibm is known as big blue and tends to use
blue in many names and theme stuff with blue colors.



-- 
Gustavo Matheus Rahal
IBM Linux Technology Center


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] z3c.jsonrpc and zope3.4 egg versions

2009-07-31 Thread Gustavo Rahal
Hello

I'm trying to use z3c.jsonrpc with Zope3.4 but I'm encountering problems
with imports that z3c.jsonrpc does from zope.publisher.

From http://download.zope.org/zope3.4/3.4.0/versions.cfg I see that
zope.publisher for zope3.4 is 3.4.6 but the latest version
of zope.publisher from svn is 3.8.0.

From reading the Changes section of
http://pypi.python.org/pypi/z3c.jsonrpc it seems like version 0.5.3 did
changes to cope with changes of zope.publisher newer versions (newer
then what comes with zope3.4).

I haven't tried but I imagine that if I downgrade z3c.jsonrpc to version
0.5.2 things might work but then some questions came into my mind as i'm
new to zope3 and buildout/eggs world.

1. Am I looking things in the wrong way or zope 3 components don't
necessary follow the stable release of zope3 but rather a zope component
version (in this case z3c.jsonrpc is following zope.publisher not
zope3.4)

2. If 1 is true, I imagine that whenever I try a zope3 component It's a
trial and error adventure and it's not guaranteed that developer is
following zope3 versions.

3. If 2 is true, isn't there a better way to do things? :)


Appreciate some help 

Thanks

-- 
Gustavo Matheus Rahal
IBM Linux Technology Center


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Schema to JSON

2009-06-29 Thread Gustavo Rahal
Em Seg, 2009-06-29 às 11:18 +0100, Paul Wilson escreveu:
 2009/6/29 Martijn Faassen faas...@startifact.com
 
  Hi there,
 
  Paul Wilson wrote:
   I'm about to embark on a module to serialize Zope schemas into the JSON
   format for my application, taking inspiration from z3c.schema2xml. I've
   had a look around SVN to see if this functionality has already been
   implemented but can't find anything - does anybody know whether this has
   already been done somewhere?
 
  I imagine lazr.restful hides functionality for this somewhere in its
  codebase. Perhaps one way forward would be to extract it? Maybe not, but
  it bears some investigation.
 
 
 Thanks for the hint. I'll take a look.
 
 
   Also, it makes sense in my mind for a schema2xml and schema2json to
   implement the same interface. How does Zope handle this case? With a
   format agnostic interface module or something?
 
  I am not sure I understand the proposal. Which interface would be the
  same and why would that be useful?
 
 I don't want my application to have knowledge of the format that the
 object tree will be serialized into - I want that to be a
 configuration detail. So, a simple format independent interface (with
 serialize and deserialize) would hide this. I was considering
 implementing some of the TODOs in the schema2xml package for my json
 version, but this would diverge their behaviour enough to spoil my
 hopes of switching freely between the two formats. Perhaps I'm looking
 at this the wrong way?
 
  I think you should just think in terms of what the API should be like
  before you worry about interfaces. (though interfaces are also used to
  look up adapters here).
 
 I've structured it internally in a very similar way to your schema2xml
 package, and shamelessly copied your test cases! :-)
 
 
  Sounds like a useful project!
 
 
 It's in my sandbox at the moment - all tests pass as it stands but it
 needs more attention I think.
 
 Regards,
 Paul

Nice, I would be interested in helping as well. Perhaps you could open a
launchpad project or something?
We are planning a new web app using GWT (Google Web Toolkit) as
frontend. We already have an application written in Django that spits
json to a GWT interface and we are planning a new app based on zope3
(yeah, I did not like django that much, perhaps I should write about
this when I get to know zope3 more...)



-- 
Gustavo Matheus Rahal
IBM Linux Technology Center


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )