Mailing List Archive: Zope: Dev

Proposal: zope.app.publisher refactoring

Index | Next | Previous | View Threaded

nadako at gmail

Aug 21, 2009, 12:06 PM

Post #1 of 24 (2978 views)
Permalink

Proposal: zope.app.publisher refactoring

Hi all.

I think it's time to clean the mess in the zope.app.publisher package.
Currently it contains many things that could be moved into separate
packages or merged with base zope packages. So here's a sketch plan
about where to move things:

Menu mechanism (the browser:menuItem directive and friends) - move
this to the new "zope.browsermenu" package. This should be easy as
nothing else in zope.app.publisher seem to depend on menus.

Browser view directives (browser:page and friends) - move this to some
"zope.browserpage" package and make its structure more clean, so
people could understand the magic of browser page class generation.
:-)

BrowserSkinsVocabulary - this can be moved to zope.publisher.browser
and rewritten with zope.schema's SimpleVocabulary not to introduce
dependency on zope.componentvocabulary.

ManagementViewSelector (the @@SelectedManagementView.html view) -
leave it there as is.

Resource mechanism (files, directories, etc.) - probably the most
complicated code, but it should be easy to move it to the new
"zope.browserresource" package. One problem is with
PageTemplateResource that introduces a dependency on
zope.pagetemplate. It should probably moved to another package, like
"zope.ptresource" and made dependent on z3c.ptcompat to support
chameleon engine.

ModifiableBrowserLanguages implementation - move to
zope.publisher.browser. It's the useful thing that won't introduce any
new dependencies.

"date" fieldconverter - I don't think anyone uses it, I'd leave it
there as is and forget about it :)

http.zcml - this file contains security declarations for
zope.publisher's HTTP-related classes. move them to zope.publisher.

xmlprc - move the IXMLRPCView interface and XMLRPCView base class to
zope.publisher as a counterpart to zope.publisher.browser.BrowserView.
Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to
new "zope.xmlrpcview" package. Also I'd merge MethodTraverser with
MethodPublisher to make it easier to understand and to decrease number
of entities :)

IXMLRPCPublisher adapters for zope.container - move them to
zope.container. The IBrowserPublisher adapters that are already there,
so it won't make things worser. The zope.container package may be
refactored later to break dependency on zope.publisher though.

IHTTPView and IFTPView interfaces - move that into zope.publisher as a
counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a
subclass of IHTTPView?)

IFTPDirectoryPublisher interface - not sure what's this and where is
it used. Probably should be moved to zope.publisher.interfaces.ftp as
well.

ILogin, ILogout from zope.app.publisher.interfaces.http - looks like
these don't really mean anything and are used only in
zope.app.security. I'd move them to zope.app.security even without BBB
imports (not to make zope.app.publisher dependent on
zope.app.security), but maybe I just don't know something about them?
:)

That's all for now. I'd like to see some
comments/propositions/objections before I start. Also, maybe there are
more beautiful names for new packages?

After refactorings it will be much easier to clean and develop
features that are currently provided by zope.app.publisher. For
instance I'd like to try to simplify browser resources code somewhat,
but it's for another proposal :)

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

kobold at kobold

Aug 21, 2009, 12:19 PM

Post #2 of 24 (2884 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

* 2009-08-21 21:07, Dan Korostelev wrote:
> IXMLRPCPublisher adapters for zope.container - move them to
> zope.container. The IBrowserPublisher adapters that are already there, so
> it won't make things worser. The zope.container package may be refactored
> later to break dependency on zope.publisher though.

-1, I think this is bad and we shouldn't do it: zope.container has nothing
to do with the publisher, and it shouldn't depend on it. The fact that we
already have the adapters for IBrowserPublisher shouldn't be a reason to
bring more publisher-related stuff over there.

Fabio
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

nadako at gmail

Aug 21, 2009, 12:28 PM

Post #3 of 24 (2881 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

