RE: [Zope] - Yet another stupid question: image folders
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:
<!--#var imagename-->
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.
On Mon, Dec 07, 1998 at 05:16:35PM -0500, Jeffrey Shell wrote:
[I commit some for of heresay]
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. :/
Nobody has said that you couldn't use a more complicated solution WHEN you need it, have they? I'm just trying to account for what in my life is 90% of the solution.
So since I'm a glutton for punishment, why wouldn't a tag:
<!--#var imagename-->
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).
I agree totally, BUT I also fin that I use a HUGE number of images without these things being controlled in the detail. Just because a facility is provided for a simple case (a'la <!--#var image--> doesn't mean you can't use the more complicated solutions that have been proposed. But is there some reason this is a BAD idea for a case when in my life seems to be WAY into the majority.
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.
I don't see how continuing the concept of an object publishing itself is so foreign. I'm not asking for 5,000 add-ons, I'm asking for a simple solution to a common problem, that quite honestly occurs on average anywhere from 3-10 times in a page, and it'd seem stupid to have to custom write code for the "normal" case. As another person pointed out (bad attribution), the current situation doesn't help with caching either, if an object knows where it is, then it should gives it's NORMAL location, and not be rerferenced via its acquisitional location. These are dynamic pages, not static, so when a new obnject is placed in the path and found instead of the original, it should be published as such, and not as the other one. In fact, the current situation I think, could exadurate caching problems in this situation. Don't get me wrong I think this is a great starting point, but I also think that all projects have a LONG way to go. Chris -- | Christopher Petrilli | petrilli@amber.org
participants (2)
-
Christopher G. Petrilli -
Jeffrey Shell