Re: [Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
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. ___ 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
[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
Andreas Jung wrote: > > To bring it to the point: _scripters_ should be able to develop in Zope > 3 as easy as in Zope 2 :-) > > -aj > I'd go further and say regular developers should be able to develop faster with Zope 3 by having automatic reloading in most python modules in debug mode :-) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
--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 pgpC5PO9Jq6U4.pgp Description: PGP signature ___ 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
On Thu, 2005-12-29 at 15:40 +0100, Andreas Jung wrote: > > What I am saying: don't take away feature that are useful for a particular > kind of coders and for a particular way of coding. Don't take away a feature > _just_ to enforce a certain way to do programming. +1 to Andreas. -1 to the proposal. Andrew ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
Igor Stroh wrote: > +/-0 > I'd give it a +1 if TAL would support boolean operators :) That's something we could give some thought. It might not be that hard to implement a BooleanExpression for TALES... > Another use case is the passing of arguments > to a method/function/whatever - you might have a tal:repeat > where each iteration calls a view method and where just need > to supply an argument and you can't since TALs path syntax > doesn't support that (I say tal:repeat here, 'cos in other > situations you _probably_ can retrieve the value from REQUEST). I think the amount of calls from ZPT into content space or any calls from ZPT at all should be limited IMHO. A while ago we had a discussion (I think it was on Paul's blog) on push vs. pull. I think ZPTs could be simplified a lot with more data pushing from Python. Basically, ZPTs should only be able to understand iterables, mappings and objects with a public attribute API (let's get rid of that implicit calling too!). I think this is one of the strongholds of ClearSilver and that's also what makes it fast like hell (that and the fact it's written in C ;)). 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: RFC: abolishing python: expressions in ZPT TALES
Chris McDonough wrote:
> I'm +1 for deprecating python: expressions in the context of views.
> But I'm not sure what "deprecate" would mean; I doubt they can go away
> entirely given the body of code that exists which uses them.
That doesn't mean they can't go away for sure. It would just mean we'd
have to be careful, perhaps give a longer deprecation period and aid
people in converting their code with good tutorials.
> An interesting thing about python: expressions... I've found that
> simple "python: foo['bar']" expressions are typically faster than their
> path counterparts ("foo/bar") because they are more explicit. This is
> not an argument to use them instead of path expressions, but I thought
> it was interesting regardless in a I-didn't-expect-that kind of way.
>
> If there was even a small speed win in making TALES expression parsing
> faster by removing support for python: in some backwards- incompatible
> mode, that would be a *reason* to deprecate-in-code rather than
> deprecate-in-documentation.
I think it would be quite possible to do explicit key or attribute
lookup with TALES, e.g.:
foo/attr:bar (for foo.bar)
foo/key:bar (for foo['bar'])
foo/item:1(for foo[1])
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: RFC: abolishing python: expressions in ZPT TALES
--On 29. Dezember 2005 10:08:03 -0330 Rocky Burt <[EMAIL PROTECTED]> wrote: 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. What I am saying: don't take away feature that are useful for a particular kind of coders and for a particular way of coding. Don't take away a feature _just_ to enforce a certain way to do programming. -aj pgpT2WdviFRIQ.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
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. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
Rocky Burt wrote: Its my personal opinion that anytime a page template requires logic complicated enough to warrant using a 'python:' expression, that logic should be re-thought and placed into a view class. I know that some python: expressions are fairly simple, but for an HTML designer, *any* python: portions are dangerous to touch (and shouldn't be touched by the HTML designer). -1 At least not until TALES has a way to do: - basic boolean logic (foo or bar, foo and not bar, ...) - basic sequence indexing (foo[1]) Florent -- 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/archive%40mail-archive.com