2009/8/21 Fabio Tranchitella <kobold [at] kobold>:
> * 2009-08-21 21:07, Dan Korostelev wrote:
>> IXMLRPCPublisher adapters for zope.container - move them to
>> zope.container. The IBrowserPublisher adapters that are already there, so
>> it won't make things worser. The zope.container package may be refactored
>> later to break dependency on zope.publisher though.
>
> -1, I think this is bad and we shouldn't do it: zope.container has nothing
> to do with the publisher, and it shouldn't depend on it. The fact that we
> already have the adapters for IBrowserPublisher shouldn't be a reason to
> bring more publisher-related stuff over there.

Sorry, I didn't explain correctly. Those things are actually simply
two ZCML declarations that register traversers that are already
defined in zope.container.traversal and used for browser traversing.
See for yourself - zope/app/container/xmlrpc/configure.zcml. I think
those zcml declarations should be placed together with browser adapter
registrations, so people who will be refactoring zope.container could
see them. :)

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

nadako at gmail

Aug 21, 2009, 12:42 PM

Post #4 of 24 (2874 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

2009/8/21 Dan Korostelev <nadako [at] gmail>:
> I think it's time to clean the mess in the zope.app.publisher package.
> Currently it contains many things that could be moved into separate
> packages or merged with base zope packages. So here's a sketch plan
> about where to move things:

BTW, I am also waiting for comments from a steering group member, as
described in ZTK docs :-)

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

shane at hathawaymix

Aug 21, 2009, 1:37 PM

Post #5 of 24 (2885 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Hi Dan,

I'll provide feedback for a few parts of your proposal.

Dan Korostelev wrote:
> xmlprc - move the IXMLRPCView interface and XMLRPCView base class to
> zope.publisher as a counterpart to zope.publisher.browser.BrowserView.
> Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to
> new "zope.xmlrpcview" package. Also I'd merge MethodTraverser with
> MethodPublisher to make it easier to understand and to decrease number
> of entities :)

Few developers care about XML-RPC these days. Most web developers are
now working with REST, JSON, and other similar stuff. It's probably
best to move all XML-RPC artifacts, including those in zope.publisher,
to a single package, so that most developers can safely ignore the
XML-RPC code.

> IXMLRPCPublisher adapters for zope.container - move them to
> zope.container. The IBrowserPublisher adapters that are already there,
> so it won't make things worser. The zope.container package may be
> refactored later to break dependency on zope.publisher though.

You need Jim Fulton's input on this. I think his latest opinion is that
zope.container should have nothing to do with publishing.

> IHTTPView and IFTPView interfaces - move that into zope.publisher as a
> counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a
> subclass of IHTTPView?)

In zope.app land, sometimes IHTTP* really means INonBrowser*. In other
words, sometimes people want to define views just for HTTP ports not
intended for web browsers.

> IFTPDirectoryPublisher interface - not sure what's this and where is
> it used. Probably should be moved to zope.publisher.interfaces.ftp as
> well.

FTP is in the same boat as XML-RPC. Today, very few developers care to
provide a dynamic FTP view of anything. WebDAV usually wins over FTP
because adding SSL to WebDAV is easy. All FTP artifacts should move to
a separate package.

> That's all for now. I'd like to see some
> comments/propositions/objections before I start. Also, maybe there are
> more beautiful names for new packages?

The names you proposed seem ok.

Shane
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

nadako at gmail

Aug 21, 2009, 2:14 PM

Post #6 of 24 (2881 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

2009/8/22 Shane Hathaway <shane [at] hathawaymix>:
> Hi Dan,
>
> I'll provide feedback for a few parts of your proposal.
Thanks

> Few developers care about XML-RPC these days. Most web developers are now
> working with REST, JSON, and other similar stuff. It's probably best to
> move all XML-RPC artifacts, including those in zope.publisher, to a single
> package, so that most developers can safely ignore the XML-RPC code.

