Re: [Zope3-dev] Re: Zope 3 web root
Shane Hathaway wrote: [snip] Yes, that's a valid point. I also stopped myself from listing folders, since a folder is a general organizational tool. Let's just talk about templates and scripts. [snip] I think I've got a decent use case for templates in the ZODB, but I could be wrong. I work for a large publishing company, and typically one of our applications will get installed on 40 or 50 sites within the same Zope instance, differing only in cosmetic ways. It seems like the logical thing to do here is to treat the templates as data and let them be edited TTW, limiting the coding level to 'presentation only'. -- Wade Leftwich Ithaca, NY ___ 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
Shane Hathaway wrote: Wade Leftwich wrote: Shane Hathaway wrote: [snip] Yes, that's a valid point. I also stopped myself from listing folders, since a folder is a general organizational tool. Let's just talk about templates and scripts. [snip] I think I've got a decent use case for templates in the ZODB, but I could be wrong. I work for a large publishing company, and typically one of our applications will get installed on 40 or 50 sites within the same Zope instance, differing only in cosmetic ways. It seems like the logical thing to do here is to treat the templates as data and let them be edited TTW, limiting the coding level to 'presentation only'. That can work, but be aware of the customers who customize more than you expect. They'll push the limits of the templates, and some of them might push so hard that they wind up creating a whole new framework based on your template API. You'll have to help them migrate their templates to new versions of your software, you'll have to put their templates under version control, you'll have to test new versions of your system with their templates, etc. I saw this pattern emerge several times at Zope Corporation, and I don't think it's specific to Zope 2. Maybe you can design a system that exposes a perfect, unchanging API to templates, but I'm pretty sure I can't. Shane We're supporting corporate users, so s/customers/coworkers/, but I see your point, and am interested in some of the less featureful templating alternatives being discussed -- meld3 et al. In Zope 2 our group follows the approach described by Stefan Holek in the tal:define considered harmful thread earlier today, and we put all the data the template is going to need into the options namespace. From Stefan's post: My take is that it's not the TAL features (tal:define, python:, whatever) that invite misuse, but the available namespaces. I have ported ZPT to Django [1][2] and found the experience surprisingly refreshing. Django naturally does not have anything like container or context in the Zope sense. And by Django policy, templates don't even get to see the request. The namespace Zope PTs call options becomes the sole, top-level namespace in Django PTs. This very effectively keeps me from pulling-in anything not provided by the view in the first place. Everything -- even functions I want to call in, say, conditions -- has to be added by the view. The result is clean and fast templates. -- Wade ___ 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
Shane Hathaway wrote: An idea just occurred to me. I think others have probably had similar ideas, but didn't express it in the right place or time. Part 1: Let's put an Apache-like web root (similar to /var/www/localhost/htdocs/) in Zope instance homes. It might be called browser or www. Zope will serve pages out of that web root rather than an object database. Part 1 rationale: When people create a Zope instance home, they create some config files and an object database. The root of the site is served out of the object database. To change the default page, newbies are directed to create a default page in the object database. The user didn't ask for an object database. The use of an object database should be a choice, not a requirement. Now the user has to learn some extra tools (fssync, etc.) in order to put the files under version control. I think the user experience for both newbies and experts would be much better if the root of the site were served from a filesystem directory. -8-- Any thoughts or gut reactions? Shane +1 from the standpoint of promoting corporate adoption, especially when combined with first-class citizenship for RDBMS. (In the corporation I work for, anyway.) -- Wade Leftwich Ithaca, NY ___ 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
Shane Hathaway 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. However, I expect ZODB to continue to be the dominant platform for writing Zope applications, because ZODB is quite productive for writing abstract applications. Zope is a feast with many kinds of food. When people come to the feast, most are not willing to try everything at once, particularly the entrees from the land of OODBMS. First let them have some familiar foods. When they find out how finely prepared the food is, they'll be ready to try the meaty main course. Although many will still prefer the RDBMS salads. Shane Man, now I really wish I hadn't skipped lunch. Page templates and SQL scripts on the filesystem -- my co. has a bunch of successful Zope2 little applications built that way (except TTW of course), tying in to existing RDB's. It's a great story for Zope3, especially if we can make sure that RDB inserts and updates participate properly in Zope transactions. Without it, we find our selves saying OK, we'll use Django for quick little apps, Zope3 for big apps. What happens when little apps grow? Uh. Following the lead of Holger Froebe, I'm looking at using Sqlalchemy with Z3 to get access to more SQL syntax than SqlObject currently exposes. By the way, Holger wrote a terrific Z3 advocacy post the other day: http://www.jrandolph.com/blog/?p=23#comment-324 -- Wade ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Scripters, websites, documentation, advocacy
On 1/4/06, Jeff Shell wrote: On 1/3/06, Wade Leftwich [EMAIL PROTECTED] wrote: Andreas Jung wrote: To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) Or at least almost as easily as in RoR or Django. TTW is not a requirement; Chris McDonough's TTB posting was right on target (http://www.plope.com/Members/chrism/ttb_programming). Are those 'scripters'? I see RoR and Django going down the same path that Zope 2 went down. They're great, they're young, they're inexperienced. Django's horrible query syntax reminds me of the cryptic early index querying that Zope / Principia had that was geared primarily for input coming in from web forms and not scripting. I see both of those projects taking either shortcuts or blanket we only do things this way statements. [Django: we don't support HTTP auth. We've never needed it.]. It's not to say they're bad products at all. To work in Django, you essentially are using Django's admins, which apparently many of their target users don't mind. This is akin to just using and promoting the Plone UI, the ZMI (zope 2 or zope 3's) or whatever. Neither I nor my customers have wanted those UIs. I love Zope 3 for finally giving me the freedom of detaching from the ZMI completely (with me having the option to use it for emergencies, but our own much more focused skins should do the job well enough to not need it). There are 3 PHP developers in the group I work in, and they know they want something better, and they like Python. But when they look at Z3 they get all upset confused. I like Ruby. But when I look at rails I get all upset and confused. I still have no idea how its widgets work. With Zope 3, I was able to follow the adapter lookup chain. Granted, I'm pretty familiar with Zope 3's component architecture by now. Zope 3 needs better advocacy. It needs better web site(s). If zope3.org turns out to be a Wiki I promise to take extra medication and try to add some helpful material to it as possible, because I think Zope 3 is really lacking in different levels of tutorials from different authors who have different perspectives that may better help different audiences. *whew!* That's the problem. It's great that there are books out there. But there's no good central and well promoted advocacy sites. Many Zope 3 developers, like myself, I imagine are often very heavy with real work engagements and finding spare time to write and advocate aren't there. Is this (increased usability for non-experts) a possible project for the Zope sprint at Pycon? I'll be there. And since I am not an expert myself, I will have a head start. I still think that a great increased usability could come from a zope3 focused web site that is simple and fun. With the time based releases, it's known what's going to be in each release. My gods, I'd LOVE to see articles like Exploring Zope 3.x: New feature - Viewlets. I'd LOVE to see clear documents like Exploring Zope 3.x: what's deprecated, why, and how to fix it. The doctest documentation about content providers, forms, and viewlets are great for experts. At least there's fairly comprehensive documentation that I can read and figure out and go ahh!. But turning that into a more comprehensive non-expert story on a web site would be a good thing. I agree completely. What else can I say? Maybe just a few things: Yes, the best fastest way to get better usability for non-experts (including but not limited to 'scripters') is through more tutorials better docs. This is also the point I took away from Chris McDonough's TTB posting. If I can help in that regard, I would love to participate. Love it or don't love it, Ruby on Rails definitely raised the bar for having a cool website and generating lots of buzz around your web application server project. Setting aside all technical considerations, Django and TurboGears picked up on this lesson and got some traction, and Subway did not and did not. Meanwhile, Zope 3 moves forward in spite of its web presence. Actually the place I have been going to help me get ahold of the big concepts in Zope 3 is http://griddlenoise.blogspot.com. It's also one of very few weblogs where you can find any kind of Zope 3 advocacy. I still think that a great increased usability could come from a zope3 focused web site that is simple and fun. With the time based releases, it's known what's going to be in each release. My gods, I'd LOVE to see articles like Exploring Zope 3.x: New feature - Viewlets. I'd LOVE to see clear documents like Exploring Zope 3.x: what's deprecated, why, and how to fix it. Absolutely. ___ 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: RFC: abolishing python: expressions in ZPT TALES
Andreas Jung wrote: --On 29. Dezember 2005 10:08:03 -0330 Rocky Burt [EMAIL PROTECTED] wrote: Andreas Jung wrote: Another argument against removing python expressions: in Zope 2 scripters could directly modify and test templates, script etc. (also using the skins tool). In Z3 you have to restart the server at least for view classes (but not for templates). Personally I would say implement logic that allows view classes to be reloadable rather than relying on zpt for exactly this reason if this is indeed something developers need/want (I would love for such a feature). This was also one of the nice things about writing python scripts as a skins item with CMF as it was instantly reloadable. To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) -aj Or at least almost as easily as in RoR or Django. TTW is not a requirement; Chris McDonough's TTB posting was right on target (http://www.plope.com/Members/chrism/ttb_programming). There are 3 PHP developers in the group I work in, and they know they want something better, and they like Python. But when they look at Z3 they get all upset confused. Is this (increased usability for non-experts) a possible project for the Zope sprint at Pycon? I'll be there. And since I am not an expert myself, I will have a head start. -- Wade Leftwich Ithaca, NY ___ 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: Twisted Publisher and Zope 2
Tres Seaver wrote: If twisted and ZEO are incompatible, then twisted needs *never* to be the default; ZEO is an essential part of Zope's real world story. I can't imagine even *developing* without ZEO, much less deploying applications in production. Tres. -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com Endorsing this statement. We've got Zope 2 running in a cluster with ZEO (and DirectoryStorage). Besides being the right way to do our application, ZEO was essential in getting past the CIO asking What do you mean you won't be using Sql Server? -- Wade Leftwich Ithaca, NY ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Subversion not working 11/8/2005 6:30am EST
http://svn.zope.org/ An Exception Has Occurred Python Traceback Traceback (most recent call last): File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 3196, in main request.run_viewcvs() File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 265, in run_viewcvs self.rootpath, rev) File /usr/local/viewcvs-1.0-dev/lib/vclib/svn/__init__.py, line 322, in __init__ self.repos = repos.svn_repos_open(rootpath, self.pool) SubversionException: (Berkeley DB error while opening 'strings' table for filesystem /svn/repos/main/db:\nCannot allocate memory, 160029) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
