[Zope3-dev] Re: How does the rotterdam skin work?
Michael Jansen schrieb: Hi Is there anywhere an explanation how the rotterdam skin works. Some insight's to how an when which parts are selected? How to use and expand it? I think i'm making progress in understanding how the parts click together, but some additional insights would be nice. The tutorials i found about skins just told me to create a template.pt and a dialog_macros.pt and so on. But not why. And when either one is used. I think i understand some parts of that now and if there is no such thing like a explanation of this logics i would try to blame myself by writing down my findings so far. Btw. I think doc/skins/README.txt is a little bit out of date. I think the Rotterdam skin is doomed. I'd rather create my own skin than try to expand it. Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: How does the rotterdam skin work?
Tonico Strasser wrote: > Michael Jansen schrieb: > >> Hi >> >> Is there anywhere an explanation how the rotterdam skin works. Some >> insight's to how an when which parts are selected? >> >> How to use and expand it? >> >> I think i'm making progress in understanding how the parts click >> together, but some additional insights would be nice. >> >> The tutorials i found about skins just told me to create a >> template.pt and a dialog_macros.pt and so on. But not why. And when >> either one is used. >> I think i understand some parts of that now and if there is no such >> thing like a explanation of this logics i would try to blame myself >> by writing down my findings so far. >> >> Btw. I think doc/skins/README.txt is a little bit out of date. > > > I think the Rotterdam skin is doomed. I'd rather create my own skin > than try to expand it. > > Tonico > Hi! the problem is not in the skin itself, but in the model used to create "skins". Filesystem-based skins that depend on ZPT macros are doomed by definition, unless they are designed to cover most of the site layouts you'll find on the internet (for instance the Plone skin is quite generic). But maintaining such a generic skin (HTML + CSS) is a lot of work. Also there is a problem with the target audience: ZPT programmers are not always good graphic designers and UI/ graphic designers are not always good at ZPT / python. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: How does the rotterdam skin work?
Jean-Marc Orliaguet schrieb: Tonico Strasser wrote: Michael Jansen schrieb: Hi Is there anywhere an explanation how the rotterdam skin works. Some insight's to how an when which parts are selected? How to use and expand it? I think i'm making progress in understanding how the parts click together, but some additional insights would be nice. The tutorials i found about skins just told me to create a template.pt and a dialog_macros.pt and so on. But not why. And when either one is used. I think i understand some parts of that now and if there is no such thing like a explanation of this logics i would try to blame myself by writing down my findings so far. Btw. I think doc/skins/README.txt is a little bit out of date. I think the Rotterdam skin is doomed. I'd rather create my own skin than try to expand it. Tonico Hi! the problem is not in the skin itself, but in the model used to create "skins". Filesystem-based skins that depend on ZPT macros are doomed by definition, unless they are designed to cover most of the site layouts you'll find on the internet (for instance the Plone skin is quite generic). But maintaining such a generic skin (HTML + CSS) is a lot of work. Yes, and the ZMI-"design" is also broken IMHO. Actions below tabs is not intuitive, the navtree does not feel good etc. I find the classic ZMI much better in this respect. I guess I'm confusing the ZMI with a Skin definition :) Memo: Management Interface != Skin <=> Skin != Management Interface Also there is a problem with the target audience: ZPT programmers are not always good graphic designers and UI/ graphic designers are not always good at ZPT / python. I agree. Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: How does the rotterdam skin work?
Tonico Strasser wrote: > Jean-Marc Orliaguet schrieb: > > Yes, and the ZMI-"design" is also broken IMHO. Actions below tabs is > not intuitive, the navtree does not feel good etc. I find the classic > ZMI much better in this respect. > > I guess I'm confusing the ZMI with a Skin definition :) > > Memo: Management Interface != Skin <=> Skin != Management Interface > they are very much the same in a Zope3 context I think since the separation between software and content is done on a lower level, whereas Zope2 tries to emulate the separation on a skin level. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: How does the rotterdam skin work?
Jean-Marc Orliaguet wrote: Tonico Strasser wrote: Michael Jansen schrieb: Hi Is there anywhere an explanation how the rotterdam skin works. Some insight's to how an when which parts are selected? How to use and expand it? I think i'm making progress in understanding how the parts click together, but some additional insights would be nice. The tutorials i found about skins just told me to create a template.pt and a dialog_macros.pt and so on. But not why. And when either one is used. I think i understand some parts of that now and if there is no such thing like a explanation of this logics i would try to blame myself by writing down my findings so far. Btw. I think doc/skins/README.txt is a little bit out of date. I think the Rotterdam skin is doomed. I'd rather create my own skin than try to expand it. Tonico Hi! the problem is not in the skin itself, but in the model used to create "skins". Filesystem-based skins that depend on ZPT macros are doomed by definition, unless they are designed to cover most of the site layouts you'll find on the internet (for instance the Plone skin is quite generic). But maintaining such a generic skin (HTML + CSS) is a lot of work. While I wouldn't put it *quite* so harshly, I agree. Also there is a problem with the target audience: ZPT programmers are not always good graphic designers and UI/ graphic designers are not always good at ZPT / python. ZPT isn't supposed to be grouped with Python. ZPT was definately designed for Web Designers -- people who use tools like Dreamwever. Except for the macro issue, ZPT has been pretty (as opposed to completely) sucessful in our experience. One thing I'd definately do differently if I could go back in time to when we invented ZPT is I would absolutely not include python expressions. In generally, I would have made them computationally less powerful. Our intent was definately that people would not do complex computations in ZPT but people have definately abused the power we've provided. I think the biggest problem with the ZPT macro approach to look and feel concerns are not separated. CPSSkins deals with this in it's own way. I'd like to see an approach for people not using CPSSkins. :) I think that this will involve some sort of post-publishing phase in the publication process. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: How does the rotterdam skin work?
Hi Thanx for the answers so far. OK. Just a question that occured to me after posting this. Is this the right newsgroup? I'm subscribed here for over a year. Just lurking, never posted before. So just forgot looking for a users list. I guess there is a zope3-users list? > >>>The tutorials i found about skins just told me to create a > >>>template.pt and a dialog_macros.pt and so on. But not why. And when > >>>either one is used. > >>>I think i understand some parts of that now and if there is no such > >>>thing like a explanation of this logics i would try to blame myself > >>>by writing down my findings so far. > >>> > >>>Btw. I think doc/skins/README.txt is a little bit out of date. > >> > >> > >>I think the Rotterdam skin is doomed. I'd rather create my own skin > >>than try to expand it. But i ( have to / should ) use the rotterdam skin as a blueprint for my new one? Or are there better alternatives? As i wrote the tutorials just mention the rotterdam skin! Has one of the books better documentation? Should i use the schooltools skin? I'm still willing to document my findings on how to create a zope3 skin. Michael Jansen - This mail sent through IMP: http://horde.org/imp/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] hurry.query in Zope 3.2?
Hi there, Would there be any interest in merging hurry.query into Zope 3.2? What it does: hurry.query - higher level query system built on top of the Zope 3 catalog. Some inspiration came from Dieter Maurer's AdvancedQuery. See src/hurry/query/query.txt for documentation. Here's the code: http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/ And here's a doctest: http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/query.txt Of course, it probably needs a review and adaptations before it's accepted, and time until the feature freeze in november is short. It would be a very useful addition to Zope 3's featureset, however. It exposes features of various indexes that the normal catalog API does not expose, or if so, only very obscurely. :) Now that I think of it, exposing the ZCTextIndex properly with the various features involved may need the most work. If there's interest, I'd really appreciate volunteers for putting up a proposal on the wiki and integrating it into the codebase. This way it'd get a review by that person. If it'd be up to myself I likely won't have time... By the way, is zc.catalog up for merging with Zope 3.2, or won't this happen yet? hurry.query has a dependency on zc.catalog, though I believe I succeeded in keeping this optional. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: How does the rotterdam skin work?
Hi Jim, just de-lurking for a moment: On 10/24/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > I think the biggest problem with the ZPT macro approach to look and feel > concerns are not separated. CPSSkins deals with this in it's own way. I couldn't quite parse that. What is not separated from what? thanks, -PW -- http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: How does the rotterdam skin work?
Paul Winkler wrote: Hi Jim, just de-lurking for a moment: On 10/24/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > I think the biggest problem with the ZPT macro approach to look and feel concerns are not separated. CPSSkins deals with this in it's own way. I couldn't quite parse that. What is not separated from what? Sorry, I assumed too much context. At a minimum, the concerns of the page author are not separated from the concerns of the site designer. Put another way, the concerns of the person creating the content well are mixed up with the concerns of people creating the "O-wrap". There are probably other concerns that should be separated too. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: How does the rotterdam skin work?
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> Hi! >> the problem is not in the skin itself, but in the model used to create >> "skins". Filesystem-based skins that depend on ZPT macros are doomed by >> definition, unless they are designed to cover most of the site layouts >> you'll find on the internet (for instance the Plone skin is quite >> generic). But maintaining such a generic skin (HTML + CSS) is a lot >> of work. > > > While I wouldn't put it *quite* so harshly, I agree. > >> Also there is a problem with the target audience: ZPT programmers are >> not always good graphic designers and UI/ graphic designers are not >> always good at ZPT / python. > > > ZPT isn't supposed to be grouped with Python. ZPT was definately designed > for Web Designers -- people who use tools like Dreamwever. Except for > the macro > issue, ZPT has been pretty (as opposed to completely) sucessful in our > experience. One thing I'd definately do differently if I could go back > in time to when we invented ZPT is I would absolutely not include python > expressions. In generally, I would have made them computationally less > powerful. Our intent was definately that people would not do complex > computations in ZPT but people have definately abused the power we've > provided. > > I think the biggest problem with the ZPT macro approach to look and feel > concerns are not separated. CPSSkins deals with this in it's own way. > I'd like to see an approach for people not using CPSSkins. :) I think > that > this will involve some sort of post-publishing phase in the publication > process. > > Jim > > Sure, the separation between content and presentation is very clean in ZPT (assuming python: expressions did not exist..:-) ). The difference in the two approaches are more deeply grounded I think: - the page template model starts from the idea of individual web pages (easy to understand for a web designer) that expands into a whole site by creating abstractions such as 'page headers', 'slots', etc.. The starting point is a web *page* which becomes a generic 'template', and eventually a site as a collection of published objects that use the same templates. The process is from the particular to the general, the 'template' make it possible to do the transition. - with cpsskins, the process goes the other way: from general to particular. The difficulty lies instead in creating particular pages that do not follow any given pattern. The logic is close to the development of an application UI that tries to emulate web sites. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: How does the rotterdam skin work?
Jim Fulton wrote: > Paul Winkler wrote: > >> Hi Jim, just de-lurking for a moment: >> >> On 10/24/05, Jim Fulton <[EMAIL PROTECTED]> wrote: >> > I think the biggest problem with the ZPT macro approach to look >> and feel >> >>> concerns are not separated. CPSSkins deals with this in it's own way. >> >> >> >> I couldn't quite parse that. What is not separated from what? > > > Sorry, I assumed too much context. > > At a minimum, the concerns of the page author are not separated from the > concerns of the site designer. Put another way, the concerns of the > person > creating the content well are mixed up with the concerns of people > creating the > "O-wrap". There are probably other concerns that should be separated > too. > > Jim > To put it differently: with page templates you try to separate concerns, by splitting things into: content, presentation, portlets, viewlets, macros, local variations in the presentation (put your concept here) using the TAL language. But what you start from is in fact a HTML page. In cpsskins you start from the individual concepts (portlets, widgets, styles, slots, pages, themes, perspectives. ...) that can be related in different ways and the job of the rendering engine is create a particular composition based on the instructions given by different categories of users (UI designers. site designer, application designers, users, .. ) /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] tagged value handling inconsequent for interface methods and attributes and interfaces themself
On Wednesday 19 October 2005 05:51, Grégoire Weber wrote:
> while modeling the external API of an application I'd like to use the
> tagged value feature of the interface implementation.
>
> It seems to me that handling tagged values is implemented inconsequently.
I plan to make a proposal that would allow the following:
import zope.interface
class IFoo(zope.interface.Interface):
attr = zope.interface.Attribute('doc string')
def method():
"""doc string"""
interfaceTags = zope.interface.interfaces.ITaggedValues(IFoo)
interfaceTags.someVariable = value
attributeTags = zope.interface.interfaces.ITaggedValues(IFoo['attr'])
attributeTags.someVariable = value
methodTags = zope.interface.interfaces.ITaggedValues(IFoo['method'])
methodTags.someVariable = value
Alternatively, I would like to try the following as well:
from zope.interface.interfaces import ITaggedValue
class IFoo(zope.interface.Interface):
attr = zope.interface.Attribute('doc string')
ITaggedValues(attr).someVariable = value
Any comments before I spend time writing this up?
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.wfmc UML
Adam Groszer wrote: Dear Jim, I tried to sketch an UML diagram from the zope.wfmc package. Can you please have a look if it is half way correct? If I ignore the attributes, it looks pretty reasonable. The picture is a bit incomplete because it doesn't show work items, which are, after all, application defined. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Interface-dev] Re: [Zope3-dev] tagged value handling inconsequent for interface methods and attributes and interfaces themself
On 10/24/05, Stephan Richter <[EMAIL PROTECTED]> wrote: > Any comments before I spend time writing this up? Sounds like a good approach to me. I'd like something a little nicer to work with than the current model. -Fred -- Fred L. Drake, Jr. "Society attacks early, when the individual is helpless." --B.F. Skinner ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Interface-dev] Re: [Zope3-dev] tagged value handling inconsequent for interface methods and attributes and interfaces themself
Stephan Richter wrote:
On Wednesday 19 October 2005 05:51, Grégoire Weber wrote:
while modeling the external API of an application I'd like to use the
tagged value feature of the interface implementation.
It seems to me that handling tagged values is implemented inconsequently.
I plan to make a proposal that would allow the following:
import zope.interface
class IFoo(zope.interface.Interface):
attr = zope.interface.Attribute('doc string')
def method():
"""doc string"""
interfaceTags = zope.interface.interfaces.ITaggedValues(IFoo)
interfaceTags.someVariable = value
attributeTags = zope.interface.interfaces.ITaggedValues(IFoo['attr'])
attributeTags.someVariable = value
methodTags = zope.interface.interfaces.ITaggedValues(IFoo['method'])
methodTags.someVariable = value
Alternatively, I would like to try the following as well:
from zope.interface.interfaces import ITaggedValue
class IFoo(zope.interface.Interface):
attr = zope.interface.Attribute('doc string')
ITaggedValues(attr).someVariable = value
Any comments before I spend time writing this up?
This won't work for tags whos keys are not python identifiers.
I'd like to encourage people to use ids (dotted names or urls) for
tags.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.wfmc UML
On Monday 24 October 2005 16:40, Jim Fulton wrote: > > I tried to sketch an UML diagram from the zope.wfmc package. > > Can you please have a look if it is half way correct? > > If I ignore the attributes, it looks pretty reasonable. > The picture is a bit incomplete because it doesn't show > work items, which are, after all, application defined. What software are you using to look at it? I tried Umbrello and nothing showed up other than the class definitions. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Interface-dev] Re: [Zope3-dev] tagged value handling inconsequent for interface methods and attributes and interfaces themself
On Monday 24 October 2005 16:44, Jim Fulton wrote: > > Any comments before I spend time writing this up? > > This won't work for tags whos keys are not python identifiers. > I'd like to encourage people to use ids (dotted names or urls) for > tags. Okay, in this case I'll implement a mapping interface, instead an attribute one. Is that the change you were hinting at? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Interface-dev] Re: [Zope3-dev] tagged value handling inconsequent for interface methods and attributes and interfaces themself
Stephan Richter wrote: On Monday 24 October 2005 16:44, Jim Fulton wrote: Any comments before I spend time writing this up? This won't work for tags whos keys are not python identifiers. I'd like to encourage people to use ids (dotted names or urls) for tags. Okay, in this case I'll implement a mapping interface, instead an attribute one. Is that the change you were hinting at? I guess. The current api doesn't bother me enough to think hard about it. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.wfmc UML
Stephan Richter wrote: On Monday 24 October 2005 16:40, Jim Fulton wrote: I tried to sketch an UML diagram from the zope.wfmc package. Can you please have a look if it is half way correct? If I ignore the attributes, it looks pretty reasonable. The picture is a bit incomplete because it doesn't show work items, which are, after all, application defined. What software are you using to look at it? I tried Umbrello and nothing showed up other than the class definitions. Um, Mozilla. I just looked at the image. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[2]: [Zope3-dev] zope.wfmc UML
Hello Stephan, I did it with Sparx Enterprise Architect, is just a package export not the complete model. It's currently xmi 1.1, but if you need EA can export xmi 1.0 or xmi 1.2. Monday, October 24, 2005, 11:18:15 PM, you wrote: > On Monday 24 October 2005 16:40, Jim Fulton wrote: >> > I tried to sketch an UML diagram from the zope.wfmc package. >> > Can you please have a look if it is half way correct? >> >> If I ignore the attributes, it looks pretty reasonable. >> The picture is a bit incomplete because it doesn't show >> work items, which are, after all, application defined. > What software are you using to look at it? I tried Umbrello and nothing showed > up other than the class definitions. > Regards, > Stephan -- Best regards, Adammailto:[EMAIL PROTECTED] -- Quote of the day: If you explain so clearly that nobody can misunderstand, somebody will. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