That's a good point. After a quick look, it seems to be easy to move
xmlrpc-related things from zope.publisher and zope.app.publisher to
new zope.xmlrpc package. One problem is how to make BBB imports then.
It doesn't look good to me to make zope.publisher dependent on
zope.xmlrpc for xmlrpc stuff, but moving things without BBB imports
will break applications that currently uses zope.publisher xmlrpc. One
option is to use the notorious "extra" dependencies, but that needs to
be discussed. Other options is to start a big refactoring of
zope.publisher, but that is a thing I didn't want to do right now, so
the third option is to leave these things until zope.publisher
refactoring. ;-)

>> IXMLRPCPublisher adapters for zope.container - move them to
>> zope.container. The IBrowserPublisher adapters that are already there,
>> so it won't make things worser. The zope.container package may be
>> refactored later to break dependency on zope.publisher though.
>
> You need Jim Fulton's input on this. I think his latest opinion is that
> zope.container should have nothing to do with publishing.

That's true, but see my reply to Fabio Tranchitella on this topic. :-)

>> IHTTPView and IFTPView interfaces - move that into zope.publisher as a
>> counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a
>> subclass of IHTTPView?)
>
> In zope.app land, sometimes IHTTP* really means INonBrowser*. In other
> words, sometimes people want to define views just for HTTP ports not
> intended for web browsers.

Okay then, let's leave the class hierarchy as is :-)

>> IFTPDirectoryPublisher interface - not sure what's this and where is
>> it used. Probably should be moved to zope.publisher.interfaces.ftp as
>> well.
>
> FTP is in the same boat as XML-RPC. Today, very few developers care to
> provide a dynamic FTP view of anything. WebDAV usually wins over FTP
> because adding SSL to WebDAV is easy. All FTP artifacts should move to a
> separate package.

Then, there's the same option and the same problem as one for XMLRPC,
described above. :-)

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

nadako at gmail

Aug 21, 2009, 2:38 PM

Post #7 of 24 (2877 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

2009/8/21 Dan Korostelev <nadako [at] gmail>:

> Browser view directives (browser:page and friends) - move this to some
> "zope.browserpage" package and make its structure more clean, so
> people could understand the magic of browser page class generation.
> :-)

Silly me, I forgot that browser page directives have the "menu" and
"title" arguments to integrate browser pages with menus!

But I'd like to see browser pages usable without using that browser
menu implementation, so I want to discuss one more proposition: make
browser page directives smarter, so they wouldn't depend hadly on
menus and support menu item registration for pages only when
"zope.browsermenu" is installed (and raise an error if browsermenu is
not installed and user tried to use "menu" argument). This won't hurt
any current zope.app.publisher's users, but can confuse new users who
will be learning these zcml directives. But I am sure that good
documentation can help here. :-)

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

mh at gocept

Aug 22, 2009, 5:21 AM

Post #8 of 24 (2855 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Am 21.08.2009 um 23:14 schrieb Dan Korostelev:
> 2009/8/22 Shane Hathaway <shane [at] hathawaymix>:
>> Hi Dan,
>>
>> I'll provide feedback for a few parts of your proposal.
> Thanks
>
>> Few developers care about XML-RPC these days. Most web developers
>> are now
>> working with REST, JSON, and other similar stuff. It's probably
>> best to
>> move all XML-RPC artifacts, including those in zope.publisher, to a
>> single
>> package, so that most developers can safely ignore the XML-RPC code.
>
> That's a good point. After a quick look, it seems to be easy to move
> xmlrpc-related things from zope.publisher and zope.app.publisher to
> new zope.xmlrpc package. One problem is how to make BBB imports then.
> It doesn't look good to me to make zope.publisher dependent on
> zope.xmlrpc for xmlrpc stuff, but moving things without BBB imports
> will break applications that currently uses zope.publisher xmlrpc. One
> option is to use the notorious "extra" dependencies,

