Hi there, Recently I've had an idea. Problem description: I'm sure lots of people will recognize this. The root folder fills up with lots and lots and lots of methods; both factored HTML layout components and methods that should apply to all subfolders. Ideally you'd want to put this stuff in subfolders. But you run into the following problem: acquisition works no more. That is, acquisition works, but to override any specific layout component that's in a subfolder, you need to override the entire subfolder and copy over *all* layout elements. That's not what we want. I haven't seen an easy solution to this problem yet, unless I'm missing something. Analysis: So, why do you want to use folders at all? To compartementalize the system so we can easily find stuff. To avoid long lists of methods in the root folder. But proper folders hurt acquisition, so.. Solution: We need a new type of folder, the 'transparent' or 'virtual' folder. If we have a folder 'folder', and a subfolder 'sub', and sub is a transparent folder, anything we place in 'sub' is actually in 'folder' as well. It'll be acquired. It can be overridden (either in a subfolder of the same name, or in the folder that's doing that acquiring directly). This way, we get to compartementalize things while keeping the benefits of acquisition. Actually, this idea could have deep consequences, as it's getting very close to (multiple) inheritance. That is, if you put a transparent folder in your folder, it's like saying the current folder inherits from that transparent folder. Perhaps transparent folders could then also be generalized for a new type of ZClass inheritance that may or may not be easier to manage than the current system. Imagine being able to drop a transparent folder in your ZClass to make it inherit the methods in that transparent folder. ZClass inheritance needs an extra bit, though; the ability to make a 'reference' transparent folder that does not have actual methods inside itself, but just refers to some other ZClass (or Python base class, or whatever). Let's just stick to my original transparent folder idea for now, keeping all this inheritance zen in mind for later. My questions are: * is this a good idea at all? Any disastrous complications or consequences? * is this technically feasible? Regards, Martijn
Hi Martijn, Great idea!!! Tom. At 15:10 27/04/2000 +0200, Martijn Faassen wrote:
Hi there,
Recently I've had an idea.
Problem description:
I'm sure lots of people will recognize this.
The root folder fills up with lots and lots and lots of methods; both factored HTML layout components and methods that should apply to all subfolders.
Ideally you'd want to put this stuff in subfolders. But you run into the following problem: acquisition works no more. That is, acquisition works, but to override any specific layout component that's in a subfolder, you need to override the entire subfolder and copy over *all* layout elements. That's not what we want. I haven't seen an easy solution to this problem yet, unless I'm missing something.
Analysis:
So, why do you want to use folders at all? To compartementalize the system so we can easily find stuff. To avoid long lists of methods in the root folder. But proper folders hurt acquisition, so..
Solution:
We need a new type of folder, the 'transparent' or 'virtual' folder. If we have a folder 'folder', and a subfolder 'sub', and sub is a transparent folder, anything we place in 'sub' is actually in 'folder' as well. It'll be acquired. It can be overridden (either in a subfolder of the same name, or in the folder that's doing that acquiring directly).
This way, we get to compartementalize things while keeping the benefits of acquisition.
Actually, this idea could have deep consequences, as it's getting very close to (multiple) inheritance. That is, if you put a transparent folder in your folder, it's like saying the current folder inherits from that transparent folder.
Perhaps transparent folders could then also be generalized for a new type of ZClass inheritance that may or may not be easier to manage than the current system. Imagine being able to drop a transparent folder in your ZClass to make it inherit the methods in that transparent folder. ZClass inheritance needs an extra bit, though; the ability to make a 'reference' transparent folder that does not have actual methods inside itself, but just refers to some other ZClass (or Python base class, or whatever).
Let's just stick to my original transparent folder idea for now, keeping all this inheritance zen in mind for later. My questions are:
* is this a good idea at all? Any disastrous complications or consequences?
* is this technically feasible?
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
"Morten W. Petersen" wrote:
Hi Martijn,
Great idea!!!
I'll second that. This would be sweet.
I am also interested in the Transparent Folders idea and decided to create a prototype. It's almost ready. It's just something to experiment with, because right now it slows down Zope by a factor of 50% or so! Shane
Shane Hathaway wrote:
I am also interested in the Transparent Folders idea and decided to create a prototype. It's almost ready. It's just something to experiment with, because right now it slows down Zope by a factor of 50% or so!
Wow! Wild, I think I'll mention some of my ideas here more often. :) What does it do that slows down Zope so much? Regards, Martijn
Martijn Faassen wrote:
Shane Hathaway wrote:
I am also interested in the Transparent Folders idea and decided to create a prototype. It's almost ready. It's just something to experiment with, because right now it slows down Zope by a factor of 50% or so!
Wow! Wild, I think I'll mention some of my ideas here more often. :)
What does it do that slows down Zope so much?
It puts a Python wrapper around the basic machinery that gets an attribute from a folder--not just folders that contain transparent folders, but *all* folders. There are a few ways to fix that, and we may want to discuss them. But for now, try out the product and see if it does what it's supposed to do. I got interested in the idea because the concept of symbolic links in a Zope tree has a lot of merit but could hamper speed and security. Transparent folders combined with acquisition, on the other hand, have similar benefits, are easier to implement, and have the potential to be quite fast (faster than standard acquisition--though a rewrite will be necessary to achieve good speed.) BTW I didn't bother to prevent the case of inheritance from multiple level transparent folders. I want to find out whether that's an issue or not through trial and error. Shane
Martijn:
Recently I've had an idea.
Excellent.
Ideally you'd want to put this stuff in subfolders. But you run into the following problem: acquisition works no more. That is, acquisition works, but to override any specific layout component that's in a subfolder, you need to override the entire subfolder and copy over *all* layout elements.
Yes it's a problem I have encountered. I have been forced to let the site get unorganized in order to take advantage of acquisition. However, for layout, I have started uwins a UIClass ZClass that my objects inherit from and I can reuse my code, so I don't have that problem as much anymore.
Analysis:
So, why do you want to use folders at all? To compartementalize the system so we can easily find stuff. To avoid long lists of methods in the root folder. But proper folders hurt acquisition, so..
Solution:
We need a new type of folder, the 'transparent' or 'virtual' folder. If we have a folder 'folder', and a subfolder 'sub', and sub is a transparent folder, anything we place in 'sub' is actually in 'folder' as well. It'll be acquired. It can be overridden (either in a subfolder of the same name, or in the folder that's doing that acquiring directly).
This way, we get to compartementalize things while keeping the benefits of acquisition.
<snip>
* is this a good idea at all? Any disastrous complications or consequences?
* is this technically feasible?
I think developing a new class to organize things with a "management interface" focus is taking a step backwards. The physical location of an item is important because of aquisition. But the *physical* location of an item is not important to organization. I think that the two should be kept separate. The Catalog allows you to manage items (very clunky) regardless of their location. You could very easily group those items for organization without effecting their physical place in the hirearchy. This goes along with establishing object relationships that are not 2 dimensional(hirearchy), but multi-dimensional(those 'relationships' or 'links' that pop up on the list every month or so). I truely think that physical location shouldn't be the only effect on aquisition. 2 cents gingles in the jar. All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 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.
Jason Spisak wrote:
Martijn:
Recently I've had an idea. Excellent.
Happens all the time, really. :) [snip]
I think developing a new class to organize things with a "management interface" focus is taking a step backwards.
Why is this 'management interface' focus, though? Obviously we construct our site through the management interface. But the transparent folder would not be something of the management interface; it's a new way to organize objects.
The physical location of an item is important because of aquisition. But the *physical* location of an item is not important to organization.
I happen to disagree. I think the location of an item in the folder tree is important to site organization. (I don't think the word 'physical' makes much sense in a situation where we have abstractions heaped upon abstractions already; a file is an abstraction, the object database is an abstraction, the tree is an abstraction, and then the catalog is an abstraction too :).
I think that the two should be kept separate.
But they're not. If they are to be kept seperate, why organize your objects into a folder tree at all? You could simply have a vast amount of unorganized objects with a catalog on top of it, and this would be perfect, right? Or do you say we only organize things in a tree for acquisition, and not because the site might look like a tree?
The Catalog allows you to manage items (very clunky) regardless of their location. You could very easily group those items for organization without effecting their physical place in the hirearchy.
I'm not sure I follow you here. How would this help with the acquisition and organization problem I mentioned? As far as I'm aware, you can't use the Catalog to 'pull' an object into a folder and let it be acquired, right? Even if it were possible, this would be clunkier than the transparent folder approach, though more powerful.
This goes along with establishing object relationships that are not 2 dimensional(hirearchy), but multi-dimensional(those 'relationships' or 'links' that pop up on the list every month or so). I truely think that physical location shouldn't be the only effect on aquisition.
Right, and wasn't I proposing something to deal with that exactly? I agree that somekind of 'reference' or 'soft link' system would be useful. But having such a system still would not solve the acquisition problem that I pointed out in my previous mail. You still end up with folders full of methods that are to be acquired. The transparent folder idea attempt to solve that. If you then add references, that would be useful for even more organization, later, in *combination* with transparent folders. You can then pull in objects into a folder from somewhere else completely; you can share the same sets of layout components across multiple independent trees, etc. In combination with ZClasses, it'd allow you to easily change the base classes of a ZClass. A smart kind of reference may even bring ZClasses outside the Product screen entirely, into the main tree. Define a ZClass for just one particular subtree, etc. Anyway, that's all speculation. I haven't understood yet what you think is wrong with the 'transparent folder' proposal. It seems orthogonal with what you're proposing, if I understand you right. Regards, Martijn
Martijn Faassen wrote:
Hi there,
Recently I've had an idea.
Problem description:
I'm sure lots of people will recognize this.
The root folder fills up with lots and lots and lots of methods; both factored HTML layout components and methods that should apply to all subfolders.
Right.
Ideally you'd want to put this stuff in subfolders. But you run into the following problem: acquisition works no more. That is, acquisition works, but to override any specific layout component that's in a subfolder, you need to override the entire subfolder and copy over *all* layout elements.
Ya lost me right there, where is there a copy involved? Why can't you put your Foo layout components in a FooLayout folder in the root folder and say: <dtml-with FooLayout></dtml-with> When you want to use them? The only downside of this from your approach is that it's not 'transparent'. But otherwise what you are proposing does make sense, I'm getting the impression of 'overlaying' various folder namespaces while keeping their organziational structure. Ok, some questions. What happens when a transparent folder 'A' contains a tranparent folder 'B'? So 'B' contains the object 'Foo' which you try to access from some completly different location. It is not found in the root folder, how is 'A' searched? Are all transparent folders in a container searched in a linear fashion? Does 'B' get descended into when A doesn't contain Foo? This begins to sound like an expensive recursive lookup unless a transparent folder plays with the namespace of its container, but then I think you run into a whole other slew of problems, like why Zope complains to newbie eyes that the id 'Foo' exists when it clearly doesn't in the root folder (oops, gotta look in A/B!, but if there's lots of these transparent folders, you're lost). What if both A and B contain a 'Foo'? Is B's Foo ever visible to anyone other than explicitly? -Michel
Michel Pelletier wrote:
you need to override the entire subfolder and copy over *all* layout elements.
Ya lost me right there, where is there a copy involved? Why can't you put your Foo layout components in a FooLayout folder in the root folder and say:
<dtml-with FooLayout></dtml-with>
When you want to use them?
You can't exploit acquisition so easily then. You can use a FooLayout folder. Now you suddenly (for some bizarre reason) want to support a Dutch version of the site in some seperate subtree, with different texts, images, and so on. But not *everything* is replaced. You want to change some of the stuff in FooLayout, for instance 'header_html', but not all of it. I can't simply reate my own FooLayout in /dutch, and put my own header_html there. I'd need to copy over *everything* from FooLayout to make that work. Of course there are some ways around that, but they all seem to be a hassle compared to what's possible with acquisition.
The only downside of this from your approach is that it's not 'transparent'.
Does this mean you understood what I meant already? That was the downside I was trying to solve. :)
But otherwise what you are proposing does make sense, I'm getting the impression of 'overlaying' various folder namespaces while keeping their organziational structure.
Right. That's another way to look at it. It's quite analogous to inheritance, except that the base classes are defined 'inline'.
Ok, some questions.
What happens when a transparent folder 'A' contains a tranparent folder 'B'?
So 'B' contains the object 'Foo' which you try to access from some completly different location. It is not found in the root folder, how is 'A' searched? Are all transparent folders in a container searched in a linear fashion? Does 'B' get descended into when A doesn't contain Foo? This begins to sound like an expensive recursive lookup
True. I don't know the fine details of the acquisition machinery, but presumably there's somekind of 'expensive recursive lookup' involved at some point too. Would this increase the expense that much compared to the current situation? (Ignoring the fact that much of acquisition happens in C)
unless a transparent folder plays with the namespace of its container, but then I think you run into a whole other slew of problems,
Probably. :)
like why Zope complains to newbie eyes that the id 'Foo' exists when it clearly doesn't in the root folder (oops, gotta look in A/B!, but if there's lots of these transparent folders, you're lost).
Right. You could work around that with error reporting, perhaps, but that'd be a pain. Better behavior would be that 'Foo' in the root folder simply overrides any other Foo's in A or B. I think you can make the playing with the container's namespace smart enough to do that. Not that it still wouldn't be tricky. We haven't even thought about any security implications yet, for instance.
What if both A and B contain a 'Foo'? Is B's Foo ever visible to anyone other than explicitly?
Yes; A's Foo would be found. Another question that I *can't* answer is what if I have transfolders C and D, and they both contain Foo. Which one gets found? This is analogous to what can happen in multiple inheritance in Python, but it's less clear what the order of depth first search in Zope is. Thanks for your comments. Very useful. Regards, Martijn
<entire useful discussion of "Transparent Folders" snipped :) > Butch Landingin proposed (and coded!) a class called ContextBase. You can check it out here: http://squishdot.org/948790303/index_html It's a bit different from what you're asking for, but it's straightforward and flexible on an instance-by-instance basis. Kevin
Scavenging the mail folder uncovered Martijn Faassen's letter:
Michel Pelletier wrote:
you need to override the entire subfolder and copy over *all* layout elements.
Ya lost me right there, where is there a copy involved? Why can't you put your Foo layout components in a FooLayout folder in the root folder and say:
<dtml-with FooLayout></dtml-with>
When you want to use them?
You can't exploit acquisition so easily then. You can use a FooLayout folder. Now you suddenly (for some bizarre reason) want to support a Dutch version of the site in some seperate subtree, with different texts, images, and so on. But not *everything* is replaced. You want to change some of the stuff in FooLayout, for instance 'header_html', but not all of it. I can't simply reate my own FooLayout in /dutch, and put my own header_html there. I'd need to copy over *everything* from FooLayout to make that work.
Of course there are some ways around that, but they all seem to be a hassle compared to what's possible with acquisition.
use the Translator product. it lets you acquire (trasparently) from different folders based on the value of the HTTP_ACCEPTED_LANGUAGES header or of a cookie of your choice. or use the ChamelonFolder product (more generic.) but the ability to have transparent folders would be great. no more 2 or 3 dtml-with at the start of every page just to keep the root folder clean... ciao, federico -- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org A short story: I want you. I love you. I'll miss you. -- Me
Hi! On Thu, Apr 27, 2000 at 12:31:44PM -0700, Michel Pelletier wrote:
Martijn Faassen wrote:
Hi there,
Ya lost me right there, where is there a copy involved? Why can't you put your Foo layout components in a FooLayout folder in the root folder and say:
<dtml-with FooLayout></dtml-with>
When you want to use them? The only downside of this from your approach is that it's not 'transparent'.
I think "transparent" is better, as you can also do the sorting afterwards, e.g. when you think that it's now too full.. You wouldn't have to change every occurence of an object in the dtml code somewhere then.
But otherwise what you are proposing does make sense, I'm getting the impression of 'overlaying' various folder namespaces while keeping their organziational structure. Ok, some questions.
What happens when a transparent folder 'A' contains a tranparent folder 'B'?
Maybe this simply shouldn't be allowed.. ;-) At least then all the mentioned problems wouldn't occur.. -- christian
At 04:07 28/04/2000 +0200, Christian Scholz wrote:
Hi!
On Thu, Apr 27, 2000 at 12:31:44PM -0700, Michel Pelletier wrote:
Martijn Faassen wrote:
Hi there,
Ya lost me right there, where is there a copy involved? Why can't you put your Foo layout components in a FooLayout folder in the root folder and say:
<dtml-with FooLayout></dtml-with>
When you want to use them? The only downside of this from your approach is that it's not 'transparent'.
I think "transparent" is better, as you can also do the sorting afterwards, e.g. when you think that it's now too full.. You wouldn't have to change every occurence of an object in the dtml code somewhere then.
But otherwise what you are proposing does make sense, I'm getting the impression of 'overlaying' various folder namespaces while keeping their organziational structure. Ok, some questions.
What happens when a transparent folder 'A' contains a tranparent folder 'B'?
Maybe this simply shouldn't be allowed.. ;-) At least then all the mentioned problems wouldn't occur..
Yes, this shouldn't be allowed, i.e. a transparentfolder shouldn't be able to contain a folder or a transparantfolder (...). A transparentfolder is just something to ease the organisation of a certain node. Nothing more. Tom
participants (9)
-
cs＠comlounge.net -
fog＠mixadlive.com -
Jason Spisak -
Kevin Dangoor -
Martijn Faassen -
Michel Pelletier -
Morten W. Petersen -
Shane Hathaway -
Tom Deprez