here here; the current zope dtml syntax is really a nightmare. I would
I don't disagree that the current syntax is quite baroque in the mode that it is used by many people for many projects---many times because there is no other option. However...
be even more extreme and as has been suggested elsewhere would use some open and close delimiters to contain arbitrary python.
Blah, no this again violates the paradigm that we are trying to push, which is that you keep your logic code as much out of your presentation code as possible. By allowing this inclusion, I think you're only reverting to the ASP model, which is a serious step backwards. One might even argue that the painfulness of the current syntax encourages people not to write much in DTML :-) Unfortunately, we've not done a great job of giving them something else to use. This *will* change very soon I hope. The concept of call is that it will be used to do some very basic things, like: <!--#call "approveEntry()"--> You wouldn't want to implement approveEntry in DTML. At least not if it was more than a couple lines of code. I hope what I'm saying makes sense, because I think a lot of people are still approaching Zope from the mindset of CGI, PHP, ASP, etc., where you have code, logic and presentation all mingled in the same file. That's not what Zope is designed to encourage, just the reverse... we want you to seperate it as much as possible, because then you can gain re-use of data AND logic. Chris
In article <613145F79272D211914B0020AFF6401918B084@gandalf.digicool.com> , Chris Petrilli <petrilli@digicool.com> writes
here here; the current zope dtml syntax is really a nightmare. I would
I don't disagree that the current syntax is quite baroque in the mode that it is used by many people for many projects---many times because there is no other option. However...
be even more extreme and as has been suggested elsewhere would use some open and close delimiters to contain arbitrary python.
Blah, no this again violates the paradigm that we are trying to push, which is that you keep your logic code as much out of your presentation code as possible. By allowing this inclusion, I think you're only reverting to the ASP model, which is a serious step backwards.
... I don't disagree with the expressed intention, but what I observe is that people seem to be writing stuff which (to novices like me) is pretty incomprehensible. I also question whether there is such a real need for the separation. ie is the recent stuff on navigation bars good or bad code? I could just about understand it. Having to quote things several times with various delimiters eg <!--#if followed by expr="..." etc makes no use of python's clean syntax. My view is that it's easier to do the programming in Python and use strings therein. I guess I can then do without most of the <!--# keywords other than #var & #call
I hope what I'm saying makes sense, because I think a lot of people are still approaching Zope from the mindset of CGI, PHP, ASP, etc., where you have code, logic and presentation all mingled in the same file. That's not what Zope is designed to encourage, just the reverse... we want you to seperate it as much as possible, because then you can gain re-use of data AND logic.
Chris
-- Robin Becker
On Fri, 11 Jun 1999 13:30:28 -0400, Chris Petrilli <petrilli@digicool.com> said: Chris> One might even argue that the painfulness of the current syntax Chris> encourages people not to write much in DTML :-) Unfortunately, Chris> we've not done a great job of giving them something else to use. Chris> This *will* change very soon I hope. Yes, in fact, knowing a little python before starting to learn Zope, I found external methods about as easy to understand as DTML. I'm still not sure I understand DTML :-) Chris> The concept of call is that it will be used to do some very basic Chris> things, like: Chris> <!--#call "approveEntry()"--> Chris> You wouldn't want to implement approveEntry in DTML. At least Chris> not if it was more than a couple lines of code. Chris> I hope what I'm saying makes sense, because I think a lot of Chris> people are still approaching Zope from the mindset of CGI, PHP, Chris> ASP, etc., where you have code, logic and presentation all Chris> mingled in the same file. That's not what Zope is designed to Chris> encourage, just the reverse... we want you to seperate it as much Chris> as possible, because then you can gain re-use of data AND logic. This should be emphasised more in the DTML user's guide. A best-practice list of things that should and should be done with DTML vs external methods would be helpful to newcomers. Alex Rice | alrice@swcp.com | http://www.swcp.com/~alrice Current Location: N. Rio Grande Bioregion, Southwestern USA
participants (3)
-
Alex Rice -
Chris Petrilli -
Robin Becker