Another option are conditional imports: only import from zope.xmlrpc
when it does not lead to an import error.

Yours sincerely,
--
Michael Howitz � mh [at] gocept � software developer
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 8 � fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

mh at gocept

Aug 22, 2009, 5:27 AM

Post #9 of 24 (2859 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Am 21.08.2009 um 21:06 schrieb Dan Korostelev:
[...]
> ILogin, ILogout from zope.app.publisher.interfaces.http - looks like
> these don't really mean anything and are used only in
> zope.app.security. I'd move them to zope.app.security even without BBB
> imports (not to make zope.app.publisher dependent on
> zope.app.security), but maybe I just don't know something about them?
> :)

z3c.layer.pagelet also uses these interfaces to re-implement login/
logout like zope.app.security but by using pagelets and viewlets.
So it would be nice to have a better place for these interfaces, so
z3c.layer.pagelet does not need to depend on zope.app.security.

Yours sincerely,
--
Michael Howitz � mh [at] gocept � software developer
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 8 � fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

srichter at cosmos

Aug 24, 2009, 5:39 AM

Post #10 of 24 (2839 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

On Friday 21 August 2009, Dan Korostelev wrote:
> BrowserSkinsVocabulary - this can be moved to zope.publisher.browser
> and rewritten with zope.schema's SimpleVocabulary not to introduce
> dependency on zope.componentvocabulary.

-1. Why? The reason we wrote the zope.componentvocabulary code originally was
exactly to avoid the constant reimplementation of that code.

Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

nadako at gmail

Aug 24, 2009, 6:00 AM

Post #11 of 24 (2830 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

2009/8/24 Stephan Richter <srichter [at] cosmos>:
> On Friday 21 August 2009, Dan Korostelev wrote:
>> BrowserSkinsVocabulary - this can be moved to zope.publisher.browser
>> and rewritten with zope.schema's SimpleVocabulary not to introduce
>> dependency on zope.componentvocabulary.
>
> -1. Why? The reason we wrote the zope.componentvocabulary code originally was
> exactly to avoid the constant reimplementation of that code.

Well, the only reason is that zope.publisher currently doesn't depend
on zope.componentvocabulary. But it doesn't matter for me personally,
so if steering group decides that it's okay to add a dependency on
zope.componentvocabulary to zope.publisher, I won't rewrite the
vocabulary with SimpleVocabulary :-)

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

nadako at gmail

Aug 24, 2009, 10:02 AM

Post #12 of 24 (2835 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

2009/8/22 Michael Howitz <mh [at] gocept>:
> Am 21.08.2009 um 21:06 schrieb Dan Korostelev:
> [...]
>>
>> ILogin, ILogout from zope.app.publisher.interfaces.http - looks like
>> these don't really mean anything and are used only in
>> zope.app.security. I'd move them to zope.app.security even without BBB
>> imports (not to make zope.app.publisher dependent on
>> zope.app.security), but maybe I just don't know something about them?
>> :)
>
> z3c.layer.pagelet also uses these interfaces to re-implement login/logout
> like zope.app.security but by using pagelets and viewlets.
> So it would be nice to have a better place for these interfaces, so
> z3c.layer.pagelet does not need to depend on zope.app.security.

Are these interfaces used for anything else than just declaring them
as implemented? :-) I don't see much sense in them, because they are
too abstract and it's hard to understand what they are for, so I'd get
just rid of them in z3c.layer.pegelet.

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

dev at projekt01

Aug 24, 2009, 1:55 PM

Post #13 of 24 (2836 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Hi Dan

