Re: [Zope3-Users] Re: z3ext
Martin Aspeli skrev: Hi Nikolay, I'm not entirely sure it's in everyone's interest to have something that looks so very much like Plone's out of the box look and feel that is not based on Plone at all (as I understand it) - least of all z3ext's, since it may get confused with Plone. I think there are two sides to this argument. It is confusing that it looks so much like Plone. But on the other hand. If it ever came to be that two systems could run in parallel from the same zodb, then it would be necessary to make it look like Plone anyway for a seamless user experience. At least they should share html class and id structure to make that easy. But something like z3ext would not have to use the same css definition out of the box. I actually think it would be stronger if it did not. Something more web2'ish would make it stand out more. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science Phone: +45 66 11 84 94 Mobile: +45 29 93 42 96 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Hivurt new open source CMS 0.1.3pre-alfa released
Mikhail Kashkin skrev: Hi everybody, Hi Mikhail, Key Solutions (http://keysolutions.ru/) and Hivurt team (http:// hivurt.org/) proud to announce first public release of our Zope3- based content management system. Requirements (You need to have before installing Hivurt) * Zope 3.3.x (3.4.x untested) * PostgreSQL 8.2 * Python 2.4.4 with psycopg2 and json libs * Tested on Mac OS X and Linux (Ubunty and ALTLiniux) This looks really interresting. Especially as you are already using it on customer projects. I just wonder about the Postgres dependency. Why did you choose to have that? I think that one of the beauties of Zope is that you don't need to install an rdbms. I agree that being able to seamlessly use an rdbms is a good feature, but I do belive that it should be optional. I have several development machines for different purposes, and having to install Postgres on them is a bit of a bother, as I don't intend to use relational storage before I absolutely have to. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Grok or raw Zope?
Michael Ang skrev: Use Plone, best for Intranet. Certainly not. Plone is a pain in the but for intranets. At least for some kinds. I have made quite a few of them, and plone works against you a lot of the time. Plone has a content based interface, and an intranet needs a task based interface. For intranets you often need to do the same littel thing over and over again. So the interface needs to be fast and simple. Eample: If you want to make eg. a time registration module, you need a quick way to enter time registration entries. So you really have to create a special interface for it. Adding a time registration content type to a special folder is really impractical. Content based model 1. go to intranet 2. find time registration folder 3. add time registration -- 4. set start time 5. set end time 6. add a comment 7. select project -- 8. save time registration task based model 1. go to intranet -- 2. add comment 3. Enter time used 4. select project -- 5. save time registration The last model will make time registration a lot more pleasent for end users. If you chose to go that way, you are fighting the way Plone is thought out, and are probably better of with a z3 solution. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Ahh, counters... Best practice?
Benji York skrev: Jeff Shell wrote: We're working on something where we need to allow site visitors to rate items. It's the basic star-rating thing. We want to keep a count of the number of votes along with the current value. At work we've been contemplating an approach for use in some similar situations we want to address. In broad strokes: keep the updated value in memory, write the value to the database periodically (for whatever value of periodically is appropriate for the data). This should work well when the value changes often and loosing the most recent updates to the value isn't catastrophic. I have used this approach in mxmcounter for zope 2. It keeps a dict in memory, by making it a module attribute. Every n count it then writes the dict to disk. It has worked on my site for years with no problems. Only a single problem has been reported by another user. Apparently a zope site crashed while writing the dict, and so left it unreadable. After restoring the dict on file from backup the site ran fine again. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science Phone: +45 46 93 23 92 Mobile: +45 29 93 42 96 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Blog naming proposals
Florian Lindner skrev: Hello, some people might have noticed I am developing a Blog package for Zope3. Since it slowly becomes functional (an older version is working at http://xgm.de) I want to release it (under an free and open source licence). One thing still missing is a good name. A name that quickly comes to my mind is zBlog but which is not very fancy. What ideas have you for Zope3 blog package, what would you choose? Don't be afraid to make it obvious. Ie make sure to have the word blog in it somewhere. Instead of just calling it eg. Lorum, Lorum Blog is so much easier to understand and remember. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science Phone: +45 46 93 23 92 Mobile: +45 29 93 42 96 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Losely or rather, less loosely coupled objects.
When doing sites in Zope 2 I often have the need to couple/contain two
or more fixed objects.
When an object needs to have some specific properites and logic, many
developers choose to subclass an existing object and change that.
Eg. a member folder needs to *allways* have a 'contact_info' object. Eg.
to keep company policy and to ease skinning.
That would typically lead to a new folderish content type with contact
info properties. Which I think is a really bad pattern.
Normally in Zope 2 I just give it a fixed id, and then set the
folder._reserved_names = ('contact_info',) property on the parent folder.
This is like folder.contacts_info = ContactInfo()
But this is a pretty obscure and unknown feature. And site managers
cannot use it.
I have the suspicion that many cases where people are doing Archetype
subclasses in Plone they should really use something like that approach
instead. It would lead to much simpler maintenance in the long run, with
a looser coupling of objects and less repetition of functionality.
Are there any good patterns for this in Zope 3? It would be really nice
to have a standard way of doing it.
It would also be nice if those objects did not show up in the navigation
like folder contents. It confuses the users that they cannot delete it.
But rather outside the normal navigation. Like in a portlet or as a
list of actions.
In Plone that is possible by adding a dot to the id like
'.contact_info', but that is a hack. Also there is no reason to have
those ugly urls.
Any pointers, or am I the only one thinking along those lines?
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
Phone: +45 66 11 84 94
Mobile: +45 29 93 42 96
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
Jeff Shell wrote: Yes it does. And I hate it. At Bottlerocket, we're a very small company. We look at Plone and go alright, how do we make it do less? how do we turn this thing off, and this thing off, and this thing off, and this thing off? why is it so slow? and it still doesn't do the page we need to do. Let's just write our own CMS. * Apparently many people disagree with you. Google hits: **27,700,000* for **Plone ***23,600,000* for **Zope** *14,800,000* for **Zope -Plone** For small companies that needs a small subset of what Plone can do, Plone might be a bit big. But for consultants/developers like me it is *far* easier to use Plone, remove some features and add those that are missing. A fully finished system, that end users can install and try out, is the biggest succes story of Zope. There *must* be a lesson in that somewhere. That Plone is difficult does not reflect that a big integrated system is the wrong way to go! It only indicates that the Zope/CMF/Plone stack is too big. Which is exactly why Zope 3 was developed, and I can hardly wait until something like Plone is running directly on Zope 3. Then we will both have a big hunking end user system and a clean development model. I know that something like Plone isn't the best solution for everything. Eg creating a task based intranet is impractical. But its still the most succesfull approach so far. Plone has become a very precise communication tool between programmers. If your product works in a straight Plone installation, it can be modified with known patterns by other developers. If everything is fragmented we will loose this unification by example and setting up big systems will be a lot more difficult. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
Jeff Shell wrote: I think this keeps Zope 3 as we know it alive, keeps the Zope brand intact, and offers a future for Zope 2 and similar caliber desires for a Big App Server while not interfering with the more pure and simple concepts that makes Zope 3 appealing for developers like me. I think its an absolutely terrible idea! The most succesfull Zope 2 product out there is most likely Plone. And it has everything and the kitchen sink in it. Python also has a lot of libraries included, which means that you seldomly need 3. party libraries to extend Plone. I fear that loosely coupled libraries does not make an app server. I can just imagine the upgrade hell when one package requires two different packages, and another package requires the same two different packages, but in different versions. Canonical releases of compatible package collections is a *must*. Splitting it all up in small chunks that are out of sync would be a disaster. Releases that contains a *huge* compatible collection of packages is the most effective way to move forward in an unified way. Plone products works together because Plone is so well defined. Sometimes this feels like a straightjacket. On the othe hand, in plain Zope 2 it is practically impossible to reuse other peoples products on your own site because the playing field was too loosely defined. But just like you don't have to learn every Python library to use Python, you should not have to know every package in the app server. That is not a question of making seperate releases though, it's the age old programming problem of structuring code with few interdependencies. So throw everything into the release. heck even throw Zope 2 in there if you have to. But dont force the programmers to use it before they need the functionality. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope 3 Marketing Competition? (was Re: [Zope3-dev] Re: Selecting a code name)
Martijn Faassen wrote: Alternatively, we could use our energy to actually work together on a new website instead of competing. There's a zope-web mailing list, after all, so go and talk there. This would have my preference. If you want to fix the Zope 2 website at the same time as branding Zope 3, I fear it is a monumental task that will never happen. The Zope 2 website is so big, and has so much content that it should have somebody working on it full time if it needs changing. Perhaps this monumental approach to a zope site is wrong. Microsites with well defined boundaries, that a few or a single person could be responsible for might be a better approach. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Re: Please Guido, pick me, pick me!
Martin Aspeli wrote: On Thu, 02 Feb 2006 21:12:27 -, Stephan Richter [EMAIL PROTECTED] wrote: Having said that, I feel very strongly that built Zope version 3 and nothing more or less. And I feel that a name change would betray me and my intentions. Well, Joel didn't suggest a name change, he suggested adding a codename to signify that there was something new and exciting, over and beyond Zope 2 and all the stigma attached to it, and spend a bit of time letting the world know that there is a wonderful new framework that has a lot going for it, and you should consider it. I don't see how this could possibly betray anything, and I think the Zope community would have a lot to gain from a little more buzz outside its own confines. You seem to refactor the code all the time, why are you so resitant to refactoring the brand just a little? :-) Not calling it Zope would be a mistake, but how about adding a qualifier to the name. Like microsoft did with Windows NT eg. Zope DR aka Zope Done Right The difference between Z2 and Z3 is really so great that it is not just an upgrade of the same technology. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
