hi folks, first off, thanks to the people who offered quick, helpful responses to my question yesterday. ok, i'm converted. i've started implementing in zope. i have a relational database of about 8 tables. it is used for a registry of trainings and trainers. we have ten centers that will offer trainings. each center needs a publicly accessible home page where people can search on data in the database. also, each center needs a management section, where they can insert/edit/delete data and more. this section is restricted to certain validated users. my question is how to structure this in zope. i started by creating a centers folder, and a subfolder for each center. i plan to place common DTML docs and SQL methods in the centers folder, letting each center acquire them. each center has an ID property, corresponding to its unique ID in the database. i just noticed this morning that this is the same way its done in the budget sample application in the HOWTO section. i must be going in the right direction. i expect to have a number of DTML documents that are access restricted. for organizational clarity and ease of managing the permissions, i'd like to put them in a folder. but if i put them in a folder in the centers folder, then they are parallel to the individual centers and can't be acquired. does this mean i'm stuck putting them all in the centers folder? any suggestions? lets say i put a DTML document called dtViewTrainings in the centers directory. it uses a SQL method and an ID property to get trainings from the database. so the user views http://.../centers/roswell/dtViewTrainings and the ID is acquired from the roswell folder. everything's ok. but what if they browse to http://..centers/dtViewTrainings. there's an error because ID is not defined. that's fine, because the request makes no sense. but is this problem? it just kind of bugs me that the user could browse to this URL and get a meaningless error. thanks in advance for any help, -scott ----- Scott Lewis Baltic Avenue Productions csl@balticave.com
Scott Lewis wrote:
ok, i'm converted. i've started implementing in zope.
Cool! :) [description of setup snipped]
my question is how to structure this in zope. i started by creating a centers folder, and a subfolder for each center. i plan to place common DTML docs and SQL methods in the centers folder, letting each center acquire them. each center has an ID property, corresponding to its unique ID in the database. i just noticed this morning that this is the same way its done in the budget sample application in the HOWTO section. i must be going in the right direction.
i expect to have a number of DTML documents that are access restricted. for organizational clarity and ease of managing the permissions, i'd like to put them in a folder. but if i put them in a folder in the centers folder, then they are parallel to the individual centers and can't be acquired. does this mean i'm stuck putting them all in the centers folder? any suggestions?
Probably some mild level of Zope Zen is needed to realize fully that *folders* are acquired by subfolders too -- recently I faced similar organizational issues as well, and used this to good effect. I had the same setup with a root folder and a number of sub folders, and common SQL methods in the root folder so that they were acquired. As I had quite a few SQL methods this started to get messy. So I made a subfolder called 'sql' and moved all SQL methods to that place. Now I have a nice and clean root folder. Zen: All the sub folders acquire this SQL folder. Of course I had to adapt my DTML documents in the subfolders from things like: <!--#call "insert_whatever(REQUEST)"--> to: <!--#call "sql.insert_whatever(REQUEST)"--> so it's easier to set this up the right way in the beginning. You can use the same strategy for any common documents.
lets say i put a DTML document called dtViewTrainings in the centers directory. it uses a SQL method and an ID property to get trainings from the database. so the user views http://.../centers/roswell/dtViewTrainings and the ID is acquired from the roswell folder. everything's ok. but what if they browse to http://..centers/dtViewTrainings. there's an error because ID is not defined. that's fine, because the request makes no sense. but is this problem? it just kind of bugs me that the user could browse to this URL and get a meaningless error.
I think this is one of the disadvantages of acquisition; I don't know a way around it. Perhaps the Real Gurus have some advice here. I think the main idea is that users who try to create their own URLs are lucky if it works, more power to them, but when it fails they shouldn't complain. Usually a user just clicks a button or hyperlink, and those URLs should always be correct anyway. I hope this helps! Regards, Martijn
On Wed, 21 Apr 1999, Martijn Faassen wrote:
Scott Lewis wrote:
i expect to have a number of DTML documents that are access restricted. for organizational clarity and ease of managing the permissions, i'd like to put them in a folder. but if i put them in a folder in the centers folder, then they are parallel to the individual centers and can't be acquired. does this mean i'm stuck putting them all in the centers folder? any suggestions?
Probably some mild level of Zope Zen is needed to realize fully that *folders* are acquired by subfolders too -- recently I faced similar organizational issues as well, and used this to good effect.
I had the same setup with a root folder and a number of sub folders, and common SQL methods in the root folder so that they were acquired. As I had quite a few SQL methods this started to get messy. So I made a subfolder called 'sql' and moved all SQL methods to that place. Now I have a nice and clean root folder.
Zen: All the sub folders acquire this SQL folder.
I had the exact same situation and came up with another way to handle it... Zen: Acquisition is dynamic (run-time) and can be redefined by the traversal path (URL). That is, you don't need to change from...
Of course I had to adapt my DTML documents in the subfolders from things like:
<!--#call "insert_whatever(REQUEST)"-->
to:
<!--#call "sql.insert_whatever(REQUEST)"-->
You just place the 'sql' folder in the URL of pages that need it. For example... Site map: /sql - all sql methods /search - interfaces search database /admin - alter database /browse - browse through database contents All the URL's look something like this: http://www.somesite.com/sql/search/findit/ Works great, with one caveat. The view tab doesn't work with the sql. This doesn't bother me though, as I don't usually use the view tab. --- John Eikenberry [jae@kavi.com - http://taos.kavi.com/~jae/] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
Martijn Faassen wrote:
Probably some mild level of Zope Zen is needed to realize fully that *folders* are acquired by subfolders too -- recently I faced similar organizational issues as well, and used this to good effect.
I had the same setup with a root folder and a number of sub folders, and common SQL methods in the root folder so that they were acquired. As I had quite a few SQL methods this started to get messy. So I made a subfolder called 'sql' and moved all SQL methods to that place. Now I have a nice and clean root folder.
Zen: All the sub folders acquire this SQL folder.
Of course I had to adapt my DTML documents in the subfolders from things like:
<!--#call "insert_whatever(REQUEST)"-->
to:
<!--#call "sql.insert_whatever(REQUEST)"-->
so it's easier to set this up the right way in the beginning.
You can use the same strategy for any common documents.
I really like the sound of this, and I've been re-organising my Zope application organisation, but I've hit a snag. I used to call DTML documents with <!--#var myfunction--> so now, since they are in a sibling folder under the root folder, (eg /myapp) I tried: <!--#var myapp.myfunction--> But it doesn't work any more - keeps giving KeyErrors. The funny thing is that <!--#var "myapp.myfunction"--> correctly returns all the raw content of the DTML document, so it *can* find it OK. Any ideas? Cheers, Martin -- ### Martin Dougiamas -- Internet Agent is == i see ### Centre for Educational Advancement ### http://cea.curtin.edu/staff/martin
Martin Dougiamas wrote:
The funny thing is that
<!--#var "myapp.myfunction"-->
correctly returns all the raw content of the DTML document, so it *can* find it OK.
Any ideas?
The quotes switch DTML into "expr" (expression) mode. Outside of expressions, DTML is limited to very safe operations. Getting attributes (the dot) is an operation that requires the security machinery to get involved, to make sure that you have permission. I agree that this inconsistency is confusing, as are things like sequence-item outside an expression and sequence_item inside an expression. Perhaps if we do a major overhaul of DTML (e.g. changing it to an XML-ish syntax) we'll look for ways to make it more consistent. --Paul
Paul Everitt wrote:
Martin Dougiamas wrote:
The funny thing is that
<!--#var "myapp.myfunction"-->
correctly returns all the raw content of the DTML document, so it *can* find it OK.
Any ideas?
The quotes switch DTML into "expr" (expression) mode. Outside of expressions, DTML is limited to very safe operations. Getting attributes (the dot) is an operation that requires the security machinery to get involved, to make sure that you have permission.
Oh. I was logged in as manager .... so I didn't think security was a problem. Is there any other way to do this? For now I'm using the other suggested technique in this thread, of <!--#var myfunction--> and just calling it from the browser as: /myapp/somedirectory/somefilethatcallsmyfunction but it does spoil the URLs somewhat. Cheers, Martin -- ### Martin Dougiamas -- Internet Agent is == i see ### Centre for Educational Advancement ### http://cea.curtin.edu/staff/martin
Martin Dougiamas wrote:
Paul Everitt wrote:
Martin Dougiamas wrote:
The funny thing is that
<!--#var "myapp.myfunction"-->
correctly returns all the raw content of the DTML document, so it *can* find it OK.
Any ideas?
The quotes switch DTML into "expr" (expression) mode. Outside of expressions, DTML is limited to very safe operations. Getting attributes (the dot) is an operation that requires the security machinery to get involved, to make sure that you have permission.
Oh. I was logged in as manager .... so I didn't think security was a problem. Is there any other way to do this?
I think you misunderstood Paul just now; he didn't mean security was a problem, he just intended to give an explanation of why the foo.bar trick only works in quotes. The quotes are simply a short cut to 'expr="foo.bar"', i.e.: <!--#var "foo.bar"--> is the same as <!--#var expr="foo.bar"--> but <!--#var foo.bar--> doesn't work, as apparently this expression is too complicated to evaluate safely without the quotes. The quotes *are* necessary, though. Is this a big problem? Perhaps a Next Generation DTML could do away with the first 'quoteless' notation altogether, to avoid such confusion? Hm.. Regards, Martijn
Martijn Faassen wrote:
Martin Dougiamas wrote:
Paul Everitt wrote:
The quotes switch DTML into "expr" (expression) mode. Outside of expressions, DTML is limited to very safe operations. Getting attributes (the dot) is an operation that requires the security machinery to get involved, to make sure that you have permission.
Oh. I was logged in as manager .... so I didn't think security was a problem. Is there any other way to do this?
I think you misunderstood Paul just now; he didn't mean security was a problem, he just intended to give an explanation of why the foo.bar trick only works in quotes. The quotes are simply a short cut to 'expr="foo.bar"', i.e.:
<!--#var "foo.bar"-->
is the same as
<!--#var expr="foo.bar"-->
but
<!--#var foo.bar-->
doesn't work, as apparently this expression is too complicated to evaluate safely without the quotes.
Well, it was not so much a misunderstanding, so much as a further plea for help with my original problem! :) The discussion on NG DTML is very interesting, but I'm still trying to call objects in "Aunty" folders using the current version of DTML. Putting it in quotes means that the contents of the DTML document are inserted "raw" into my current document, rather than being evaluated. ie:
I used to call DTML documents with
<!--#var myfunction-->
so now, since they are in a sibling folder under the root folder, (eg /myapp) I tried:
<!--#var myapp.myfunction-->
But it doesn't work any more - keeps giving KeyErrors.
The funny thing is that
<!--#var "myapp.myfunction"-->
correctly returns all the raw content of the DTML document, so it *can* find it OK.
Martin -- ### Martin Dougiamas -- Internet Agent is == i see ### Centre for Educational Advancement ### http://cea.curtin.edu/staff/martin
Paul Everitt wrote: [snip DTML discussion]
I agree that this inconsistency is confusing, as are things like sequence-item outside an expression and sequence_item inside an expression. Perhaps if we do a major overhaul of DTML (e.g. changing it to an XML-ish syntax) we'll look for ways to make it more consistent.
I've been vaguely thinking about Next Generation DTML myself recently -- DTML is nice and powerful but it can get confusing in the corners. Coincidentally I've been reading up on XML as well. If you people get serious about doing NG-DTML I think people in the group would like to contribute/interfere in the design, at least I would. :) Am I right in assuming that one could use DTML and NG-DTML in parallel in the same Zope database, if one defined a NGDTML (ugh :) Document/Method product? That would be a nice way to do some experimental development. Regards, Martijn
Martijn Faassen wrote:
If you people get serious about doing NG-DTML I think people in the group would like to contribute/interfere in the design, at least I would. :) Am I right in assuming that one could use DTML and NG-DTML in parallel in the same Zope database, if one defined a NGDTML (ugh :) Document/Method product? That would be a nice way to do some experimental development.
I certainly hope we'll remember to include everybody, especially those submitting patches :^) --Paul
Martijn Faassen wrote:
parallel in the same Zope database, if one defined a NGDTML (ugh :)
Perhaps a rewritten 'next generation' DTML would be the time to 'Zopify' the name - ZTML anyone? -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
Paul Everitt wrote:
Martin Dougiamas wrote:
The funny thing is that
<!--#var "myapp.myfunction"-->
correctly returns all the raw content of the DTML document, so it *can* find it OK.
Any ideas?
The quotes switch DTML into "expr" (expression) mode. Outside of expressions, DTML is limited to very safe operations. Getting attributes (the dot) is an operation that requires the security machinery to get involved, to make sure that you have permission.
Dot notation and expressions have nothing to do with security. The difference is really about language. <!--#var foo--> is a short-hand for <!--#var name="foo"--> while: <!--#var "foo"--> is a short-hand for: <!--#var expr="foo"--> The argument to the name attribute is a DTML name, where there is no restrictions on characters in the name and no special interpretation has been given to any characters. Further, when a name is looked up, and the value is a document template or a callable object that requires no arguments, it is called. The argument for the expr attribute is a Python expression. The semantics for this value are defined by the Python language and any special objects, like '_'. In Python, objects are not called unless you supply the call operator. If you have a function, foo, the expression "foo" returns the function, not the result of calling the function.
I agree that this inconsistency
I don't agree that this is an inconsistency. An expression attribute always takes a Python expression with Python expression semantics. A name attribute always takes a DTML name, with DTML name lookup semantics.
is confusing,
The confusomg part is that: <!--#var "foo"--> looks so much like: <!--#var foo--> Perhaps this shorthand notation (which was added by popular demand) should be discouraged.
as are things like sequence-item outside an expression and sequence_item inside an expression.
"sequence_item" is not a special spelling for "sequence-item". When used as a name, you say: <!--#var sequence-item--> This is consistent with rules for DTML names. The dash was used in this (and similar names) to avoid conflicts with other names. In expressions, you say: <!--#var "_['sequence-item']--> Because "sequence-item" is not a legal Python name, we have to quote the name and do an explicit lookup from the namespace object, '_'. This seems very consistent to me.
Perhaps if we do a major overhaul of DTML (e.g. changing it to an XML-ish syntax) we'll look for ways to make it more consistent.
I don't expect adding an XML-compliant format to DTML to cause a major overhaul. XML *is* far more explicit that current DTML (and HTML) formats, so confusing short-hands will not be an option. You will *have* to name the attributes explicitly. Of course, people will still have to know the semantics for the various attributes. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Martin Dougiamas wrote:
Martijn Faassen wrote:
Probably some mild level of Zope Zen is needed to realize fully that *folders* are acquired by subfolders too -- recently I faced similar organizational issues as well, and used this to good effect.
I had the same setup with a root folder and a number of sub folders, and common SQL methods in the root folder so that they were acquired. As I had quite a few SQL methods this started to get messy. So I made a subfolder called 'sql' and moved all SQL methods to that place. Now I have a nice and clean root folder.
Zen: All the sub folders acquire this SQL folder.
Of course I had to adapt my DTML documents in the subfolders from things like:
<!--#call "insert_whatever(REQUEST)"-->
to:
<!--#call "sql.insert_whatever(REQUEST)"-->
so it's easier to set this up the right way in the beginning.
You can use the same strategy for any common documents.
I really like the sound of this, and I've been re-organising my Zope application organisation, but I've hit a snag.
I used to call DTML documents with
<!--#var myfunction-->
so now, since they are in a sibling folder under the root folder, (eg /myapp) I tried:
<!--#var myapp.myfunction-->
But it doesn't work any more - keeps giving KeyErrors.
The funny thing is that
<!--#var "myapp.myfunction"-->
correctly returns all the raw content of the DTML document, so it *can* find it OK.
Any ideas?
Sure. See my response to Paul. The bottom line is that you have to call the document template explicitly when you use it in a (Python) expression: <!--#var "myapp.myfunction(None, _)"--> This is the way that DocumentTemplates call other document templates when they aren't used in expressions. It is important to pass the current document template namespace, '_' as the second argument. This provides access to the current namespace to the document template being called. The first argument, 'None', is just a placeholder, since these arguments are positional. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (7)
-
Jim Fulton -
John Eikenberry -
Martijn Faassen -
Martin Dougiamas -
Paul Everitt -
Ross J. Reedstrom -
Scott Lewis