> Betreff: Re: [Zope-dev] Proposal: zope.app.publisher refactoring
>
> 2009/8/22 Michael Howitz <mh [at] gocept>:
> > Am 21.08.2009 um 21:06 schrieb Dan Korostelev:
> > [...]
> >>
> >> ILogin, ILogout from zope.app.publisher.interfaces.http -
> looks like
> >> these don't really mean anything and are used only in
> >> zope.app.security. I'd move them to zope.app.security even without
> >> BBB imports (not to make zope.app.publisher dependent on
> >> zope.app.security), but maybe I just don't know something
> about them?
> >> :)
> >
> > z3c.layer.pagelet also uses these interfaces to re-implement
> > login/logout like zope.app.security but by using pagelets
> and viewlets.
> > So it would be nice to have a better place for these interfaces, so
> > z3c.layer.pagelet does not need to depend on zope.app.security.
>
> Are these interfaces used for anything else than just
> declaring them as implemented? :-) I don't see much sense in
> them, because they are too abstract and it's hard to
> understand what they are for, so I'd get just rid of them in
> z3c.layer.pegelet.

Everything which has to do with login has nothing to do
in z3c.layer.pagelet.
z3c.layer.pagelet should only offer a working setup for
pagelet based traversal stuff and error handling.

Regards
Roger ineichen

> --
> WBR, Dan Korostelev
> _______________________________________________
> Zope-Dev maillist - Zope-Dev [at] zope
> 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 )
>

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

mh at gocept

Aug 24, 2009, 11:26 PM

Post #14 of 24 (2801 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Am 24.08.2009 um 19:02 schrieb Dan Korostelev:
> 2009/8/22 Michael Howitz <mh [at] gocept>:
>> Am 21.08.2009 um 21:06 schrieb Dan Korostelev:
[...]
>> z3c.layer.pagelet also uses these interfaces to re-implement login/
>> logout
>> like zope.app.security but by using pagelets and viewlets.
>> So it would be nice to have a better place for these interfaces, so
>> z3c.layer.pagelet does not need to depend on zope.app.security.
>
> Are these interfaces used for anything else than just declaring them
> as implemented? :-) I don't see much sense in them, because they are
> too abstract and it's hard to understand what they are for, so I'd get
> just rid of them in z3c.layer.pegelet.

I looked a bit into the code of z3c.layer.pagelet and it seems that
you are right.
Only the ILogin interface is used there. (The ILogout interface is the
one from zope.authentication which seems to be semantically different
from the one in zope.app.publisher.interfaces.http.)
Although it is a bad idea to copy interfaces, z3c.layer.pagelet could
reinvent ILogin if it is really needed.

Yours sincerely,
--
Michael Howitz � mh [at] gocept � software developer
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 8 � fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

mh at gocept

Aug 24, 2009, 11:31 PM

Post #15 of 24 (2810 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Am 24.08.2009 um 22:55 schrieb Roger Ineichen:
[...]
> Everything which has to do with login has nothing to do
> in z3c.layer.pagelet.
> z3c.layer.pagelet should only offer a working setup for
> pagelet based traversal stuff and error handling.

Until we find a better place for it I'd like to keep it there as it is
a basic implementation (ported from zope.app.security) of login/logout
using pagelets/viewlets. It is the pagelet version of login/logout as
the other parts are the pagelet version of error handling and traversal.

Yours sincerely,
--
Michael Howitz � mh [at] gocept � software developer
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 8 � fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

dev at projekt01

Aug 25, 2009, 5:39 AM

Post #16 of 24 (2805 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Hi Michael

> Betreff: Re: AW: [Zope-dev] Proposal: zope.app.publisher refactoring
>
> Am 24.08.2009 um 22:55 schrieb Roger Ineichen:
> [...]
> > Everything which has to do with login has nothing to do in
> > z3c.layer.pagelet.
> > z3c.layer.pagelet should only offer a working setup for
> pagelet based
> > traversal stuff and error handling.
>
> Until we find a better place for it I'd like to keep it there
> as it is a basic implementation (ported from
> zope.app.security) of login/logout using pagelets/viewlets.
> It is the pagelet version of login/logout as the other parts
> are the pagelet version of error handling and traversal.

