Re: [Zope3-dev] One namespace for ZCML
Stephan Richter wrote: That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). I do not think namespace declarations are dead chickens. For me declaring a namespace in ZCML is the same as importing a package or module in Python. You would not want all functions and classes in Python live in one namespace, would you? The more namespaces, the more needs to be learned, the more confusion. ZCML is not python, comparing the two isn't right. I'm all for simpler and simpler zcml... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Philipp von Weitershausen wrote: directives. I realize "somewhat" is fuzzy. Let me just say that I think ZCML has failed when Plone will have its own ZCML directives... There's a mailing list post from ages ago about going off and humping the leg of the next great thing. Plohn _will_ grow its own directives, simply because it can... you wait ;-) cheers, Chris - feeling cynical tonight, sorry... -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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: Zope 3 web root
Martin Aspeli wrote: I think that's certainly true for content-centric applications, which is what people seem to build the most of in Zope. But if you were storing 80 million records of numbers and short strings that you needed to query across multiple dimensions, you'd probably put them in postgresql. That depends. If the data is heirarchical, I'd stick with ZODB. IF I cared about seamless rollback I'd stick with ZODB. If I cared about a uniform storage for all data to do with a project, I'd stick with ZODB... Zope 3 should really have a better story on SQL. Not replace the ZODB, but show how in your code you best deal with an RDBMS. I think that should leverage existing python APIs and ORM tools (I think there's a place for both SQL-style queries and ORM, depending on how much you need "ad-hoc" queries or at least complex, one-off representations of data, and how much you need one logical view of your data), but there should be patterns and integration layers (if needed) to show how to get data from an RDBMS into a view, how to make an edit form for that data, and how to integrate that with the rest of your probably content-centric application. Yup, not gonna argue with any of that, if only for integrating with legacy systems... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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: Re: tal:define="..." considered harmful?
Martijn Faassen said the following on 2006-02-15 18:27: Aah, now I understand where the 'c' comes from. What about 'btal', browser tal? ctal. Client TAL; I see no reason to restrict this to browsers. This has neat and exiting implications for non-browser clients that understand java-script, (ie. wxJS http://wxjs.sourceforge.net/). And yes, I know that I am now making myself guilty of starting Yet Another Of Those Whatchawecallit Threads on a Zope-list. (*) /dario (*) though in reality it is really Martijn's fault. He started it by confusing the meaning of 'c' ;-) -- -- --- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley ___ 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 3 web root
On 2/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Wade Leftwich wrote: > > +1 from the standpoint of promoting corporate adoption, especially when > > combined with first-class citizenship for RDBMS. (In the corporation I > > work for, anyway.) > > Yes, RDBMS would become a first-class citizen. New users would be able > to write some page templates and SQL scripts on the filesystem and have > them work with no extra effort. I know I'd like that capability myself. How? How "first class"? Does first class mean "supports SQLite level features"? "MySQL"? Then what happens when you have people needing to use real commercial databases who find a serious lack of support for the features that they want or need? How would you tie that in? Without offending those who just want to use SQLlite to store comments? Would it be all manual SQL statements? Would the be through an O-R layer? What about those (like my company) who have customers on RDBMS and other storage systems that have complex data handling and security requirements that go far beyond most O-R mappers (especially those that appeal to those just wanting a web page to have comments?) Would it be a pain in the ass to integrate a completely custom and different data management layer in? Would it be easy? "extra effort?" This smells like Zope 2 development, but without the ZODB. Just a bunch of little templates and scripts and SQL statements on the file system. The best day in many of Bottlerocket's Zope 2 era RDBMS applications was when we moved them away from both models. Being neither an O-R mapper, nor just full of endless similar SQL statements for basic CRUD stuff (but still using them, as methods on Python classes usually, for custom queries). Personally, I think that a Data Mapper layer that used zope.schema would be very effective. This is essentially what we built in Zope 2, using Formulator. Formulator ensured the data was in a clean / common format and satisfied any constraints, and a very simple layer generated SQL Methods on the fly based on the filtered down data that came in / out. If we migrate any of those applications to Zope 3 and keep the same data model, I easily see us doing it using zope.schema and doing directlyProvides or something like that on what is produced. It's not a situation that works for everyone. But it's one that works for us and is adaptive to different storage solutions. Our 'enterprise' level data management works on a similar level, but with a lot more transformations going on as data flows to / from its sources (and that data management framework itself has no dependencies on Zope, but a simple Gateway allows us to use it with Zope 2 while letting Zope 2 acquire the page templates, authenticated user, etc). Anyways, it's a scenario that I like because the data in these situations is more important to me than whether it looks sorta-like a Python object, yet the boring and repetitive operations are still taken care of. I agree that better integration with external data should be a priority for Zope. But what does that mean? In theory, if something's a Python object it should work with Zope 3 with relative ease... If that's not the case, perhaps we need to look at how much work is required to take some random Python object that may be created by some random data access library and get it into a Zope 3 published web page. If it kicks and screams and resists security and interfaces, or what not, maybe we need to take a look at all of that. If it doesn't kick and scream, we just need clear documentation that's neither too short nor too wordy about what to do... "I just installed cElementTree and have an XML document that I've turned into a Python object. How can I show that in Zope?" > However, I expect ZODB to continue to be the dominant platform for > writing Zope applications, because ZODB is quite productive for writing > abstract applications. ZODB is also very productive in Zope 3 for writing concrete applications. Now that our ZODB databases aren't polluted with a mixture of business objects as well as scripts, icons, sql, templates, etc, the ZODB is a joy to work with. It's very productive for writing NEW applications. I see these other tutorials for every O-R backed database and I'm thinking - "you're only creating a two column table to do a to-do list... why do you even have an RDBMS? you're not generating SQL directly and yay - it turns the todos into Python booleans and strings! Well, uh, again, why even have an RDBMS?" An application that I just completed would have actually been very hard with an RDBMS (especially as data requirements changed - 'can we have that field be in the leg?'). It would have taken me a lot longer to implement if I had to keep switching my mind back and forth between SQL and Python. THIS IS A HUGE ADVANTAGE! Why do we act like we're embarrassed by the ZODB? With zc.catalog, schoolbell.relationships, and vocabularies, I was able to make widgets that assign and remove
Re: [Zope3-dev] Zope 3 web root
Jeff Shell wrote: Personally, I think that the ZODB is a terrific asset that has achieved a greater level of usability in Zope 3. At least, it has for us, now that we're no longer confused about whether the ZODB should house our persistent objects, or if it should house our icons and scripts and code and the RDBMS should be the store. I wouldn't want to downplay this advantage. No, we're still confused. Templates and scripts are code. Should they be in ZODB? Grrr, I hope not. I don't want to suffer that pain, fssync or no fssync. I invented the CMF skins tool primarily to pull a lot of templates and scripts out of ZODB. I invented Ape to pull them *all* out. Now I'm having trouble convincing myself to use Zope 3 because the problem has to be solved somehow yet again! I first thought fssync might solve the problem, but now I feel like it adds unnecessary complexity, similar to Ape. External Editor is also a good idea, but it exposes only a single file at a time. The web root idea is another possible solution. I'm sure there are others (such as an NFS view into ZODB, which I also did once!) Let's keep thinking for now. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Last chance to comment on Simplify skinning
Hey Gary,
thanks for your feedback.
> I like many parts of it. I didn't like the fact that the zcml ended
> up being longer.
Me neither :(.
> I didn't love that people had to start asking
> questions about interface types in order to register a skin.
> Interface types are a cost--another layer of abstraction, another
> potentially mind-blowing thing to explain.
Perhaps, perhaps not. I think the interface ZCML directive would be easy to
understand by itself ("Aha, so we register an interface. And we give it a
type, like, what kind of interface it is."), but I'm totally biased.
> You are already suggesting changing the zcml, and I'd like to see a
> compromise between the brevity of the current zcml and the conceptual
> clarity of your proposed changes.
>
> I tried to brainstorm, but didn't love what I came up with. Maybe it
> can take us somewhere. What if we still deprecated browser:layer but
> kept a redefined version of browser:skin? Then your zcml--
>
>interface=".interfaces.ShanghaiSkin"
>type="zope.publisher.interfaces.browser.IBrowserSkinType"
>/>
>
>component=".interfaces.ShanghaiSkin"
>provides="zope.publisher.interfaces.browser.IBrowserSkinType"
>name="ShanghaiSkin"
>/>
>
> could become
>
>name="ShanghaiSkin" />
>
> The rest of your example would remain the same.
As you can imagine I'm a bit hesitant about having too many specialized ZCML
directives like browser:skin. But I definitely see your point. I have the
following compromise to suggest. The 'interface' directive is used for two
things:
* Registering an interface as a utility. For that it will use the dotted name
of the interface.
* Optionally putting a type on an interface.
My suggestion is to add an optional 'name' parameter to it so that the
interface won't necessarily have to registere using its dotted name. Then we
can merge the 'interface' directive and the 'utility' directive from above
into one. It will basically have the same affect as your suggested
browser:skin directive and is only longer by the 'type' argument.
Other usecases I see for the extra 'name' argument: Content Types. For example:
So, this would be a very generic way of giving interfaces a type and name.
Generic means that it'd be used throughout Zope extensions and would therefore
provide a lot of consistency.
> It doesn't accomplish everything you set out to do, and that's a
> shame, but it feels like a compromise with a reasonable counter-
> argument: defining skins is a basic task often introduced early on
> with teaching Zope, and it's a shame to have to bloat the zcml and
> teach advanced topics too soon.
>
> I'd like to at least get the zcml out of this story.
I know my compromise does everything except that :). I think it's still better
to keep consistency in the ZCML directives than having nicely sounding
directives whose way of working isn't really explained just by their names.
Philipp
This message was sent using IMP, the Internet Messaging Program.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
Max M wrote: The problem is that all the people used to LAMP will come to Zope and think "Well I will need to think differently here. Thats a bother. I will use sql for everything like usual." And so we will get a lot of duplicated efforts and half-baked Zope developers, who will desperately try to use Zope for SQL development. Let us not worry about the "half-baked developers" but instead think about how the ideas in Zope itself can benefit a larger community of developers. Remember its the "Z Object Publishing Enviroment"? Has been around a while with ZSQL support and the net is littered with war stories about how people have burnt their fingers using Zope for SQL development. The mechanism of loading objects from the filesystem is going to set anybody back. My 2 paise, Suresh ___ 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: Last chance to comment on Simplify skinning
On 2/15/06, Fred Drake <[EMAIL PROTECTED]> wrote: > On 2/15/06, Paul Winkler <[EMAIL PROTECTED]> wrote: > > Only that I have the same question Martijn does: > > Can I then override one of those resources and keep the other 34? > > Perhaps the resourceDirectory directive should just be sugar for a set > of resource directives, one for each file in the directory? That > would allow individual overrides, and maintain the convenience. I would prefer not. We've used resourceDirectory to support things like webcams. The image(s) uploaded by the cams might not always be there, but the containing path is. It's nice not having Zope start complaining on startup about making a resource for something that doesn't exist, and allows us to open up select file system points for resource uploads without having to know details about their contents. (We don't use this heavily, but it has been a nice advantage). If it was sugar for a set of resource directives, this could easily fail out on us, unless it was making 'resource' items all the time whenever the directory's contents changed. ___ 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: Last chance to comment on Simplify skinning
Jeff Shell wrote: > > I find Zope 3's approach much simpler and much easier to explain than > > the CMF's approach. In Zope 3 (especially with my proposed changes in > > place), a layer is simply a label (read: marker interface) on the > > request. When we now look up pages and resources (e.g. images), we take > > the request into account and therefore inevitably that label. We will > > only find pages and resources associated (read: registered) for this > > label. Good news is that any page or resource can be associated for this > > label, we just have to remember to do that in their ZCML directive. > > When you say "with my proposed changes in place", I don't understand > how that differs from what currently exists, or what can exist. We at > Bottlerocket started serious Zope 3 work with Zope 3.1. We've been > defining skins and layers as Interfaces since that time. I didn't > understand it entirely at first, but when I was debugging some issues > that arose with a fix to multi-adapter lookup that came in Zope 3.2, I > understood it more, and now it makes a lot of sense to me. Cool! > So coming from that world, I'm not entirely sure I understand how your > proposal is really different, except for this: > > In your proposal, 'Skins' are just gone as a separate concept - yes? > What is now treated as a Layer can also be treated directly as a skin, > yes? Yes, you are right, that's basically the only change my proposal advocates (and some minor details around it). > Here's a situation from a recent application of mine. The comments and > doc strings are verbatim. Notice that I leave a number of breadcrumbs > behind about which is the skin and which is the layer:: > > # Layer > class KBase(IBrowserRequest): > """ The ``kbase.skin.KBase`` **Layer** """ > > # Skin > class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): > """ > The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. > > The Knowledge Base skin is very specialized and does not need as > many > generic features as the Content Management or default ZMI skins. The > primary dependance on the CMS layer is to get its resources > (javascript > libraries, icons). > """ > > I assign most things in my application to the KBase layer. The > KnowledgeBase Skin builds from three layers. Very early versions of > this app did a mix of layers and skins in the bases used for > ``KnowledgeBase``, but the skin it used brought in too many views that > I didn't want interfering with things accidentally, so I went with the > ``CMS`` layer instead so I'd get things from our CMS layer, but not > get *everything* that was chosen for the *Content Management* skin. > > Does that make sense? > > If I understand your proposal correctly, the Layer and Skin above > would both basically be the same thing, right? Not necessarily. You're free to create whichever layer hierarchy suits you best. At some point you can then say that a particular layer in that hierarchy (typically one that combines a lot of other layers) becomes known under a human-readable name. We then say it's a skin. My proposal gives you the freedom to promote any layer to a skin. That means you can also register views directly for a skin because it's just another layer. You won't have to create a layer and then a skin based on that layer... > The only thing that I don't understand right now is this concept of > Interface Types. I don't have our Zope 3 book in front of me right > now, so I'm not sure if it has anything helpful to say. But I'll just > say that Interface Types have been an elusive concept for me, so far. Interfaces mark objects. Like "This is a recipe" or "This is attribute-annotatable". Interface types mark interfaces. Like "This is not just some interface, it's an interface for content components" or "This is an interface we use as a skin". When you got my book in front of you, look up the beginning of Chapter 5. Interfaces extend z.i.Interface. Interface types extend z.i.i.IInterface (notice the double I) because they describe interfaces. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: Last chance to comment on Simplify skinning
On 2/15/06, Jeff Shell <[EMAIL PROTECTED]> wrote: > I would prefer not. We've used resourceDirectory to support things > like webcams. The image(s) uploaded by the cams might not always be > there, but the containing path is. It's nice not having Zope start Good point. > If it was sugar for a set of resource directives, this could easily > fail out on us, unless it was making 'resource' items all the time > whenever the directory's contents changed. Right. In which case, another possibility would be to have a new directive that really is just sugar as I described. That would avoid backward compatibility problems and make the intention clear. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Last chance to comment on Simplify skinning
On Feb 15, 2006, at 6:03 AM, Philipp von Weitershausen wrote: Hi there, a while back I wrote a proposal on simplifying the skinning system (http://dev.zope.org/Zope3/SimplifySkinning). I got a lot of useful feedback which in turn made me update the proposal. Since then I haven't heard much comments. I would like to start implementing it soon, especially since the time schedule has been moved up one month. Please speak up now if you got any remaining comments. Silence is assent :). I guess I'm +0 on your current proposal, and +1 on its goals. I like many parts of it. I didn't like the fact that the zcml ended up being longer. I didn't love that people had to start asking questions about interface types in order to register a skin. Interface types are a cost--another layer of abstraction, another potentially mind-blowing thing to explain. You are already suggesting changing the zcml, and I'd like to see a compromise between the brevity of the current zcml and the conceptual clarity of your proposed changes. I tried to brainstorm, but didn't love what I came up with. Maybe it can take us somewhere. What if we still deprecated browser:layer but kept a redefined version of browser:skin? Then your zcml-- could become name="ShanghaiSkin" /> The rest of your example would remain the same. It doesn't accomplish everything you set out to do, and that's a shame, but it feels like a compromise with a reasonable counter- argument: defining skins is a basic task often introduced early on with teaching Zope, and it's a shame to have to bloat the zcml and teach advanced topics too soon. I'd like to at least get the zcml out of this story. Gary ___ 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 3 web root
On 2/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Chris Withers wrote: > > I'd flip that, because I think you and Steve A would agree on one thing: > > The use of an object database _should_ be a choice, not a requirement, > > but it should also be the default ;-) > > Actually, I disagree--I don't want an object database to be the default. > An OODBMS is good complexity for some projects and bad complexity for > others. Let people first choose the thing they're familiar with (the > filesystem), then make it easy for them to branch out toward an RDBMS or > OODBMS. This is frustrating to see. At least, in the concept of 'Zope' as the full application server it is. Others have brought up the concept of 'Bobo', and I would much rather see that. There are situations where I don't want the ZODB. We have our own data management layer for very very very very complex RDBMS interactions. We have a Zope 2 gateway to this layer right now and then acquisition and other wonderful tricks allow templates/scripts to be picked up and applied to the resulting data. We want to move it to Zope 3 to take advantage of the concept of Views and, most importantly, have all of the templates on the file system. But we really don't need all (or most) of zope.app. Containers, Sized, Catalog, and so on and so on and so on, really don't apply. I know it's *possible* to not use all of that, but just *how* to do it, I don't know. A Zope that was basically zope.publisher, zope.component, zope.interface, zope.schema, and tal/tales (and maybe 'transaction') would be ideal. Your idea terrifies and confuses me. I think I just don't like this 'Newbie comes in and ...' talk. It's so generalizing. These days, I find myself being THWARTED at many turns by the magical special browser: ZCML directives that were to make life easier for newbies. Yeah, they helped me in the beginning. And now I'm pulling my hair out. Don't thwart me! I'm not saying that helping new people is a bad thing. But why push all of these new concepts on them AND seasoned developers like me? Personally, I think that the ZODB is a terrific asset that has achieved a greater level of usability in Zope 3. At least, it has for us, now that we're no longer confused about whether the ZODB should house our persistent objects, or if it should house our icons and scripts and code and the RDBMS should be the store. I wouldn't want to downplay this advantage. Anyways, I believe fervently that a totally pared down version of Zope that was just the basic stuff as mentioned above (zope.publisher, zope.component, etc) would be a good target. That's something I understand. What you describe, I don't understand. > Do you mean "_just_ an RDBMS if you so desire"? We don't want to force > people to use an ORM either. > > Flat files are everybody's land. Our flavor of flat files will be > engineered to ease the transition from flat files to a Python package. Huh? This is sounding like the "but everyone just likes and wants PHP" talk. Maybe it's my fault for never wanting, nor changing, a 'default page' after installing an instance home, and I'm not the target audience. We use the ZODB for data and storage and it's so wonderfully easy in Zope 3 to keep all of that in the ZODB while all of the templates and views are on the file system that I've never thought much about fssync. - I WOULD LOVE TO HAVE EXPORT/IMPORT THOUGH! - (or fssync, but really more for backups or data updates...) And I guess we have the other odd requirement that we often don't have just a single root, or a single view of any particular site root. For our internal CMS customers, the public never sees anything close to the content management screens. 'admin' is thought to be a separate experience, even by our customers. But it's really just a different skin on the exact same data. Not really a root at all. I guess it's my fault for no longer really thinking in terms of "serving up pages," but rather "serving up your flight itinerary" or "serving up a list of related articles and who wrote them." I guess this is all kindof rambling. I just don't see any benefit to me. I'd rather see any effort like this pick up the zope.bobo branch/product or whatever it is right now and deliver a clean and simple stripped down zope publisher that could run on WSGI and could be used to show up all of those "but i can make a wiki in twenty minutes" tutorials and have no dependence on storage of any kind. ___ 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: Last chance to comment on Simplify skinning
On 2/15/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > I find Zope 3's approach much simpler and much easier to explain than > the CMF's approach. In Zope 3 (especially with my proposed changes in > place), a layer is simply a label (read: marker interface) on the > request. When we now look up pages and resources (e.g. images), we take > the request into account and therefore inevitably that label. We will > only find pages and resources associated (read: registered) for this > label. Good news is that any page or resource can be associated for this > label, we just have to remember to do that in their ZCML directive. When you say "with my proposed changes in place", I don't understand how that differs from what currently exists, or what can exist. We at Bottlerocket started serious Zope 3 work with Zope 3.1. We've been defining skins and layers as Interfaces since that time. I didn't understand it entirely at first, but when I was debugging some issues that arose with a fix to multi-adapter lookup that came in Zope 3.2, I understood it more, and now it makes a lot of sense to me. So coming from that world, I'm not entirely sure I understand how your proposal is really different, except for this: In your proposal, 'Skins' are just gone as a separate concept - yes? What is now treated as a Layer can also be treated directly as a skin, yes? Here's a situation from a recent application of mine. The comments and doc strings are verbatim. Notice that I leave a number of breadcrumbs behind about which is the skin and which is the layer:: # Layer class KBase(IBrowserRequest): """ The ``kbase.skin.KBase`` **Layer** """ # Skin class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): """ The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. The Knowledge Base skin is very specialized and does not need as many generic features as the Content Management or default ZMI skins. The primary dependance on the CMS layer is to get its resources (javascript libraries, icons). """ I assign most things in my application to the KBase layer. The KnowledgeBase Skin builds from three layers. Very early versions of this app did a mix of layers and skins in the bases used for ``KnowledgeBase``, but the skin it used brought in too many views that I didn't want interfering with things accidentally, so I went with the ``CMS`` layer instead so I'd get things from our CMS layer, but not get *everything* that was chosen for the *Content Management* skin. Does that make sense? If I understand your proposal correctly, the Layer and Skin above would both basically be the same thing, right? The only thing that I guess really differentiates them right now (in my application) is how they're registered in ZCML. But they're each the same basic collection of interfaces. ``KBase`` is shallow and dedicated to the browser view/resource components in my application, ``KnowledgeBase`` is rich and pulls in components from others. The only thing that I don't understand right now is this concept of Interface Types. I don't have our Zope 3 book in front of me right now, so I'm not sure if it has anything helpful to say. But I'll just say that Interface Types have been an elusive concept for me, so far. -- Jeff Shell ___ 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: One namespace for ZCML
[Sidnei da Silva] ... >> Now whether that's that's the correct interpretation is up to the >> original author (Tim Peters?) to clarify :) [Fred Drake] > I don't know if he's paying attention to this thread, but I'm fairly > certain everyone at PythonLabs understood that to refer to namespaces. > If Tim would like to counter that, he's certainly free to do so, of > course. :-) I was, of course, merely acting as a channel for Guido. It wasn't my job to understand or interpret, it was merely to put into words Guido's essentially ineffable wisdom. I'm not sure even God (let alone Guido) knows what that stuff _means_, and there's been healthy debate over interpretations ever since. FWIW, I always thought "the namespace one" was talking about namespaces, or _perhaps_ wooden shoes. I'm certain it wasn't talking about tulips, although certainty over interpretations has admittedly been the cause of much human misery throughout history. So if someone _does_ think it's about tulips, best to smile and nod, then killfile the moron :-) ___ 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: Zope 3 web root
> Max M wrote: > > The problem is that all the people used to LAMP will come to Zope and > > think "Well I will need to think differently here. Thats a bother. I > > will use sql for everything like usual." And so we will get a lot of > > duplicated efforts and half-baked Zope developers, who will desperately > > try to use Zope for SQL development. > > Because of this concern, I'm putting this off for a while. I think it > addresses a major hole in Zope, but it also creates two ways to > accomplish similar tasks without a clear division between the two ways. > Note that the Python language, despite its philosophy, has at least > two ways to accomplish things: with functions or with classes. In this > case, two ways are definitely better than one, IMHO. > > But before Zope acquires a new way to create web sites, we need to > better understand whether that's a burden Zope ought to bear. It could > turn out that people who don't want ZODB really shouldn't use Zope at > all. I would find that conclusion disheartening, but maybe it's > realistic. > > Shane I think that the discussion about whether one could or should completely replace ZODB with SQL is less important than providing good connections to SQL while other things are done with ZODB. (After all -- python provides functions and classes, but it never says: either develop only with one or the other!) In my application it is perfectly clear (for the moment at least:)) what things are part of the UI/application interface (ZODB) and what things are data that needs ACID transactions, write-ahead logging and ODBC (Postgres). In general, many people who use relational databases do so for a good reason. I once worked on a project where we had to rip out ObjectStore after much frustration delay and expense for scalability reasons. What I'm having to write myself in this project, would have liked to have had, and perhaps wouldn't mind contributing to ZPL versions, are containers that allow one to open a window on the SQL world rather seamlessly. As it turns out, I've already done my object marshalling because our system has a Twisted/spread interface as well, so I didn't need SQL specific object marshalling (though a way of mapping annotations to DB would have been nice, as I hadn't included that in DB design). Rather, I just need containers that know that their contents live "out there somewhere" in a transaction based system that is itself responsible for object keys. - Shaun ___ 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: Zope 3 web root
Max M wrote: The problem is that all the people used to LAMP will come to Zope and think "Well I will need to think differently here. Thats a bother. I will use sql for everything like usual." And so we will get a lot of duplicated efforts and half-baked Zope developers, who will desperately try to use Zope for SQL development. Because of this concern, I'm putting this off for a while. I think it addresses a major hole in Zope, but it also creates two ways to accomplish similar tasks without a clear division between the two ways. Note that the Python language, despite its philosophy, has at least two ways to accomplish things: with functions or with classes. In this case, two ways are definitely better than one, IMHO. But before Zope acquires a new way to create web sites, we need to better understand whether that's a burden Zope ought to bear. It could turn out that people who don't want ZODB really shouldn't use Zope at all. I would find that conclusion disheartening, but maybe it's realistic. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Swiss Easter Sprint - Announcement
Swiss Easter Sprint "Sorry for cross posting, I just will make sure that nobody feels like not invited and has a chance to participate." When The sprint starts on Saturday, April 8, at 9:00am and will end on Wednesday, April 12 in the afternoon. The official welcome activity will be at noon on April 8. Where The workshop will be located in Cham. Cham is a Town near Zug, Switzerland. Yeah, Zug is a town and doesn't mean Zope User Group! http://www.cham.ch/de/portrait/sehenswuerdigkeiten What Zope 3 Strategy Workshop The future of Zope 3 and its role for other frameworks With the recent interest of the wider community in Zope 3, it is important to define Zope 3 in light of this. Discussions could be held about what should be the Zope 3 core, how can other development shape the core and how Zope 3 can best support high-level frameworks, such as Cubed. In previous sprints we have also worked on a new face for Zope 3, a new Web site. This and other Zope 3 marketing material could be developed during the sprint, making the event also interesting for non-developers. It would be really great to have a Zope 3 "promotion" leam at the sprint. This is a great opportunity for Zope 3 core developers and framework builders to meet and have discussions. We will define more concrete topics to work on and discuss as we come closer to the sprint date. Zope 3 Core Development We have recently seen and will see a lot of reorganization of the core. However, a lot of the changes (with exception of Jim's adapter registry rewrite) are cosmetic, leaving some tougher technical challenges open. Since this sprint will be a true Zope 3 sprint, we could address some really hard-core issues, like menues, new widget package, formlib work, etc. The actual topics will depend on the participants, of course. Zope 3 Experimentation Recently, there have been several experimental packages under development, like the boston skin and the WebDev package while others have been proposed like Shane's Web root or indirection tool. While not directly usable in a release, this research work is necessary to give Zope 3 the cutting edge in the future. You can register yourself on the sprint page at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SwissEaster Sprint Or send me a mail if you don't have access for editing the Wiki-Page and add yourself to the participant list. Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Langackerstrasse 8 6330 Cham phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ 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: Last chance to comment on Simplify skinning
On 2/15/06, Paul Winkler <[EMAIL PROTECTED]> wrote: > Only that I have the same question Martijn does: > Can I then override one of those resources and keep the other 34? Perhaps the resourceDirectory directive should just be sugar for a set of resource directives, one for each file in the directory? That would allow individual overrides, and maintain the convenience. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ 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: One namespace for ZCML
Hi Philipp [...] > Subject: Re: [Zope3-dev] Re: One namespace for ZCML > > Roger Ineichen wrote: > > I'm interessted in a menu / menu item refactoring. > > > > This means, we could get rid of the implicit magicly > > registred menus in other directives which ends in > > unaccessible menu items and will offer a better > > accessible API. I will write a proposal later, but perhaps > > I have to prototype first since this part is very complex > > and used almost in every browser directive. > > Note that my other proposal, > ReducingTheAmountOfZCMLDirectives, mentions > something like this in the end (it's not really part of the actual > proposal anymore, just some random thoughts): > > """ > Many directives of the browser namespace support the registration of > menu items in addition to registering the component in > question. Though > this can be considered useful because it might save some > typing, keeping > directives as simple as possible (on/off switches!) might be weighed > higher. People are certainly intimidated by the length of some of the > browser directives (such as browser:editform); by taking the menu > functionality out, we could reduce many directives by two lines making > them easier to understand by themselves (of course, we'll have to add > another menu directive, but it'll only be 3 or so lines). > """ Yes, I agree, that's also a good base for a menu simplyfication. > If you got any further comments on this, I'd be happy to hear them. It > doesn't *have* to be a proposal, but it would sure be nice :). I think it's to complex it right now since I'm not sure at all if my idea will work. Let me try to give a short overview. - Merge the menu and menu item to one implementation - the above will also allow to implement nested menus. Right now the implicit menu, registred in views, don't have a id itself. This means they are unuseful for nested menu registrations. - move menu registration out of the view directives, (like described in your proposal) - Also refactor the IFactory concept. Use IFactory adapters on folders instead of IFactory utilities. The last part IFactory adapters instead of IFactory utilities depends on a application I wrote and was running in serious problems because of the slowdown which depends on IFactory utilies lookups. I'm not sure if somebody will agree on this, but I think if I can profile the IFactory utility implementation and show the slowdown, we have a better base for a proposal. This would also solve some namespace problems we have with the content type name registration. Note; nested menus are implemented since more then a half year. But they are not useable with the existing menu items which are registered inculded in the view directives. Because in the view directive registred menus are only "menu items" which are not nested. Regards Roger Ineichen > Philipp > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ 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: Zope 3 web root
On Feb 15, 2006, at 4:21 PM, Lennart Regebro wrote: On 2/15/06, Max M <[EMAIL PROTECTED]> wrote: Remember its the "Z Object Publishing Enviroment"? Hear, hear! +1 (Which, to be clear, does not mean we shouldn't encourage people making it easier to use SQL in Zope. But our strength and heritage is as an OPE.) Gary ___ 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: Zope 3 web root
On 2/15/06, Max M <[EMAIL PROTECTED]> wrote: > Remember its the "Z Object Publishing Enviroment"? Hear, hear! -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
Dario Lopez-Kästen wrote:
Sidnei da Silva said the following on 2006-02-14 12:15:
On Tue, Feb 14, 2006 at 08:17:04AM +0100, Dario Lopez-Kästen wrote:
| Shaun Cutts said the following on 2006-02-14 07:37:
| I have seriously considered trying out Django and similar tools to
see | if they would fit better with the kind of applications I need to
do, but | I really like the power that Zope as a platform offers, even
in Zope 2.
Then comes a question. Did anyone try reusing parts of Django inside
Zope 3?
I just would like it to be easier to work with Zope and {CMF or it's
successors} when data is not inside the ZODB.
The problem is that all the people used to LAMP will come to Zope and
think "Well I will need to think differently here. Thats a bother. I
will use sql for everything like usual." And so we will get a lot of
duplicated efforts and half-baked Zope developers, who will desperately
try to use Zope for SQL development.
Remember its the "Z Object Publishing Enviroment"?
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
Hello, I was thinking a lot about the proposed Zope3 web root, and the mentioned RDBMS first class citizenship. I'd like to backup an usecase and propose a somewhat different approach .. First of all, having the ZODB optional and mountable IMHO is a great thing, because it is not always needed, or even usable - imagine for example lots of accounting or statistical data, stored in millions of rows in a RDBMS, several years old, and presented using charts and grids. Moreover, I would and do design brand new Zope3 applications using SQL storage, not the ZODB, even when the storage is local to the filesystem (sqlite), just because I firmly believe, that the place for data is in the RDB, not in the ODB. Also because I couldn't find easy and effective enough way to get 20 objects out of 10 pieces in an ordered set, starting with number 27897 for example, but that's another story and may be entirely my fault as I didn't care to look very hard. But I know a lot of tasks, which the ZODB is much better suited for, especially if it did had that shiny little tool, capable of not only analyzing and displaying a stored object, but also changing it - it could spare me many minutes worth of restarting and waiting Zope to boot each day. It is on my todo list, you know, I just need some spare time. And the proposed indirection analyzer tool could spare some 2 months full of curiosity and curses as I slowly made my way trough let's say about 20% of that rapidly-changing-worst-documented-in-the-world big picture (not talking about Zope2, sorry guys, but although the more I learn, the more I love Zope3, it's not easy at all). Anyway, one of the strongest arguments against that web root in the filesystem is the Apache - why do we need Zope3 to serve files and directories out of the filesystem, and have those config files there, when we have a very sophisticated and solid tool, which does that more than fine and also a lot more, and more effectively than we can ever dream of with an interpreted language? You know, it wasn't the very next question that I asked myself, although it is so obvious, but eventually I got to it - well, why do we need Zope3 to parse HTTP requests while it generally and historically proved exists proxied behind this very tool, which is so much capable of parsing HTTP, and is also so flexible? Zope3 uses it's integrated twisted server to do everything about parsing protocols, but as I already said, we can't even dream of reaching the effectiveness of a heavy duty pure C/C++ HTTP machine which has decades of development and fine tuning behind, by using an interpreted language. And remembering the statement from it's own documentation, that Zope doesn't care much about what is in front, as long as it supplies the right object, then why not just mod_zope it ? And guess what .. There is that fundamental truth about Internet - it doesn't matter what idea just came to you, it is already there. Turns out that somebody is already doing it at http://codespeak.net/z3/modzope/ . So why not making it at least a bit more official and feature-complete? For example - capable of rendering page templates directly from the filesystem and mounting ZODBs .. Integrating with existing and proved solutions seems a lot more natural and trouble-proof, than doubling them and Apache has a lot that could be used in Zope. Regards, Velko Ivanov ___ 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: Re: tal:define="..." considered harmful?
Martijn Faassen wrote:
if it doesn't slow things down or add features that are not really
needed, I think it's fine, but maybe an explanation would be good as
to what it does?
It basically does the same thing as ctal does, except less (no
tal:repeat for instance, though I did have a simple tal:define), and it
isn't going anywhere. I dabbled with it a few years ago as I thought it
was an interesting idea and I just wanted to play a bit with javascript.
It had unit tests, and the regex stuff that I was referring to may be
interesting - it ports the regexes from Zope's TALES to Javascript so
that the parsing of tales expressions works the same.
This is the module that has the regex bits, ported directly, if I
recall correctly, from Zope's python code:
https://infrae.com/svn/sapling/trunk/zpt/talparser.js
OK I see, it's the variable substitution;
string:${name}/${address} ..
the question is what this is not better computed in the model. If it's
just for presentation it's fine (e.g. adding a colon between two fields),
but then one could (even should) write:
...: ...
but if the data is supposed to be a URL or something meaningful for the
entire application then there's a problem, because it's the template
that creates the data and the rest of the application has strictly no
access to it (at least in the MVC model where the view observes the
model and not the opposite).
[snip]
I really think that the best way to add features is to create a
sample applications and see what's missing in the language or what
feels unnatural or too complicated to achieve, but basically if a
missing feature forces you to move the logic to the data model, it is
definitely not a missing feature. I believe that ZPT is too much of a
scripting language.
Sure. I'm not sure whether the regexes are useful, just would be nice if
they didn't go to waste after all. :)
also I think that one namespace is enough (no "context/title",
"request/user"), but use "title" and "user" instead ... extra
namespaces in a template are a sign that the view has not done a good
job at preparing a data structure for the template to render it.
Hm. If I'm rendering a bunch of records to a HTML table, say, I'd
prefer my records to be in a list, and the records themselves give
access to further details.
More in general, it's possible that some template will receive two
sets of data that's quite separate from each other. I like namespaces
then too. You can of course always argue that such a template should
be factored into multiple smaller ones, though the question remains
how they'd each receive only their data and not the rest.
Regards,
Martijn
what I mean it that the structures can always be merged before they are
passed to the template, then the data can be organized as:
data = {
items: [ ...],
people: [],
somemoredata: {}
}
ZPT does a mapping between several data structures (context, request,
view ...) and the variables with the same name in TAL, which results in
several namespaces. Such variables are very platform-dependent and a
templating language basically needs only one data structure to do the
rendering..
regards /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: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 12:44:36PM -0500, Benji York wrote: > Paul Winkler wrote: > >I have to explicitly register every one of my skin's 35 resources? > > If the 35 resources (files) are in the same directory you can use the > resource directory ZCML directive. Or am I missing something? Only that I have the same question Martijn does: Can I then override one of those resources and keep the other 34? -- Paul Winkler 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: Last chance to comment on Simplify skinning
Paul Winkler wrote: I have to explicitly register every one of my skin's 35 resources? If the 35 resources (files) are in the same directory you can use the resource directory ZCML directive. Or am I missing something? -- Benji York Senior Software Engineer Zope Corporation ___ 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: Re: tal:define="..." considered harmful?
Jean-Marc Orliaguet wrote: Balazs Ree wrote: On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. if it doesn't slow things down or add features that are not really needed, I think it's fine, but maybe an explanation would be good as to what it does? It basically does the same thing as ctal does, except less (no tal:repeat for instance, though I did have a simple tal:define), and it isn't going anywhere. I dabbled with it a few years ago as I thought it was an interesting idea and I just wanted to play a bit with javascript. It had unit tests, and the regex stuff that I was referring to may be interesting - it ports the regexes from Zope's TALES to Javascript so that the parsing of tales expressions works the same. This is the module that has the regex bits, ported directly, if I recall correctly, from Zope's python code: https://infrae.com/svn/sapling/trunk/zpt/talparser.js [snip] I really think that the best way to add features is to create a sample applications and see what's missing in the language or what feels unnatural or too complicated to achieve, but basically if a missing feature forces you to move the logic to the data model, it is definitely not a missing feature. I believe that ZPT is too much of a scripting language. Sure. I'm not sure whether the regexes are useful, just would be nice if they didn't go to waste after all. :) also I think that one namespace is enough (no "context/title", "request/user"), but use "title" and "user" instead ... extra namespaces in a template are a sign that the view has not done a good job at preparing a data structure for the template to render it. Hm. If I'm rendering a bunch of records to a HTML table, say, I'd prefer my records to be in a list, and the records themselves give access to further details. More in general, it's possible that some template will receive two sets of data that's quite separate from each other. I like namespaces then too. You can of course always argue that such a template should be factored into multiple smaller ones, though the question remains how they'd each receive only their data and not the rest. 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: Re: tal:define="..." considered harmful?
Balazs Ree wrote: On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. Okay - I don't have a lot of time so I'd need to find first it to do work on this, but I'm quite excited that TAL in javascript is making a comeback, and it'd be nice if that old code of mine could serve a purpose in the future. :) 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. I agree but if we change the name we should do it right now. What name (prefix) would you suggest? Only thing, it needs to be different from "tal" (since it must allow mixing the two namespaces in the same page) and I personally would also be against "jtal". "ctal" was meant to stand for "client tal" but indeed it might not be the finest choice. Aah, now I understand where the 'c' comes from. What about 'btal', browser tal? 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: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 03:39:02PM +0100, Philipp von Weitershausen wrote: > > Maybe I mean something different. I just want a folder in which I can > > drop all the files I want to customize (I love to customize), without > > registering something. > > That's not how it works in Zope 3, at least not right now and not by > default. My proposal doesn't isn't addressing this. > > Shane has expressed an interesting idea that goes into the "I just drop > my stuff in here" direction, but I'm frankly missing some important > points in this idea yet. It might be interesting to develop it further, > though. For now, however, we have to explicitly register everything. I > consider that a good thing. I think it's an important use case, though. In CMF, annoying and limited as it was, installing a skin was a one-time job. Adding or removing resources in that skin was trivial. > I think you don't care for the wrong reasons. You want your CMF > experience duplicated. Perhaps you're not as bothered as I was with the > CMF's limitations, but it sured annoyed me as hell having to create a > new layer for every product I wrote for CMF. Yes, I didn't like that either. Neither do I like the current system. I have to explicitly register every one of my skin's 35 resources? This is a significant burden. I do that a lot more often than I create new products. I think what we're angling for is some way to register everything in a certain directory as resources with one directive. -- Paul Winkler 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: Re: tal:define="..." considered harmful?
Balazs Ree wrote: On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: A separate svn project would be nice. I'm sure z3lab is open; it's also welcome under the z3 base on codespeak. I will then check it in to one of those; seriously, I can't decide which location would be more proper as a home. The z3base seems more generic to me, however the other ajax stuff is already in z3lab. (except AZAX, which has the "kukit" part stored on codespeak.) I am facing the same decision at where to bring in the "jsonserver" (a.k.a. json-rpc) product which would be a complete zope2-zope3 product merge. sure, whatever Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. if it doesn't slow things down or add features that are not really needed, I think it's fine, but maybe an explanation would be good as to what it does? BTW one enhancement that I was thinking of was the ctal:attributes="..." stuff, I find the i18n:attributes="..." approach more intutive since it is possible to write code as if it was HTML first, insert the variables where they should be and then specify afterwards which attributes are to be replaced: ... instead of: ... (which removes an indirection) the ZPT tal:attributes=... syntax forces me to think to much but that's just a personal opinion I really think that the best way to add features is to create a sample applications and see what's missing in the language or what feels unnatural or too complicated to achieve, but basically if a missing feature forces you to move the logic to the data model, it is definitely not a missing feature. I believe that ZPT is too much of a scripting language. also I think that one namespace is enough (no "context/title", "request/user"), but use "title" and "user" instead ... extra namespaces in a template are a sign that the view has not done a good job at preparing a data structure for the template to render it. 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. I agree but if we change the name we should do it right now. What name (prefix) would you suggest? Only thing, it needs to be different from "tal" (since it must allow mixing the two namespaces in the same page) and I personally would also be against "jtal". "ctal" was meant to stand for "client tal" but indeed it might not be the finest choice. that's what I guessed too, do I win something ? :-) /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: tal:define="..." considered harmful?
Benji York wrote:
Martijn Faassen wrote:
Right, that was my motivation too - I googled around for
javascript-based templating languages but realized there wasn't
really anything. Of course XSLT can be used this way too, but TAL is
kinda neat too. Still, I couldn't think of much practical use for
this. Perhaps in this AJAXy world this has changed.
Personally I'm very excited about ctal (and like the name too).
Getting data objects from the server and feeding them to templates on
the client seems like a nice way to do AJAXy things.
yep, you can also use TAL (ZPT) to create CTAL templates; that's the
reason why I think the namespace is ctal:... and not tal:..., otherwise
it could as well have been called tal:... and the template be stored in
a string.
then there are different usage patterns,
personally I download the template from the server when the page is
getting initialized (using asynchronous Ajax.request) and I store the
source in a javascript variable in a widget class. To render the
template I apply the transformation whenever the data changes. It makes
it possible to refresh widgets, otherwise you'd have to refresh the page
or redo an Ajax.request.
here is the part of the code that does the rendering:
render: function(data) {
if (this.source) {
var node = document.createElement("div");
node.innerHTML = this.source;
ctal.process_ctal(node, data);
var old_html = this.widget.innerHTML;
var new_html = node.innerHTML;
if (new_html != old_html) {
this.widget.innerHTML = node.innerHTML;
}
}
}
the performance is quite fine actually, but since this is event-driven I
should first check that the data really has been changed before firing a
"modified" event, to avoid rendering the template for nothing.
I think 'ctal' is fine too. (client tal)
/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: Re: tal:define="..." considered harmful?
On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: > A separate svn project would be nice. I'm sure z3lab is open; it's also > welcome under the z3 base on codespeak. I will then check it in to one of those; seriously, I can't decide which location would be more proper as a home. The z3base seems more generic to me, however the other ajax stuff is already in z3lab. (except AZAX, which has the "kukit" part stored on codespeak.) I am facing the same decision at where to bring in the "jsonserver" (a.k.a. json-rpc) product which would be a complete zope2-zope3 product merge. > Are you interested in recovering some of there Zope TAL based regex stuff > from Sapling? I'd be happy to merge it in. ctal doesn't appear to have > this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. > 'ctal' is a somewhat confusing name by the way, you'd think it > was TAL implemented in C, another interesting project I've dabbled with on > and off in the past. I agree but if we change the name we should do it right now. What name (prefix) would you suggest? Only thing, it needs to be different from "tal" (since it must allow mixing the two namespaces in the same page) and I personally would also be against "jtal". "ctal" was meant to stand for "client tal" but indeed it might not be the finest choice. -- Balazs Ree ___ 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: tal:define="..." considered harmful?
Martijn Faassen wrote: Right, that was my motivation too - I googled around for javascript-based templating languages but realized there wasn't really anything. Of course XSLT can be used this way too, but TAL is kinda neat too. Still, I couldn't think of much practical use for this. Perhaps in this AJAXy world this has changed. Personally I'm very excited about ctal (and like the name too). Getting data objects from the server and feeding them to templates on the client seems like a nice way to do AJAXy things. -- Benji York Senior Software Engineer Zope Corporation ___ 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: [Zope-dev] Pluggins vs Application Definition
Chris Withers wrote: maybe time to merge zope-dev and zope3-dev? -1 They're still different enough that most traffic on one is not interesting to the majority of subscribers to the other. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Philipp von Weitershausen wrote: Martijn Faassen wrote: [snip] * a way to register an XSLT renderer. * registering XML importers and exporters. These two immediately triggered "adapter" in my mind :). XSLT renderer may be a view, that's how we use them now. I think it's a candidate for a fairly easy transition to Zope 3 style concepts, in fact. There are subtleties with XML importers that don't really map to adapters directly, at least not in a simple way - you want to register different importers for certain XML tags. [snip] It's important, though, that we do try to find a good match between the Zope 3 ways of doing things and the historical baggage. In Zope 3 we have developed a nice way of looking at things and fit them into very simple concepts. It should be preserved. Sure, but I want my silva namespace so I don't pollute the Zope 3 space. :) Same reason I'm happy with the five namespace. Btw, I find it a bit scary that you're trying to replace an install method with a lot of ZCML directives. I'm not sure I would welcome a procedure expressed through configuration. It seems like some of these problems are better tucked away using a deployment framework like GenericSetup. But then again, I'm not really familiar with Silva and that install.py thing. Silva's 'install.py' does a lot of stuff that really should be declaration, not procedure. Registering metadata sets for content types, registering views, etc, etc. Then extensions to Silva also do the same thing. GenericSetup would make sense for some of it, but I suspect fairly little, except of course that right now lots of Silva's configuration, often unnecessarily, ends up in the ZODB. [snip] I put in a smiley, but I'm serious about the underlying problem of exposing a lot of long dotted names into Python modules into ZCML. No worries, I got the tone of the message. However, to every satire there's a true core message, as you're pointing out yourself. I too am concerned, but I also think that because dotted names actually have a meaning, they might be handier in the end than cryptic short forms. And then there's also the point of intrinsic information of a component that we're currently putting into ZCML but are starting to put into Python. I has already reduced the amount of dotted names necessary. Yes, I saw that point of yours in another thread replying to me there, and I think that's a very good point. Anyway, in my attitude to ZCML I'm for piecemeal evolution right now - I don't think ruthless refactoring is really necessary, but we can get quite ruthless on certain directives or attributes of certain directives. I wonder whether we can do things to make this look simpler. If the dotted names were not hiding in attributes but in element content, we could come up with some kind of XML vocabulary for them, even. :) At least it would give you the possibility to define and use XML entities for them :). Seriously, though, I wouldn't be sure of my vote for a system like that. As said, dotted names have a meaningful background (Python import paths). Abbreviations most likely don't. I rather build something that makes sense than one that relies on too many naming conventions... Agreed; this needs to be thought through carefully. We don't want to replace dotted names with a lot of shorter stuff you need to memorize anyway, either. It needs to be somehow predictable, and perhaps dotted names are the best we can do, if we can at least get rid of some of them and move it into Python. It's just an interesting area to think about. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Some indeed have no apparent meaning and distinction; I think zcml:condition could be safely folded into Zope's namespace. When I see apidoc or wfmc I can identify what is involved, though - possibly they can still be eliminated but they definitely have meaning to me. In the documentlibrary, so far we've only used two namespaces, zope and browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and zcml. I think eliminating the 'zcml' namespace would get us down to 2 or less declarations for most .zcml files. I think the 'zcml' namespace should be separate from the 'zope' one because 'zcml' is meta-ish whereas 'zope' is about actual and factual directives. I would rather see 'meta' directives folded into 'zcml' (like I propose in the proposal). zope:include and friends are meta-ish too though. Moving those into a separate namespace would suddenly grow the amount of namespaces necessary. Perhaps folding the meta namespace (+ zcml) into zope is actually something we can explore. The meta namespace should be a fairly solid XML vocabulary after all. Note that I absolutely see the necessity for namespace declarations. For example, I would like to see ZPT require the declaration of TAL, METAL and I18N n
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
Tonico Strasser wrote: Philipp von Weitershausen wrote: [snip] See, now I even explained this to a "template programmer", though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. Is this a layer? You're right, I don't care :) I know this is on a side track from the simplify skinning discussion, but: I think it'd be nice to have something that allowed you to register at least resources in a directory that still keeps intact the overriding capabilities that you'd have if you were to register a single resource. The current directive to register a directory of resources makes it easy to register a whole bunch of them in one go, but, unless I'm mistaken, makes it hard to override just *one* later (in another skin or override), as in fact the directory it registered directly. 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: tal:define="..." considered harmful?
Balazs Ree wrote: On Mon, 13 Feb 2006 18:59:32 +0100 Martijn Faassen wrote: Jean-Marc Orliaguet wrote: I've being working on integrating Balazs Ree's CTAL interpreter recently (added tests, fixes, etc.). CTAL is the equivalent of TAL but for javascript. I just googled around for this, and couldn't find it, but I'm intrigued. Any link? I made it some time ago just as an experiment, I was interested in having the equivalent of TAL on the client side. The implementation is far from complete but it's actually usable. If you are interested, best to check it out from the link Jean-Marc gave in the other mail (and I indeed might put it up somewhere in svn on its own). A separate svn project would be nice. I'm sure z3lab is open; it's also welcome under the z3 base on codespeak. I think the main advantage is that if someone already knows TAL can generate html from a template and raw data on the client side (which is one of the tipical AJAX usage patterns) without the need to learn another method or write dom manipulation in javascript. Right, that was my motivation too - I googled around for javascript-based templating languages but realized there wasn't really anything. Of course XSLT can be used this way too, but TAL is kinda neat too. Still, I couldn't think of much practical use for this. Perhaps in this AJAXy world this has changed. Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. We had an CVS to SVN conversion earlier this week, so sapling's source code is now here: https://infrae.com/viewvc/sapling/trunk/ (check it out with: svn co https://infrae.com/svn/sapling/trunk sapling) It has tests and everything. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Stephan Richter wrote: >>I realize that and I think at least the concern was valid. As for the >>solution, I rather prefer the convenience (which reads for me as >>"automation" when it get rids of dead chicken direcives) to be in Python. > > But I think this is exactely the problem. Convenience is often geared towards > non-technical people, like designers and integrators. For them to touch or > write Python code is horrifying. I don't think designers will have to touch Python. I don't even think they will often touch ZCML. The designers I hired never had to... > One of the goals of ZCML was to address this audience and day: Look > add, edit or change this and that directive and you are good to go. > It was also one of the reasons XML was chosen. I think ZCML is addressing people who build packages, people who make applications out of these packages and people who deploy those applications. I think in all three cases we can assume enough experience with Zope and Python to expect them to enter, say, a dotted name. And, of course, these people typically overlap. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Martijn Faassen wrote: >> I would really like to hear what kind of directives you imagine for >> Silva here (and what you mean by "new ways to configure components"). > > > The following are candidates, though note I haven't thought this through > deeply for any of them: > > * a way to register a Silva content object. > > * a way to register a content object version. > > * a way to register a Silva metadata set. > > * registering directory views (could go into CMF, though Silva is not > using it directly now) ... > * registering a silva service into the Silva root > > * configuring which objects can be addable. > > * setting up zope 2 permission/role mapping in Silva root. > > * setting up the zope 2 catalog indexes. I guess most of these fall under the "registering something that isn't a utility or adapter" category which is fine. Though I wouldn't be surprised some of those registrations could be boiled down to simpler, Zope-3-style things like menu items or utilities. Oh wait, you mention that yourself :). > * a way to register an XSLT renderer. > > * registering XML importers and exporters. These two immediately triggered "adapter" in my mind :). > I think some, or even all, of these can probably turn *eventually* into > Zope 3-style approaches directly - probably services will become some > sort of local utilities, and directory views will become Zope 3 view, > XSLT another, and the importers/exporters will become some sort of > adapters, addables menus. > > The emphasis is on eventually, as I certainly expect it to be useful in > a transition phase to clean out Silva's current grotty install.py and > replace it with ZCML that doesn't require significant refactorings of > Silva yet. Replacing this stuff with native Zope 3 components is > generally a major task. I agree on the eventuality. It's important, though, that we do try to find a good match between the Zope 3 ways of doing things and the historical baggage. In Zope 3 we have developed a nice way of looking at things and fit them into very simple concepts. It should be preserved. Btw, I find it a bit scary that you're trying to replace an install method with a lot of ZCML directives. I'm not sure I would welcome a procedure expressed through configuration. It seems like some of these problems are better tucked away using a deployment framework like GenericSetup. But then again, I'm not really familiar with Silva and that install.py thing. >>> Sometimes a new, short directive is a lot easier to >>> remember than to remember long.dotted.names.pointing.to.places and 3 >>> directives. Having to remember (or worse, look up) long dotted names is >>> extremely common in ZCML and I consider it at least as big a problem as >>> having to learn directives. >> >> >> I agree. Many of these long dotted names belong into Python, though. >> >> >>> Let's use abstraction and naming things where it makes sense. >>> >>> Heh, perhaps we need to go the other way and add a namespace directive >>> for long dotted names instead. :) >> >> >> -1. > > > I put in a smiley, but I'm serious about the underlying problem of > exposing a lot of long dotted names into Python modules into ZCML. No worries, I got the tone of the message. However, to every satire there's a true core message, as you're pointing out yourself. I too am concerned, but I also think that because dotted names actually have a meaning, they might be handier in the end than cryptic short forms. And then there's also the point of intrinsic information of a component that we're currently putting into ZCML but are starting to put into Python. I has already reduced the amount of dotted names necessary. > I wonder whether we can do things to make this look simpler. If the > dotted names were not hiding in attributes but in element content, we > could come up with some kind of XML vocabulary for them, even. :) At least it would give you the possibility to define and use XML entities for them :). Seriously, though, I wouldn't be sure of my vote for a system like that. As said, dotted names have a meaningful background (Python import paths). Abbreviations most likely don't. I rather build something that makes sense than one that relies on too many naming conventions... That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). >>> >>> >>> Namespace declarations are not dead chickens. They're things that the >>> XML language requires. Indentation and colons are not dead chickens in >>> Python either. *particular* namespace declarations may be unnecessary - >>> but not dead chickens, just perhaps the wrong solution. >> >> >> Yeah, sorry, bad wording. I just think having to declare 3 to 5 different >> namespaces on the top of the file of which some have no appa
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Tonico Strasser wrote: >>> In CMF things are very easy to understand, because a layer is simply a >>> folder. I can explain that in five minutes to a template programmer. >> >> Why does the template programmer need to know about layers? > > Because in CMF, if you want to customize or create a skin, you need to > know about the so called "layers". But we aren't in the CMF :). Seriously, you are right about the fact that you need to know about layers when you want to work with skins. Let's just be clear on the actors' names: template programmer isn't necessarily the same as a skin customizer. A template author just writes a page template and isn't necessarily concerned how and where it is going to be registered. Most of the time, it is fine to register browser pages (incl. template-based ones) for the default layer. That is a huge difference to the CMF where everything lives in a very specific layer (which I find annoying and complicated) and that layer has to be registered in a skin (which most CMF product's Install.py will automatically do...). Now, the skin customizer might write some templates to actually perform some customization first, but his job description really is about setting up the layer(s) and registering one of them as a skin. For that you need to know about layers, yes. But not when you only want to author a template. >>> Maybe this sounds a bit NAIVE, but would it be possible to make it like >>> in CMF? >> >> The CMF approach is very limiting. The fact that a layer equals a >> physical location (a folder) led to every CMF-based product coming up >> with its own layer -- because there is no way to put stuff into existing >> layers, not even the default layer. Layers as they are in Zope 3 have >> stopped this senseless layer proliferation. >> >> I find Zope 3's approach much simpler and much easier to explain than >> the CMF's approach. In Zope 3 (especially with my proposed changes in >> place), a layer is simply a label (read: marker interface) on the >> request. When we now look up pages and resources (e.g. images), we take >> the request into account and therefore inevitably that label. We will >> only find pages and resources associated (read: registered) for this >> label. Good news is that any page or resource can be associated for this >> label, we just have to remember to do that in their ZCML directive. >> >> See, now I even explained this to a "template programmer", though I >> don't think he'd care. > > > Maybe I mean something different. I just want a folder in which I can > drop all the files I want to customize (I love to customize), without > registering something. That's not how it works in Zope 3, at least not right now and not by default. My proposal doesn't isn't addressing this. Shane has expressed an interesting idea that goes into the "I just drop my stuff in here" direction, but I'm frankly missing some important points in this idea yet. It might be interesting to develop it further, though. For now, however, we have to explicitly register everything. I consider that a good thing. > Is this a layer? A layer is a marker interface on the request (Zope 3 definition). > You're right, I don't care :) I think you don't care for the wrong reasons. You want your CMF experience duplicated. Perhaps you're not as bothered as I was with the CMF's limitations, but it sured annoyed me as hell having to create a new layer for every product I wrote for CMF. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Philipp von Weitershausen wrote: In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? Because in CMF, if you want to customize or create a skin, you need to know about the so called "layers". Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a "template programmer", though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. Is this a layer? You're right, I don't care :) 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] One namespace for ZCML
Philipp von Weitershausen wrote: Martijn Faassen wrote: [snip] Moreover, sometimes a package introduces new ways to configure components. Five does so, for instance, and Silva will too eventually. I would really like to hear what kind of directives you imagine for Silva here (and what you mean by "new ways to configure components"). The following are candidates, though note I haven't thought this through deeply for any of them: * a way to register a Silva content object. * a way to register a content object version. * a way to register a Silva metadata set. * registering directory views (could go into CMF, though Silva is not using it directly now) * a way to register an XSLT renderer. * registering XML importers and exporters. * registering a silva service into the Silva root * configuring which objects can be addable. * setting up zope 2 permission/role mapping in Silva root. * setting up the zope 2 catalog indexes. I think some, or even all, of these can probably turn *eventually* into Zope 3-style approaches directly - probably services will become some sort of local utilities, and directory views will become Zope 3 view, XSLT another, and the importers/exporters will become some sort of adapters, addables menus. The emphasis is on eventually, as I certainly expect it to be useful in a transition phase to clean out Silva's current grotty install.py and replace it with ZCML that doesn't require significant refactorings of Silva yet. Replacing this stuff with native Zope 3 components is generally a major task. I expect a very similar story applies to CMF, and again to CMF-based systems like Plone. Sometimes a new, short directive is a lot easier to remember than to remember long.dotted.names.pointing.to.places and 3 directives. Having to remember (or worse, look up) long dotted names is extremely common in ZCML and I consider it at least as big a problem as having to learn directives. I agree. Many of these long dotted names belong into Python, though. Let's use abstraction and naming things where it makes sense. Heh, perhaps we need to go the other way and add a namespace directive for long dotted names instead. :) -1. I put in a smiley, but I'm serious about the underlying problem of exposing a lot of long dotted names into Python modules into ZCML. I wonder whether we can do things to make this look simpler. If the dotted names were not hiding in attributes but in element content, we could come up with some kind of XML vocabulary for them, even. :) That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). Namespace declarations are not dead chickens. They're things that the XML language requires. Indentation and colons are not dead chickens in Python either. *particular* namespace declarations may be unnecessary - but not dead chickens, just perhaps the wrong solution. Yeah, sorry, bad wording. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Some indeed have no apparent meaning and distinction; I think zcml:condition could be safely folded into Zope's namespace. When I see apidoc or wfmc I can identify what is involved, though - possibly they can still be eliminated but they definitely have meaning to me. In the documentlibrary, so far we've only used two namespaces, zope and browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and zcml. I think eliminating the 'zcml' namespace would get us down to 2 or less declarations for most .zcml files. Note that I absolutely see the necessity for namespace declarations. For example, I would like to see ZPT require the declaration of TAL, METAL and I18N namespaces. Note that there the entire namespace story is different. There they are used for what I think namespaces are intended, separating several XML models (e.g. the HTML model from the additional TAL/METAL/I18N model). I think Zope 3 extensions extend the Zope 3 XML model. They're less different than combining XHTML with TAL, but I still see a core vocabulary with potentially arbitrary extensions. 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] RFC: Reducing the amount of ZCML directives
On 2/15/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Among other things, yes. The idea isn't mine though, it was Jim's and is > already in-place as of Zope 3.2/2.9. Oh, I missed that, I thought it was planned for 3.3. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
On Wednesday 15 February 2006 07:59, Philipp von Weitershausen wrote: > I realize that and I think at least the concern was valid. As for the > solution, I rather prefer the convenience (which reads for me as > "automation" when it get rids of dead chicken direcives) to be in Python. But I think this is exactely the problem. Convenience is often geared towards non-technical people, like designers and integrators. For them to touch or write Python code is horrifying. One of the goals of ZCML was to address this audience and day: Look add, edit or change this and that directive and you are good to go. It was also one of the reasons XML was chosen. 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
[Zope3-dev] Re: One namespace for ZCML
Tres Seaver wrote: >>>- Many of the objected-to directives exist precisely because people >>>did not want to type the much more verbose equivalents which were >>>the original, "cleaner" spellings. >> >>Or perhaps people just thought that people wouldn't want to type in some >>extra stuff. Because I think they do if it helps them remember and >>understand better. The origin of the "dead chicken" meme, was Guido (and others) who objected to the mistake-prone typing required by the earliest set of directievs we had; Guido called them "dead chickens". >>> >>>If you see any dead chicken around the corner in my Reducing the amount >>>fo ZCML directives proposal, please let me know in detail. > > I'm just trying to point out that we added "convenience" directives in > order to address earlier usability complaints about the (theoretically > cleaner) original directive set. I realize that and I think at least the concern was valid. As for the solution, I rather prefer the convenience (which reads for me as "automation" when it get rids of dead chicken direcives) to be in Python. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reducing the amount of ZCML directives
Lennart Regebro wrote: > I think I agree. This to me makes sense. If it were nameless (are > there nameless utilities) you could then get off with just component=".alias.sydneyFactory" /> which is then the on/off switch we > mentioned earlier. And an adapter should be registered the same way > and what it adapts > between should be a part of the python-code with an adapts(ISomething) > declaration, just like implements(ISomethingelse), which I think you > suggested in your "ZCML does doo much" blog, right? Among other things, yes. The idea isn't mine though, it was Jim's and is already in-place as of Zope 3.2/2.9. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Jeff Shell wrote: > I still HATE magical ZCML. But I still think ZCML is a good thing and > should be modularized. Simplified - yes. Modular (namespaces) - yes. That seems to be the core message of most of the feedback I got. I'll be happy to hear more detailed suggestions on what should be simplified and/or modularized. Of course, I also have a few of my own, some of them are already listed at the bottom of the other proposal... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Dear Tonico, thanks for your input. > In CMF things are very easy to understand, because a layer is simply a > folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? > Maybe this sounds a bit NAIVE, but would it be possible to make it like > in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a "template programmer", though I don't think he'd care. > Use case: Integrate an existing application into my Web site, e.g. a forum. > > 1. Create a folder for the customized forum skin > > $ mkdir forum-skin > > 2. Register this folder > > path="forum-skin" > ... > /> > > 3. Customize everything from original forum skin > > $ cd forum-skin > $ cp $ORIGINAL_FORUM_SKIN/*.pt . > $ vi * > > This is oversimplified, I know :) Yes. It's also limiting. > Another note: when I see this I feel a cold shudder: > > name="zope3logo.gif" > file="shanghailogo.gif" > type=".interfaces.ShanghaiSkin" > /> > > Quite a lot of typing for one GIF!? Registering resources explicitly gives us the ability to easily override resources. That'll allow us to change logos, icons, etc. with just one ZCML directive. In fact, the ability to override is *the* foremost use case for registering stuff explicitly at all. If you want to save typing, you can have resource directories where you dump anything you want to be available as a resource. Philipp ___ 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: One namespace for ZCML
Roger Ineichen wrote: > I'm interessted in a menu / menu item refactoring. > > This means, we could get rid of the implicit magicly > registred menus in other directives which ends in > unaccessible menu items and will offer a better > accessible API. I will write a proposal later, but perhaps > I have to prototype first since this part is very complex > and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): """ Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). """ If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Philipp von Weitershausen wrote: Hi there, a while back I wrote a proposal on simplifying the skinning system (http://dev.zope.org/Zope3/SimplifySkinning). I got a lot of useful feedback which in turn made me update the proposal. Since then I haven't heard much comments. I would like to start implementing it soon, especially since the time schedule has been moved up one month. Please speak up now if you got any remaining comments. Hi Philipp, I really appreciate your efforts in simplifying skinning. FWIW: In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? Use case: Integrate an existing application into my Web site, e.g. a forum. 1. Create a folder for the customized forum skin $ mkdir forum-skin 2. Register this folder 3. Customize everything from original forum skin $ cd forum-skin $ cp $ORIGINAL_FORUM_SKIN/*.pt . $ vi * This is oversimplified, I know :) Another note: when I see this I feel a cold shudder: Quite a lot of typing for one GIF!? Just my two cents. 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: [Zope-dev] Pluggins vs Application Definition
On Wednesday 15 February 2006 07:20, Philipp von Weitershausen wrote: > Chris Withers wrote: > > [aside... hmmm, crossposting, maybe time to merge zope-dev and > > zope3-dev? most stuff seems to be relevent to both nowadays] > > +10 Okay, I hope this would be ignored, but -1. I can still ignore many E-mails on Zope-Dev. 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
[Zope3-dev] Re: [Zope-dev] Pluggins vs Application Definition
Chris Withers wrote: > [aside... hmmm, crossposting, maybe time to merge zope-dev and > zope3-dev? most stuff seems to be relevent to both nowadays] +10 You know, I once had a proposal. Uh, never mind :) >> In Zope 3, we went with a more explicit installation mechanism, >> in which people had to explicitly cause a package's ZCML files to be >> loaded for it to be used. We added a mechanism to make this easier, >> by simply dropping a file into a special directory, package-includes, >> so an installer wouldn't have to fool with pointy brackets. > > > Personally, I hate package-includes. It creates a load of mess in a > folder that is likely to need to have new tools written to look after it > in the future :-/ > > I'd really like to just see lines getting includes in site.zcml. We had that once. We got rid of it because it made deployment harder. With slugs you can just drop in an extra file without having to change one. That makes automated installation easy. > There is precedent for this, very good precedent in fact. > Think of httpd.conf, and the module include lines at the top. > I'm all for supporting having squillions of files all over the place, > but I'd really like to see the default be one file, as with Apache. Heh, that's actually a funny example because Debian has actually been using modular config files for quite some time now (not only for Apache). Especially module includes, module configurations and virtual sites all rest in individual config files. Small tools (a2enmod, a2ensite) help manage the files, though manual management isn't too hard either. So, seems like not only are we the first ones to come up with a setup like that, it's also used by a large > Also, I wish there was some way to have a .zcml that is in the > _software_ home, not the package home, that inlcuded all the "standard" > bits so that when I upgrade my zope version, I don't have to worry about > juggling all those files and wondering which ones are out of date and > which ones have "new" versions... You should "know" which ones you want in your instance anyways. I rather have a very, very slim "standard" set of packages and make everything else optional than provide everything else by default. If the software home ZCML file (which essentially is zope.app/configure.zcml) includes too much, it's a pain to disable things you don't like. It's trivial with package-includes. >> If application users are not technically >> sophisticated, or, more importantly, not technically interested, >> they peobably would prefer to just drop something into a special >> directory and be done with it. > > Yup, /products, /plugins, etc, everything from Photoshop to Zope 2 has > this concept ;-) It's been giving us a lot of pain in Zope 2. I don't think anyone seriously wants to go back. We *can* have a standardized location (by convention), e.g. $INSTANCE_HOME/lib/python, but let's not make it a mandatory one. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Last chance to comment on Simplify skinning
Hi there, a while back I wrote a proposal on simplifying the skinning system (http://dev.zope.org/Zope3/SimplifySkinning). I got a lot of useful feedback which in turn made me update the proposal. Since then I haven't heard much comments. I would like to start implementing it soon, especially since the time schedule has been moved up one month. Please speak up now if you got any remaining comments. Silence is assent :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] My proposals on simplifying ZCML
Dear all, thanks to everyone who commented my two proposals on simplifying ZCML. Here are some updates: Reducing the amount of ZCML directives -- I've updated this proposal slightly. It now mentions the important characteristics of ZCML directives and lists an additional risk pointed out by Martijn. It also proposes to simplify the content/class directive, something which I had forgotten to mention before. Still look for comments at http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives ... One namespace for ZCML -- There have a lot of negative comments on this (even though my initial idea got several +1 on this list). I think the discussion was still helpful. It definitely proved my point that we don't really have good guidelines for managing ZCML namespaces. A lot of people also agreed with me that we have too many namespaces. My proposal of removing all namespaces was a bit too drastic, I guess. I will create a new proposal that will "only" focus on: * coming up with guidelines for creating and managing ZCML namespaces * consolidating some unnecessary namespaces that we have today into one * making ZCML a better citizen with other XML dialects I'll welcome any suggestions if some of you have any... Stay tuned :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pluggins vs Application Definition
Stephan Richter wrote: This is interesting. I agree with Philipp though that a simple install tool would be better than one magic location. Indeed, but don't eggs already provide tools for this? I think the ZCML slugs are very cool I think they suck, sorry... it's one of the first things I hit with Zope 3 over Christmas :-( and if we have a tool (as "make" does now) Please god, not make... that does this one step, then we effectively have drop-in packages. No, drop in packages means you either use a package-manner like interface, like aptitude, a binary installer, or actually dropping a single file into a directory. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Pluggins vs Application Definition
[aside... hmmm, crossposting, maybe time to merge zope-dev and zope3-dev? most stuff seems to be relevent to both nowadays] Jim Fulton wrote: In Zope 3, we went with a more explicit installation mechanism, in which people had to explicitly cause a package's ZCML files to be loaded for it to be used. We added a mechanism to make this easier, by simply dropping a file into a special directory, package-includes, so an installer wouldn't have to fool with pointy brackets. Personally, I hate package-includes. It creates a load of mess in a folder that is likely to need to have new tools written to look after it in the future :-/ I'd really like to just see lines getting includes in site.zcml. There is precedent for this, very good precedent in fact. Think of httpd.conf, and the module include lines at the top. I'm all for supporting having squillions of files all over the place, but I'd really like to see the default be one file, as with Apache. Also, I wish there was some way to have a .zcml that is in the _software_ home, not the package home, that inlcuded all the "standard" bits so that when I upgrade my zope version, I don't have to worry about juggling all those files and wondering which ones are out of date and which ones have "new" versions... - If the application is extensible, then application users will want to be able to extend the application by adding "pluggins". This also applies particularly to framework applications like CMF... If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. Yup, /products, /plugins, etc, everything from Photoshop to Zope 2 has this concept ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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: One namespace for ZCML
Hi Philipp, hi Florent [...] > I'm all for reducing the number of namespaces in the standard > directives, > and reducing the number of directives too, but getting rid of > namespaces, as > others have pointed out, removes clean ways of extending ZCML for > third-party frameworks. [...] > Maybe a simple zope 3 component doesn't need to provide > extensions to ZCML > using a namespace, but any *framwework* on top of it will > quickly need them. Yes, that's exactly what we do in our libraries. I'm Ok with simplyfie the zope 3 namespaces and use only one namespace like , but not with removing the option to add custom namespaces. btw; I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Regards Roger Ineichen > > > Finally > > > -- > Florent Guillaume, Nuxeo (Paris, France) Director of R&D > +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
On Tue, 14 Feb 2006 13:48:42 -, Florent Guillaume <[EMAIL PROTECTED]> wrote: For example CPS currently has a cps:upgradeStep directive: Interesting... we've been talking about doing something similar in Plone. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Future of zope.app
On Tue, 14 Feb 2006 14:08:07 -, Stephan Richter <[EMAIL PROTECTED]> wrote: On Tuesday 14 February 2006 08:41, Philipp von Weitershausen wrote: Jim said that he wants zope.app to become smaller. I would welcome that. Is it time for this to be thought about? For various reasons, mostly personal ones, I would consider Zope 3.3/2.10 a good point for this to be done. If others agree, we should get started, especially since we moved up the time frame 1 month. I would not mind. I think most of the work will be investigating and documenting the steps to be taken. Technically it is less of a challenge. On the other hand, this release will see a lot of shake-up: ZCML directive removal, adapter registry reimplementation, package location changes. I'd prefer one larger shake than many largeish shakes in consequtive versions :-) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
