I have been watching this thread silently for what seems like weeks, and I think it is time for a newcomer's opinion. I like to read above my station ;-)
>> "options/a_mapping/key:items/index:0" rather than >> "python:options['a_mapping']['items'][0]". They look very similar to me. There is little or no simplification from one to the other. If it is easy to do and shall not impact on the performance of TAL, then go ahead and do it. Otherwise, leave it alone. If you have enough knowledge to create the first one, you can certainly generate the second. The only problem I ever have in this area is knowing when something is too complicated for TAL, and moving that boundary will not help. Often I solve the problem by using a tal:define, which allows the following TAL to cope with the variables I am trying to throw at it. In general this is my rule: do not ask TAL to cope with expressions outside of a define statement. Let it stick with truth and looping, which it is exceptionally good at. Chris> What an extraordinarily good idea! Why has none of us thought of this before? Because it's so extraordinarily /not new/, in the sense that it might be handy when everything else is working but remains unnecessary otherwise. I, for one, remain opposed to the idea that there should be several ways to do the same thing, just because the newer one looks a bit prettier. Newcomers spend time choosing between them to avoid developing a ZClass when they need a Product. Especially when the difference is purely syntactic, nobody bothers to write down that they are purely equivalent. Chris> I wonder what non-python'ers would think? Paul> well, that's a very good and relevant question, but I Paul> doubt we will find them on this mailing list :-) Paul> I would really like to know. I am a relevant newcomer who is getting confused by all the options. I have avoided learning DTML beyond recognising it when I see it, but still find the whole experience quite bewildering at times. It took me the months of UML work to convince my colleague (and introducer) that DTML was a backward step, and only on presenting him with the hard-to-find zpt2dtml conversion guide did I finally make my point that everything was possible without DTML and its implicit acquisition. For my money, get someone to spend time documenting option one first, and explaining why it is useful; then make option two work if there is still demand. It's less sexy, but much more productive. For instance, I spent a long time under the misapprehension that 'options/' was the only way to get python variables into templates, because that's how it shows you in the ZDG. You have an excellent product that is far more powerful than people have realised. <shout>Keep up the good work!</shout> <whisper>which might mean more marketing (documenting) and less programming</whisper> Paul> We all know that Python has a near-unbeatable record Paul> as an easy-to-use, well-designed, and downright fun language. Paul> It has a great reputation as a "first language". I think this is overstating things a little. I came to Zope/python from a background in perl-based Intershop4 and found the transition hard enough. I had printed out the 80 page reference manual before I discovered that it contained not a single python command: only on returning to it after eight months did it begin to make sense, yet wonderful features such as __call__ should be carefully documented as important in Zope Products. Paul> The zope 2 tutorial and most other available documents gave Paul> the impression that you didn't need to learn python to get things Paul> done in Zope. The Zope Book gives the impression that DTML is a poor-man's substitute to ZPT/python, which is why I did not spend time on it. It actually left me with the impression that DTML and python did not really get on. Paul> If you don't know any python, isn't it tempting to write some Paul> icky template code yourself instead of waiting for the code Paul> guy to have time to help you? That's exactly why I wrote custom templates for Intershop 4. It did not support search-within-search, or search-within-category, yet it was clear from the database schema that it should and could with little effort. Luckily the only way to do it was to create the object in advance from the database and loop over it in the presentation. Those of you interested in "options/a_mapping/key:items/index:0" would like their approach. Incidentally, and off topic. I read somewhere here that Zope3 is abolishing implicit acquisition. What should a developer be doing /now/ to avoid obsolescence? Should we use .Explicit throughout for new products, or what? And what does that mean exactly? It's not really documented in the ZDG (maybe a page and a bit), and specifically says (Ch. 3) """In general you should subclass from Acquisition.Implicit unless you have a good reason not to.""" Is Zope3 that good reason? MfG Christopher Boomer, Belfast. _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