I was looking another time at the z3c.layer.pagelet package.

I agree that the added authentication support is usefull and
was missing in the first releases. The loginForm.html pagelet
should stay there. But we should move the viewlets to another
package since this is optional and another concept which is not
really needed by pagelets. e.g. z3c.authviewlet or so.

Another reason for moving this viewlets is that this login/
logout viewlets are usfull too without using pagelets.

Regards
Roger Ineichen

> Yours sincerely,
> --
> Michael Howitz � mh [at] gocept � software developer gocept
> gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) �
> germany http://gocept.com � tel +49 345 1229889 8 � fax +49
> 345 1229889 1 Zope and Plone consulting and development
>
>

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Aug 25, 2009, 9:41 AM

Post #17 of 24 (2805 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Hey,

Shane Hathaway wrote:
[snip]
> Few developers care about XML-RPC these days. Most web developers are
> now working with REST, JSON, and other similar stuff. It's probably
> best to move all XML-RPC artifacts, including those in zope.publisher,
> to a single package, so that most developers can safely ignore the
> XML-RPC code.

+1 on this general direction.

>> IFTPDirectoryPublisher interface - not sure what's this and where is
>> it used. Probably should be moved to zope.publisher.interfaces.ftp as
>> well.
>
> FTP is in the same boat as XML-RPC. Today, very few developers care to
> provide a dynamic FTP view of anything. WebDAV usually wins over FTP
> because adding SSL to WebDAV is easy. All FTP artifacts should move to
> a separate package.

+1 as well.

I've recorded this information in the Zope Toolkit decisions document,
just so we know where we're heading.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Aug 25, 2009, 9:43 AM

Post #18 of 24 (2791 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Dan Korostelev wrote:
> 2009/8/21 Dan Korostelev <nadako [at] gmail>:
>
>> Browser view directives (browser:page and friends) - move this to some
>> "zope.browserpage" package and make its structure more clean, so
>> people could understand the magic of browser page class generation.
>> :-)
>
> Silly me, I forgot that browser page directives have the "menu" and
> "title" arguments to integrate browser pages with menus!
>
> But I'd like to see browser pages usable without using that browser
> menu implementation, so I want to discuss one more proposition: make
> browser page directives smarter, so they wouldn't depend hadly on
> menus and support menu item registration for pages only when
> "zope.browsermenu" is installed (and raise an error if browsermenu is
> not installed and user tried to use "menu" argument). This won't hurt
> any current zope.app.publisher's users, but can confuse new users who
> will be learning these zcml directives. But I am sure that good
> documentation can help here. :-)

+1 if we can make it smarter to break this dependency (but not too
smart; I'm not sure how easy this would be).

Regadrs,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Aug 25, 2009, 9:46 AM

Post #19 of 24 (2801 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Dan Korostelev wrote:
> 2009/8/24 Stephan Richter <srichter [at] cosmos>:
>> On Friday 21 August 2009, Dan Korostelev wrote:
>>> BrowserSkinsVocabulary - this can be moved to zope.publisher.browser
>>> and rewritten with zope.schema's SimpleVocabulary not to introduce
>>> dependency on zope.componentvocabulary.
>> -1. Why? The reason we wrote the zope.componentvocabulary code originally was
>> exactly to avoid the constant reimplementation of that code.
>
> Well, the only reason is that zope.publisher currently doesn't depend
> on zope.componentvocabulary. But it doesn't matter for me personally,
> so if steering group decides that it's okay to add a dependency on
> zope.componentvocabulary to zope.publisher, I won't rewrite the
> vocabulary with SimpleVocabulary :-)

For the reasons of code stability let's rely on zope.componentvocabulary
then, at least for now. zope.componentvocabulary doesn't look like it
adds serious dependencies.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Aug 25, 2009, 10:02 AM

Post #20 of 24 (2801 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Hi there,

Here are some steering-groupish responses.

