RE: [Zope] Acquisition? Did I just lose my Zen?
-----Original Message----- From: Jay R. Ashworth [mailto:jra@baylink.com] Sent: Tuesday, September 21, 1999 12:56 PM To: zope@zope.org Subject: Re: [Zope] Acquisition? Did I just lose my Zen?
On Tue, Sep 21, 1999 at 12:25:10PM +0000, Jim Fulton wrote:
When you acquire an object, the acquired object gets the context of the aquirer *and* the context it was acquired from, with the source ^^ context taking precedence over the destination context. In the example above, 'Personal' acquires from the top-level folder first, and then from the 'frames' folder.
That started off as a useful tidbit... then we got to the pronoun without a referent.
"It".
Which it?
The _acquired_ object. -Michel
On Tue, Sep 21, 1999 at 01:55:08PM -0400, Michel Pelletier wrote:
On Tue, Sep 21, 1999 at 12:25:10PM +0000, Jim Fulton wrote:
When you acquire an object, the acquired object gets the context of the aquirer *and* the context it was acquired from, with the source ^^ context taking precedence over the destination context. In the example above, 'Personal' acquires from the top-level folder first, and then from the 'frames' folder.
That started off as a useful tidbit... then we got to the pronoun without a referent. "It". Which it?
The _acquired_ object.
Got it. Then, I agree with the other folks. How can you override the context of the place where you acquired it _from_ with the context of the place where you acquired it _to_? That would seem to be a very important ability... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
"Jay R. Ashworth" wrote:
Got it. Then, I agree with the other folks. How can you override the context of the place where you acquired it _from_ with the context of the place where you acquired it _to_? That would seem to be a very important ability...
It would be really nice. Beyond a /noframes version we'd do things like: 1) Have a /print folder so if we call /print/mypage instead of /mypage the result would be a printable version of the page. 2) A /text folder where all image objects would be replaced by dtml methods giving us a text version of a site. 3) Any kind of /otherDesign folder with a customized version of your site. Nice for syndicalization. 4) A /german folder that have a LANG="de" property to make a german version of a site. It would be easy to have a multilingual site. Is it possible to code a special kind of folder that changes the aquisition order? -- Paulo Eduardo Neves maito:neves@email.com
Paulo Eduardo Neves wrote:
"Jay R. Ashworth" wrote:
Got it. Then, I agree with the other folks. How can you override the context of the place where you acquired it _from_ with the context of the place where you acquired it _to_? That would seem to be a very important ability...
It would be really nice. Beyond a /noframes version we'd do things like:
1) Have a /print folder so if we call /print/mypage instead of /mypage the result would be a printable version of the page.
2) A /text folder where all image objects would be replaced by dtml methods giving us a text version of a site.
3) Any kind of /otherDesign folder with a customized version of your site. Nice for syndicalization.
4) A /german folder that have a LANG="de" property to make a german version of a site. It would be easy to have a multilingual site.
Is it possible to code a special kind of folder that changes the aquisition order?
One thing I'd like to point out here, is that you are getting into something very, very deep. This discussion has gone pretty far, but I still dont get it. What I want to see is a very, very trivial example of what you want to do, and why you can't do it now. There may be another solution. The next point is that we will soon be modeling this. Modeling, for those of you who don't know, is just like modeling a physical structure. If you're building a shack (a small perl script) you really wouldn't need to model it out. If you were building a skyscraper (Zope) you would probably need a good set of blueprints. These blueprints are written in a language called UML, which is a visual language. We have allready published one piece of Zope in UML (http://www.zope.org:18200/Documentation/Developer/Models/ZODB) the object database, and in the next couple of days here I'll have released a very interesting model, the ZCatalog. Acquisition needs to be modeled, then we can truely get what's going on here. In the meantime, let's hear some simplification of this problem, I'm still lost on what we're talking about. -Michel
-- Paulo Eduardo Neves maito:neves@email.com
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Michel Pelletier wrote:
Acquisition needs to be modeled, then we can truely get what's going on here. In the meantime, let's hear some simplification of this problem, I'm still lost on what we're talking about.
I have different banner and logo for each section of my site. each section has it's own image folder. in each image folder is an image id="logo" and an image id="banner". Root has the same feature (it's own image folder, etc.) My standard_html_header says something like this: <dtml-with images> <dtml-var logo> <dtml-var banner> </dtml-with> I made the same assumption as Martjin, that is, that images would come from within the existing folder. it seems like this is in zope a lot, but maybe I've only seen it in an iterative context- like dt-Content for the content for document tree calls the dtml method in the directory it's parsing, not the directory it's from. for some reason this made me think I could do the above. -- ~mindlace
Ethan Fremen wrote:
I have different banner and logo for each section of my site. each section has it's own image folder...
etc.etc. nevermind, i figured it out. I've got to RTFM more before posting. /me looks sheepish. -- ~mindlace
Paulo Eduardo Neves wrote:
"Jay R. Ashworth" wrote:
Got it. Then, I agree with the other folks. How can you override the context of the place where you acquired it _from_ with the context of the place where you acquired it _to_? That would seem to be a very important ability...
I gave some examples and Michel Pelletier wrote:
One thing I'd like to point out here, is that you are getting into something very, very deep. This discussion has gone pretty far, but I still dont get it.
I also think it is complex. So complex that I initially had a misconception about how acquisition works. I was glad to see that I was not the only one:-)
What I want to see is a very, very trivial example of what you want to do, and why you can't do it now. There may be another solution.
I think I won't be able to give you a very trivial example. Zope is so powerful that it can handle all trivial examples I can think. Trivial things like the /print folder for a printable page can be handled other ways like the ?pp=1 argument to get printable pages in Zope.org. I believe a /print folder would be more elegant, but is just a matter of taste. No need to modify Zope:-) I was really thinking about a structure to build multi-lingual sites. I'll try to sketch an example. Suppose you have the following objects in your root folder: myContents /folder mySQLMethod <= these are contained in /folder index_html /portuguese myContents The root folder also has a string property LG="en". It has a folder named /portuguese that has a string property LG="pt", and a myContents document which text is written in portuguese. Suppose index_html has all the page formatting and it also includes myContents and use the results of the query mySQLMethod. mySQLMethod would query a database table that has two contents fields, let's call them "content_en" and "content_pt". This is a possible implementation: SELECT content_id, date, <dtml-var "'content_' + LG"> as content FROM Table If acquisition worked according to Martjin, calling /folder would show an english version of the site, and /portuguese/folder would give an portuguese version. Is it reasonable? It would be a nice way to approach the hard problem of multi-lingual dynamic sites.
The next point is that we will soon be modeling this.
...
Acquisition needs to be modeled, then we can truely get what's going on here.
Great! Zope documentation are really improving a lot. Each time there is less excuses for not use Zope.
In the meantime, let's hear some simplification of this problem, I'm still lost on what we're talking about.
Hope this helped. best regards, -- Paulo Eduardo Neves maito:neves@email.com
On Wed, 22 Sep 1999 18:52:39 -0300, you wrote:
Paulo Eduardo Neves wrote:
"Jay R. Ashworth" wrote:
Got it. Then, I agree with the other folks. How can you override the context of the place where you acquired it _from_ with the context of the place where you acquired it _to_? That would seem to be a very important ability...
I had been working with Zope for six months before realising that acquisition did not work that way already, and I was relieved. Maybe I can persuade you that it would be a bad thing..... With the rules as they are, an object can always rely on acquisition to source its containers first. Think of an object's containers as part of it's implementation, and the rules feel right. Under the rules suggested by Martjin, acquisition would source attributes from an object's customers in preference to its containers (As Jay wrote, the place where you acquired it _to_, rather than the place where you acquired it _from_). I don't think you could use that kind of acquistion to build a robust application, because of the unbounded number of potential clients each object might encounter. An object could never really rely on what it might pick up through acquisition. If you need that kind of wild flexibility then IMO it is better to explicitly pass it from the client object as a parameter, rather than asking it to be acquired from the client. With the current rules it is almost possible to use acquistion in the way that Martjin wanted, by ensuring that there is no object with the right id in the acquiring object's containers; the acquisition search can 'spill out' into other contexts. However this is dangerous for a different reason; the search order may be diffent to what you expect...... For those who think they understand it, heres a quick quiz. The script below is a variation of one in the acquisition documention, but what order are objects searched when looking up 'attribute' in these two cases? The answer is at the bottom of this email. from Acquisition import Implicit class C(Implicit): pass root=C() root.a=C() root.a.b=C() root.a.b.c=C() root.x=C() root.x.y=C() root.x.y.z=C() print root.a.b.c.attribute print root.a.b.c.x.y.z.attribute 'attribute' is looked up in the orders c-b-a-root and z-y-x-root-a-b-c strange but true, Toby Dickenson
Toby Dickenson wrote:
With the rules as they are, an object can always rely on acquisition to source its containers first. Think of an object's containers as part of it's implementation, and the rules feel right.
[snip] Agreed, with one exception -- It feels decidedly *wrong* (to me, any way) to make wrappers for containers we are passing *out of*. Currently, the look-up order essentially traces the path back from the acquired object to the acquiring object and then back to the root via the original path. This is perfectly logical and consistent, based on the way acquisition is defined, but it screws up hierarchical overriding something fierce. In the example:
'attribute' is looked up in the order[...] z-y-x-root-a-b-c
because we go from c down to the root and then back up to z, and further acquisition retraces this path. I would *much* prefer the order z-y-x-root-c-b-a, since this doesn't turn our client's look-up order completely inside out, but I suppose passing the client to the acquired method and using it explicitly whenever we want to use its context is the Right Way to Do It. Any other plan won't avoid hitting the greatest common ancestor (root, in the example) too early (for the client) or too late (for the acquiree) to be correct. It's just so darn easy to get lazy and assume that acquisition will always do what you want it to without help.
At 03:29 30/09/99 , Toby Dickenson wrote:
I had been working with Zope for six months before realising that acquisition did not work that way already, and I was relieved. Maybe I can persuade you that it would be a bad thing.....
Welcome to the club =). It took me 7, so you beat me.
With the rules as they are, an object can always rely on acquisition to source its containers first. Think of an object's containers as part of it's implementation, and the rules feel right.
Under the rules suggested by Martjin, acquisition would source attributes from an object's customers in preference to its containers (As Jay wrote, the place where you acquired it _to_, rather than the place where you acquired it _from_). I don't think you could use that kind of acquistion to build a robust application, because of the unbounded number of potential clients each object might encounter. An object could never really rely on what it might pick up through acquisition.
Let's make one thing clear. No wait, make that two: 1/ My name is spelled Martijn. But that's obscure Dutch, so no offence taken =). 2/ I never suggested that the way I thought acquisition worked should be implemented that way. That was someone else. I adjusted my view, and solved my problem another way (or will, because I haven't had the time to implement it yet). In other words, I reached yet another level of Zen.
If you need that kind of wild flexibility then IMO it is better to explicitly pass it from the client object as a parameter, rather than asking it to be acquired from the client.
In my case that would seriously mess up my code. I found another, im my opinion much more beautiful solution. Instead of trying to override a default inclusion, I now provide a framework for that inclusion, but leave out the default. I then pick up on those cases where a default was expected (old URLs), and redirect to another URL where the framework has been provided in the acquisition path. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
On Thu, Sep 30, 1999 at 02:29:43AM +0100, Toby Dickenson wrote:
Paulo Eduardo Neves wrote:
"Jay R. Ashworth" wrote:
Got it. Then, I agree with the other folks. How can you override the context of the place where you acquired it _from_ with the context of the place where you acquired it _to_? That would seem to be a very important ability...
I had been working with Zope for six months before realising that acquisition did not work that way already, and I was relieved. Maybe I can persuade you that it would be a bad thing.....
With the rules as they are, an object can always rely on acquisition to source its containers first. Think of an object's containers as part of it's implementation, and the rules feel right.
Under the rules suggested by Martjin, acquisition would source attributes from an object's customers in preference to its containers (As Jay wrote, the place where you acquired it _to_, rather than the place where you acquired it _from_). I don't think you could use that kind of acquistion to build a robust application, because of the unbounded number of potential clients each object might encounter.
Ok, now I'm really confused. Acquisition differs from inheritance precisely _because_ what the acquirer "acquires" things from depends on where you _use_ it, rather than where you _created_ it, no? I think it's time for ASCII art. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
Hello, Is there a problem with naming a page using a period instead of the under score as in "index.html" instead of "index_html". I'm just thinking for somebody typing in the url the dot is the normal way and provides one less thing to remember. This would only be for the DTML Documents? Not the DTML Methods or anything else, and probably even just the end documents (in other words not the headers and footers). Thanks for the information, --James
On Fri, Oct 01, 1999 at 10:25:23AM -0700, James Punteney wrote:
Is there a problem with naming a page using a period instead of the under score as in "index.html" instead of "index_html".
Yes; it's poor user-interface architecture. See below.
I'm just thinking for somebody typing in the url the dot is the normal way and provides one less thing to remember.
Are you under the mistaken apprehension that _anyone_ _ever_ types "index.html" unless they're a) told to, or b) trying to be clever and look for a directory without one? No one should ever have to type the name of an "HTML file", IMAO -- not that there's such a thing anyway. In a traditional server environment, this would imply that there was no "index.html" -- which would mean that people could see lists of raw files that you might not want them to see -- probably not a Good Thing. Remember, knowing how to build a building is good. Being an architect is more difficult, but also more important. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
No one should ever have to type the name of an "HTML file", IMAO -- not
I probably should of used a different example than index.html and index_html, as many of you have pointed out those would never need to be typed in the url. What about other documents in the same folder that would be referenced with the page name? With Zope would you just create a new folder for each page? Thanks for the help, --James
James Punteney wrote:
No one should ever have to type the name of an "HTML file", IMAO -- not
I probably should of used a different example than index.html and index_html, as many of you have pointed out those would never need to be typed in the url. What about other documents in the same folder that would be referenced with the page name? With Zope would you just create a new folder for each page?
the problem with this as I understand is that zope/python use the . to reference the object hirearchy, like bob.surfs.net.here would referr to bob/surfs/net/here. you can indeed name objects with a period but if you use them in a python context you may have problems. otoh, for other documents, i find simply not having an extention works alright. perhaps better than the alphabet soup of .php3 .phtml .asp etc. -- ~mindlace
On Fri, 1 Oct 1999, Jay R. Ashworth wrote:
On Fri, Oct 01, 1999 at 10:25:23AM -0700, James Punteney wrote:
Is there a problem with naming a page using a period instead of the under score as in "index.html" instead of "index_html".
Yes; it's poor user-interface architecture. See below.
Are you under the mistaken apprehension that _anyone_ _ever_ types "index.html" unless they're a) told to, or b) trying to be clever and look for a directory without one?
However, if you are migrating a site to Zope, you might find your old users have managed to bookmark the 'index.html' pages and such (usually as a result of dodgy web server configuration or poor HTML coding). If you need to catch these cases, you just have to create a DTML method called 'index.html' at the root of your Zope tree, with the following contents: <dtml-var index_html> The magic of aquisition then takes care of the rest. More complex redirections should probably be done by running Zope behind another web server and using its rewrite functions (eg. *.html -> *, *.php -> * etc.). ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
On Sat, Oct 02, 1999 at 10:30:11AM +1000, Stuart 'Zen' Bishop wrote:
On Fri, 1 Oct 1999, Jay R. Ashworth wrote:
On Fri, Oct 01, 1999 at 10:25:23AM -0700, James Punteney wrote:
Is there a problem with naming a page using a period instead of the under score as in "index.html" instead of "index_html".
Yes; it's poor user-interface architecture. See below.
Are you under the mistaken apprehension that _anyone_ _ever_ types "index.html" unless they're a) told to, or b) trying to be clever and look for a directory without one?
However, if you are migrating a site to Zope, you might find your old users have managed to bookmark the 'index.html' pages and such (usually as a result of dodgy web server configuration or poor HTML coding).
Aw, hell. Good point, Stuart.
If you need to catch these cases, you just have to create a DTML method called 'index.html' at the root of your Zope tree, with the following contents: <dtml-var index_html>
Can you _do_ that without the . confusing Zope? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
participants (9)
-
Ethan Fremen -
Evan Simpson -
James Punteney -
Jay R. Ashworth -
Martijn Pieters -
Michel Pelletier -
Paulo Eduardo Neves -
Stuart 'Zen' Bishop -
Toby Dickenson