[Zope] - Yet another stupid question: image folders

[Christopher G. Petrilli]

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