General note: I'm quite enthusiastic about the general plan to clean up
zope.app.publisher! Thanks for bringing this up!

Dan Korostelev wrote:
> Menu mechanism (the browser:menuItem directive and friends) - move
> this to the new "zope.browsermenu" package. This should be easy as
> nothing else in zope.app.publisher seem to depend on menus.

+1. You noted elsewhere there's a dependency from the browser:page
directive on this too. If you can make it smart enough in a simple way
to only depend on it if zope.browsermenu is actually installed, let's do
that.

> Browser view directives (browser:page and friends) - move this to some
> "zope.browserpage" package and make its structure more clean, so
> people could understand the magic of browser page class generation.
> :-)

+1.

> BrowserSkinsVocabulary - this can be moved to zope.publisher.browser
> and rewritten with zope.schema's SimpleVocabulary not to introduce
> dependency on zope.componentvocabulary.

As noted elsewhere, let's keep the dependency on
zope.componentvocabulary for now, unless this introduces more
dependencies to zope.publisher in *addition* to the introduction of
zope.componentvocabulary itself.

> ManagementViewSelector (the @@SelectedManagementView.html view) -
> leave it there as is.

+1. Anything ZMI-ish stays.

> Resource mechanism (files, directories, etc.) - probably the most
> complicated code, but it should be easy to move it to the new
> "zope.browserresource" package. One problem is with
> PageTemplateResource that introduces a dependency on
> zope.pagetemplate. It should probably moved to another package, like
> "zope.ptresource" and made dependent on z3c.ptcompat to support
> chameleon engine.

+1 on this strategy, also about factoring out zope.ptresource. This is a
less commonly used resource anyway as far as I know, as resources are
generally assumed to be static.

> ModifiableBrowserLanguages implementation - move to
> zope.publisher.browser. It's the useful thing that won't introduce any
> new dependencies.

+1

> "date" fieldconverter - I don't think anyone uses it, I'd leave it
> there as is and forget about it :)

I'm not sure about fieldconverters in general. Shane worked on a WSGI
implementation of fieldconverters instead. We could move it
zope.publisher fairly easily, except that it depends on parseDateTime in
zope.datetime. Let's leave it there for the time being, and see what
happens. We can always move it later.

> http.zcml - this file contains security declarations for
> zope.publisher's HTTP-related classes. move them to zope.publisher.

+1

> xmlprc

As noted elsewhere, I'd be nice if we had a zope.xmlrpc which
consolidated all the XML-RPC related code into a single package.

Same applies for FTP support.

We don't need to fully figure this out yet to start pulling some of the
other stuff out first, though.

> ILogin, ILogout from zope.app.publisher.interfaces.http - looks like
> these don't really mean anything and are used only in
> zope.app.security. I'd move them to zope.app.security even without BBB
> imports (not to make zope.app.publisher dependent on
> zope.app.security), but maybe I just don't know something about them?
> :)

I'll follow your decision here, I saw some further discussion elsewhere..

> That's all for now. I'd like to see some
> comments/propositions/objections before I start. Also, maybe there are
> more beautiful names for new packages?

Concerning naming:

You have zope.browsermenu, zope.browserpage, zope.browserresource. I
propose instead we name them zope.menu, zope.page and zope.resource. I
think we can safely claim these names in the 'zope' namespace as these
*are* the Zope Toolkit menu, page and resource implementations.

If we can consolidate the XML-RPC and FTP-related code into separate
packages as well, we'd end up with zope.xmlrpc and zope.ftp too.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

nadako at gmail

Aug 25, 2009, 10:13 AM

Post #21 of 24 (2797 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

2009/8/25 Martijn Faassen <faassen [at] startifact>:

> You have zope.browsermenu, zope.browserpage, zope.browserresource. I
> propose instead we name them zope.menu, zope.page and zope.resource.

