Are there Graphic Designers?
Hello everyone, as we are moving forward developing Zope 3 with large steps, it becomes more and more desirable to think about a nice frontend (ZMI) for Zope 3. However the skill set of the developers currently working on Zope 3 does not include good graphics design skills. For this reason the development team is looking for one to two good graphic artists who would like to work on the look and feel of the new Zope version. Since it is fully developed from scratch, there are almost no restrictions, other than: It has to be functional. Are there any takers? Regards, Stephan PS: I am sorry about the cross posts, but I think this is a Zope-Dev/Zope3-Dev message with an audiance mostly found on the Zope Mailing List. -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management
On Thu, Apr 04, 2002 at 03:05:39PM -0600, Stephan Richter wrote: (snip)
Are there any takers?
Not me, but as a likely zope 3 "user" I'd like to insist that you should be looking for a good interface designer, not just a good graphic designer. If I had a dime for every application (web or otherwise) that was pretty, elegant-looking, and a total pain in the butt to use... --PW
Here is the output of a test dtml document, and the source, that demonstrates that setting keys of REQUEST inside a <dtml-with REQUEST> does not work. Is dtml designed to misbehave this way, or is it a bug? Is the <dtml-with REQUEST> superfluous? Why does it change the behavior of setting keys? Is there any way to work around the problem? Thanks! -Don test This is the test Document. Foo should be "one", and is "one". Foo should be "two", and is "two". Foo should be "three", and is "three". HOWEVER: Foo is now "three". Foo should be "one", and is "three". Foo should be "two", and is "three". Foo should be "three", and is "three". BUT THEN: Foo is now "three". Foo should be "one", and is "one". Foo should be "two", and is "two". Foo should be "three", and is "three". <dtml-var standard_html_header> <h2><dtml-var title_or_id></h2> <p> This is the <dtml-var id> Document. </p> <dtml-call expr="REQUEST.set('foo', 'one')"> Foo should be "one", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'two')"> Foo should be "two", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'three')"> Foo should be "three", and is "&dtml-foo;".<br> <p>HOWEVER:<p> <dtml-with REQUEST> Foo is now "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'one')"> Foo should be "one", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'two')"> Foo should be "two", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'three')"> Foo should be "three", and is "&dtml-foo;".<br> </dtml-with> <p>BUT THEN:<p> Foo is now "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'one')"> Foo should be "one", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'two')"> Foo should be "two", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'three')"> Foo should be "three", and is "&dtml-foo;".<br> <dtml-var standard_html_footer>
Don Hopkins wrote:
Here is the output of a test dtml document, and the source, that demonstrates that setting keys of REQUEST inside a <dtml-with REQUEST> does not work. Is dtml designed to misbehave this way, or is it a bug? Is the <dtml-with REQUEST> superfluous? Why does it change the behavior of setting keys? Is there any way to work around the problem? Thanks!
-Don
test This is the test Document.
Foo should be "one", and is "one". Foo should be "two", and is "two". Foo should be "three", and is "three".
HOWEVER:
Foo is now "three". Foo should be "one", and is "three". Foo should be "two", and is "three". Foo should be "three", and is "three".
BUT THEN:
Foo is now "three". Foo should be "one", and is "one". Foo should be "two", and is "two". Foo should be "three", and is "three".
<dtml-var standard_html_header> <h2><dtml-var title_or_id></h2> <p> This is the <dtml-var id> Document. </p>
<dtml-call expr="REQUEST.set('foo', 'one')"> Foo should be "one", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'two')"> Foo should be "two", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'three')"> Foo should be "three", and is "&dtml-foo;".<br>
<p>HOWEVER:<p>
<dtml-with REQUEST>
Foo is now "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'one')"> Foo should be "one", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'two')"> Foo should be "two", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'three')"> Foo should be "three", and is "&dtml-foo;".<br>
</dtml-with>
<p>BUT THEN:<p>
Foo is now "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'one')"> Foo should be "one", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'two')"> Foo should be "two", and is "&dtml-foo;".<br> <dtml-call expr="REQUEST.set('foo', 'three')"> Foo should be "three", and is "&dtml-foo;".<br>
<dtml-var standard_html_footer>
There is a stack of namespaces to resolve names into objects. initially: --------------------------------------------> growth REQUEST {'foo':...} But after the dtml-with REQUEST you'll have --------------------------------------------> growth REQUEST ! {'foo':.... } {'foo':...} ! the with pushes (the content of) REQUEST onto the namespace, but: REQUEST does not contain itself!! Therefore, call REQUEST.set('foo', ) will touch the 'foo'-object at the bottom, while name resolution will find the topmost 'foo' first. As i understand Python, initially both 'foo's point to the same object, but asssigning to the topmost 'foo'-object will BIND another value to it and does not affect the bottom 'foo'-object inside dtml-with. Also note, that dtml-with has an additional attribute "only", which limits the depth of name lookup. -- ------------------------------------------------------------- Who's got only a hammer sees the world as a nail hans augustin (software developer) hans@beehive.de beehive elektronische medien GmbH http://www.beehive.de phone: +49 30 847-82 0 fax: +49 30 847-82 299
Don Hopkins writes:
... wrong value shown inside "<dtml-with REQUEST>" ...
I have a work around for you: <dtml-with REQUEST mapping> will work as expected. However, I do not understand this behaviour: The difference between "<dtml-with REQUEST>" and "<dtml-with REQUEST mapping>" is that in the first case "REQUEST" is wrapped into an "InstanceDict" before it is pushed onto the namespace while in the second case it is pushed itself (unwrapped). "InstanceDict" is a wrapper that maps "getitem" onto the wrapped object's "getattr". But, because "REQUEST" maps its "getattr" to its "getitem", there should not be a big difference. Should, as you see there is one.... I may look more closely into this tomorrow. Dieter
Don Hopkins recently found that "REQUEST.set" does not work as expected inside "<dtml-with REQUEST>". I replied:
Don Hopkins writes:
... wrong value shown inside "<dtml-with REQUEST>" ...
I have a work around for you:
<dtml-with REQUEST mapping>
will work as expected.
However, I do not understand this behaviour:
The difference between "<dtml-with REQUEST>" and "<dtml-with REQUEST mapping>" is that in the first case "REQUEST" is wrapped into an "InstanceDict" before it is pushed onto the namespace while in the second case it is pushed itself (unwrapped).
"InstanceDict" is a wrapper that maps "getitem" onto the wrapped object's "getattr".
But, because "REQUEST" maps its "getattr" to its "getitem", there should not be a big difference. Should, as you see there is one....
I now do understand the behaviour: "InstanceDict" instances are caching the values they returned! This has wide ramifications, for example: * "REQUEST.set" apparently ineffective inside "dtml-with REQUEST" (as Don found out) * modifications to properties apparently ineffective I am no longer sure, I should consider this a bug (as I did in the previous message). But at least, it requires a big warning sign in the Zope book and other DTML related documentation. That's the reason, I send this message to you, too, Chris. Dieter
participants (5)
-
Dieter Maurer -
Don Hopkins -
hans -
Paul Winkler -
Stephan Richter