December 1998 - Zope

RE: [Zope] - Yet another stupid question: image folders
by Jeffrey Shell 07 Dec '98

07 Dec '98

> I'm looking for an easy solution, BUT... for example, in Frontier, yo > ucan type something like: > > #image "blah.gif" > > And it will insert everything needed (including H/W tags). This works > even if you happen to have things stored in a subdirectory if I recall > (it's been a while). > > I know that most sites Zope has been used for probably aren't that > graphically intense, but a lot that I work on are, and I'd be > stuck with > nearly a billion of these refernces or writing custom code > that probably > is identical to other people's custom code. > > For the object repository to be useful, it has to be able to > SIMPLIFY my > life, not complicate it :-) This is a heavily double-edged sword, as we've found a few times ourselves. As you start to simplify too much, being able to use and re-use something in different situations becomes very difficult. On the other hand, if you make things too general, they become too hard to use. :/ > So since I'm a glutton for punishment, why wouldn't a tag: > >  But then you lose control over things like borders, javascript event handlers, imagemaps, style sheet properties, and all of the billions of combinations of tags. If you're doing a graphic intensive site, I would imagine that you would want finer control over your images and to be able to take advantage of HTML that Zope-Image developers can't keep up with. WebObjects is engineered for these types of dynamic widgets, Zope (like ActiveServerPages) isn't. So while you don't get a single-line #var insert, you do get tight control when you need it. For example, I've tried a few times to come up with a SELECT list tag that would select a value already given by the user. Sounds simple, right? Not with the flexibility I've often found myself yearning for (having to compare a possibly set value against one or two other lists coming from multiple sources and setting the presentation value and the widget value). The only major widget we have is the tree tag. And, while it brings incredible simplicity to generating hierarchical "tree" objects in HTML, there have been many times where it's grown with new parameters and more new parameters and even more new parameters to cover more and more of the different ways Trees needed to be rendered. Again, this is a fairly general-purpose widget. Specific widgets like images or select tags are tips of very very big icebergs.

2 1

- Updated win32 PYD files
by David Ascher 07 Dec '98

07 Dec '98

I've added the cPickleCache.pyd file to the unofficial win32 patches located at: http://www.zope.org/Download/Contrib --david ascher PS: I'd suggest to email me w/ win32-specific bug reports due to the use of said patch, instead of the main list (after all, Zope isn't supposed to work on Win32 yet =)

1 0

Re: [Zope] - Yet another stupid question: image folders
by Christopher G. Petrilli 07 Dec '98

07 Dec '98

On Mon, Dec 07, 1998 at 04:48:41PM -0500, Brian Lloyd wrote: > > I see what you're saying now. I think this boils down to > the usage of the __str__ method of Image objects: > > def __str__(self): > return '<IMG SRC="%s" ALT="%s">' % (self.__name__, > self.title_or_id()) Right this is what I was tweeking the other night trying to get this to work, but couldn't figure out how to find it's hierarchy. > I believe that this was added as a little convenience, > rather than a universally applicable thing. The problem here > is that you want (need) control over the SRC attribute. I would > suggest that it's better all around to simply use a bit of > DTML like: > > <img src="images/logo" alt="" > width="" ...> Maybe I'm lazy, but this seems like an AWEFUL lot of work that can't be automated by site tools (ney Dreamweaver), and that shouldn't be needed to be typed 5000 times when it's nearly always identical. I understand I'm looking for an easy solution, BUT... for example, in Frontier, yo ucan type something like: #image "blah.gif" And it will insert everything needed (including H/W tags). This works even if you happen to have things stored in a subdirectory if I recall (it's been a while). I know that most sites Zope has been used for probably aren't that graphically intense, but a lot that I work on are, and I'd be stuck with nearly a billion of these refernces or writing custom code that probably is identical to other people's custom code. For the object repository to be useful, it has to be able to SIMPLIFY my life, not complicate it :-) So since I'm a glutton for punishment, why wouldn't a tag:  Be allwoed to insert it's location in full, rathre than relative (which should never break anything I can thinik off off-hand), as well as it's ALT and H/W tags (which maybe should be stored in properties now that I think about it, and only updated when the image is inserted into the database/updated, lower overhead). Humor me here :-) Chris -- | Christopher Petrilli | petrilli(a)amber.org

3 3

Re: [Zope] - Document modification time
by Amos Latteier 07 Dec '98

07 Dec '98

At 03:36 PM 12/7/98, Kent wrote: >> I did this, and it doesn't update if I change the index_html document at >> all. In fact, it actually seems to have the date/time of the update of >> standard_html_footer, which isn't terribly useful :-) > >Actually, it depends... play with it a bit more and you will see even >more interesting behavior. :^) Part of the 'problem' is that it is >often hard to 'set' or determine what the object is that you are dealing >with. Is it an object or is it a method? Depends... If you think this >is interesting, just you wait. :^) :^) These sorts of issues will help >determine how you build your site. ... >> Am I asking the impossible? Also, it'd be nice to be able to figure out >> the last update time on a StructuredText document that was included with >> . I'd be happy with a solution >> that could scan through all the objects included and figure out which >> one was most recent. I agree that this is a bit of a problem. When you have Documents calling Documents its sometimes hard to keep things straight. Acquisition is part of the confusion, but I don't really think its the issue here. Basically you have an object docA calling another docB. The docB is told to execute a method that both it and docA implement. So it calls its own method. Really you would like to specify that it should call the method on DocA. This is hard to do, if you just specify the method name. I propose that there should be something analogous to the PARENTS list for Documents. Maybe is should be called CALLERS or DOCUMENTS or something. It should be a list of Documents, so that when index_html calls standard_html_header which calls mydoc, mydoc should be able do something like:  To call a method on index_html (the first CALLER). Thoughts? -Amos P.S. This facility would make the view dtml source widget on the Zope site work, as well :-)

2 2

Re: [Zope] - Yet another stupid question: image folders
by kent＠eaenki.nde.swri.edu 07 Dec '98

07 Dec '98

Hi Christopher (Christopher G. Petrilli), in <19981207162136.27260(a)amber.org> on Dec 7 you wrote: > So I was sitting and breaking things last night (between the shower > thoughts on FTp access, etc), and tried what seemed obvious to me, which > is probably totally wrong given my inexperience with BoboPOS, but... > > What I want to be able to do is have a folder that contains images as a > subfolder to my current folder. Now I know I can reference them, no > problem:  but that doesn't give the right SRC= > line in the IMG directive. Now I sat and thought about this, but I'm > just not sure how an image is supposed to find itself in the hierarchy > so it can publish the right URL to find itself.  calls images.logo and attempts to insert the return result into the page. Simply do it like a normal html img src, without the dtml var. > A simple solution would be for it to find itself and publish an absolute > location, rather than relative (as it currently does), but that means it > has to know wher eti is... It can be relative or absolute, just as with a normal html document. Maybe I'm missing the point... > Should I stop beating myself over the head yet? Yes, and help me write the Multi-Part Document Product, part of which was intended to help solve associated problems (and a shot at anchor cross-referencing in general also. :^) Kent.

1 0