-1 These things are really only for browser, and ZCML directives are
in "browser" namespace, while, for example, "zope.resource" is a quite
abstract name that could be taken by more appropriate package in
future.

> I think we can safely claim these names in the 'zope' namespace as
> these *are* the Zope Toolkit menu, page and resource
> implementations.

I'm not sure if they are "reusable without having to buy into the rest
of the Zope Toolkit". Currently these packages have a note that they
are not reusable, as recommended in steering group decisions list,
because they depend on the publishing system, which is a really large
part.

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Aug 27, 2009, 5:43 AM

Post #22 of 24 (2731 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Dan Korostelev wrote:
> 2009/8/25 Martijn Faassen <faassen [at] startifact>:
>
>> You have zope.browsermenu, zope.browserpage, zope.browserresource. I
>> propose instead we name them zope.menu, zope.page and zope.resource.
>
> -1 These things are really only for browser, and ZCML directives are
> in "browser" namespace, while, for example, "zope.resource" is a quite
> abstract name that could be taken by more appropriate package in
> future.

The namespace argument is a good point, but I have my doubts we'll find
something more *real* for the menu, resource or page implementation of
the ZTK than the ones we've all been using for many many years now. I'm
+0 about zope.browser*, and still prefer zope.page and friends.

Anyway, we'll keep them as you made them as you already did the work, I
don't think anyone really minds these names.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

mh at gocept

Sep 22, 2009, 1:43 AM

Post #23 of 24 (1925 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Am 25.08.2009 um 14:39 schrieb Roger Ineichen:
[...]
> I was looking another time at the z3c.layer.pagelet package.
>
> I agree that the added authentication support is useful and
> was missing in the first releases. The loginForm.html pagelet
> should stay there. But we should move the viewlets to another
> package since this is optional and another concept which is not
> really needed by pagelets. e.g. z3c.authviewlet or so.

Right. Nice naming idea, I'll put it on my to do list.

> Another reason for moving this viewlets is that this login/
> logout viewlets are useful too without using pagelets.

Right, too.

Yours sincerely,
--
Michael Howitz � mh [at] gocept � software developer
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 8 � fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

dev at projekt01

Nov 30, 2009, 8:18 AM

Post #24 of 24 (1271 views)
Permalink

Re: Proposal: zope.app.publisher refactoring [In reply to]

Hi Michael

I just implemented z3c.authviewlet and moved the
authentication viewlet part from z3c.layer.pagelet
into this new package. The z3c.layer.pagelet package
does not use the z3c.authviewlet package as a dependency.
This means you need to include the z3c.authviewlet
package in your buildout.cfg and configure it in your
configure.zcml.

I just released both packages.

Regards
Roger Ineichen

> -----Urspr�ngliche Nachricht-----
> Von: Michael Howitz [mailto:mh [at] gocept]
> Gesendet: Dienstag, 22. September 2009 10:43
> An: dev [at] projekt01
> Cc: Zope Developers
> Betreff: Re: AW: AW: [Zope-dev] Proposal: zope.app.publisher
> refactoring
>
> Am 25.08.2009 um 14:39 schrieb Roger Ineichen:
> [...]
> > I was looking another time at the z3c.layer.pagelet package.
> >
> > I agree that the added authentication support is useful and was
> > missing in the first releases. The loginForm.html pagelet
> should stay
> > there. But we should move the viewlets to another package
> since this
> > is optional and another concept which is not really needed by
> > pagelets. e.g. z3c.authviewlet or so.
>
> Right. Nice naming idea, I'll put it on my to do list.
>
> > Another reason for moving this viewlets is that this login/ logout
> > viewlets are useful too without using pagelets.
>
> Right, too.
>
> Yours sincerely,
> --
> Michael Howitz � mh [at] gocept � software developer gocept
> gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) �
> germany http://gocept.com � tel +49 345 1229889 8 � fax +49
> 345 1229889 1 Zope and Plone consulting and development
>
>

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads