Re: [Zope-dev] Re: [Zope3-dev] Are there Graphic Designers?
From: Gary Poster [EMAIL PROTECTED] I agree that we ought to trash frames we ought to use strict xhtml 1.0 we ought to rely on CSS for all graphic elements (correlative) we ought to not use *any* shims or non-logical tables the site ought to work completely without JS or Flash the site ought to be usable and legible without any CSS I disagree that we ought to use iframes (why lock out NS4 if we don't have to?) we ought to avoid Flash like the plague (see my XML file tree email) this shouldn't be the default skin (it *should*) I further feel that it would be very easy to develop a CSS file folder that one could place in a skin that would deliver different CSS files based on browser-sniffing. The CSS could be cached by the browser if we always call it from the same Hmm... If only someone had thought of that, say about a year ago. ( http://www.zope.org/Members/haqa/ZStyleSheet ) My question is this: Everyone is saying The ZMI is bad, it's confusing, users don't like it. Could anyone show me evidence of this? Personally I love the ZMI in the current versions. I have also found there is a negligable learning curve for users who already know how to use Windows Explorer and similar products. I just don't see the need to throw out the ZMI - Are we in a baby/bathwater situation here? address. While CSS support varies widely in all the various browsers, and I think we should *ship* with a CSS file that requires a standards-compliant browser such as those that Toby lists, I see *no reason* why we should design the html itself so that a NS4 user could not use the default skin simply by building him or her a new CSS file. It might not look nearly as slick as the compliant browsers, but you can still do some reasonable things with NS4 only... ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [Zope] isecure XML-RPC handling.
* the immediate correspondence between the request and the response containing essential information to analyse the problem It's application problem and the application have to handle it. Log all the request/responses on the server or the client side. * newbies They have nothing to do in a production environment don't they? Even with the stack trace immediately in the response, they report problems with no or missing essential details about the problem. Then how one can help there? This will become worse when the error information is hidden in a log. The point is that production differ from development environment. In the development environment on can do whatever he needs. In a production environment reporting information as physical path on the server, internal network addresses etc. is unexceptable. Look at it from a different prospective: Someone is browsing Internet and a site is responding like: Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword 'or'. /login.asp, line 11 Couple scenarios: 1. If he is a regular user he will go to the next site and most probably will never come back to that site again. 2. If he is tester or developer - oops the code have problem we have to fix it. 3. If he is intruder then Bingo! the site have problems escaping special characters before to pass them to the SQL server! Let's have a party! The situation with Zope is similar. Shall the dump help the regular surfer? I doubt so. Shall it benefit the developer or the tester? Most probably not since they are not performing their activities on the production site. Shall it benefit third parity developers that are requesting services from you site? May be particular, since they can report the stack to you, but you may get that information from you log any way. Since they can not control the code on you side this will not make their live easier.. The only left is the intruder! The conclusion is make the server not to dump the stack in the response if -D option does not imply. With -D dump the processor registers if you would like ;) People have to be able to control this and if there is more precise control like debug level - then it is even better. BW if a program is expecting XML-RPC response but it is receiving stack trace it may be a little confusing (especially for a not so well written program ;). Zope first have to conform the protocol for XML-RPC exchange (return XML response) and after that to sweet the developers (dump error in the server's log). Okay! Dieter Regards, Rossen _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [Zope] isecure XML-RPC handling.
From: Rossen Raykov [EMAIL PROTECTED] Shall the dump help the regular surfer? I doubt so. Shall it benefit the developer or the tester? Most probably not since they are not performing their activities on the production site. Oh, they most definitely help the developer or tester, because errors do appear on production sites too, and it can be very hard to recreate the problem. BUT: The developer has access to the system, and the dump doesn't have to be included in the HTML output. Maybe error dumps could be sent to a disk-log of some sort? ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [Zope] isecure XML-RPC handling.
Shall the dump help the regular surfer? I doubt so. Shall it benefit the developer or the tester? Most probably not since they are not performing their activities on the production site. Oh, they most definitely help the developer or tester, because errors do appear on production sites too, and it can be very hard to recreate the problem. The only one problem there is that if a surfer sees the dump most probably he will not send it to the developer BUT: The developer has access to the system, and the dump doesn't have to be included in the HTML output. Maybe error dumps could be sent to a disk-log of some sort? Exactly that's my point. Log it with as many details as you can! Log it on the local file system or use syslog or a database but do not send it to the users browser. Do not put it in the response if the server is running without -D option. Regards, Rossen _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [Zope] isecure XML-RPC handling.
On Sat, 6 Apr 2002, Rossen Raykov wrote: BUT: The developer has access to the system, and the dump doesn't have to be included in the HTML output. Maybe error dumps could be sent to a disk-log of some sort? Exactly that's my point. Log it with as many details as you can! From what he says, Shane's new better tracebacks code, which I believe will be in 2.6, does the equivalent of this. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
