On Fri, 7 Nov 2003, David Forslund wrote: ... > >http, https. > > What if I want to use another protocol? URIs allow for a variety > of protocols.
Dave, vanilla Zope also supports ftp - for an overview of Zope architecture, this may help: http://zope.org/Documentation/Books/ZopeBook/2_6Edition/ZopeArchitecture.stx ... > >We can have: > > uri_to_this_object/help or > > uri_to_this_method/help to give the API documentation. > > I tried this on your site and just get an error back that it can't find > what I'm asking for. That's because those objects do not have a defined "help" method. ... > > > As I said earlier a URI is not sufficient to invoke a class. ... > Most of the work in my web application is not done with method > calls from a browser. Sending a "get" request on an URI necessarily initiates at least one method call on the server. There are many other ways to invoke methods: Whether these other methods are logically equivalent to invoking an URL is where Zope differs from Java. With Zope, every Zope object has an URI - thus, conveniently, invoking any Zope object is equivalent to invoking its URI. ... > > > >For example: > > > > > > > >http://www.txoutcome.org/scripts/zope/library/files/browse/show_content > > s/objectid-244 ... > Is there more than one way to look at it? > Isn't the object well-defined? The object is well-defined. However, from the point of view of the calling agent, the object definition is opaque except for whatever is intentionally exposed (e.g. via a "help" method). > How do I tell what is the object and what isn't? Does it matter? That is precisely the point. Everything is an object - and you need to query the object to know its "type", interface, methods, etc. ... > How do I know what it is that I get back. It seems in the examples you give > it is always html. Is it right to assume this doesn't have to be the case? Well, you always get a file back. What else can it be? It does not have to be a text file - but the popular thing is to return a text file. Conveniently, the text file can have tagged content - typically HTML - but does not have to be HTML. ... > >You are thinking of "type" in an overly narrow way. Just because a http > >request generates a "text document" (web page) response does not mean the > >"text document" cannot embed descriptions of fancier "type" or "types". > > How am I to know what to do with the data that comes back? Since you initiated the call, you must have some intentionality. If the calling application seeks the current share price of IBM stock, for example, then the calling application will have to decide what to do with the returned value. It is also possible for the data to come back bundled with code to display it etc. But that's entirely another discussion. > Who decides? End User? > How am I to interpret the text document that comes back? Display it to the End User or Assign it to a variable and make sure it is not an error code? > I think I have the same problem with XML unless the documents are ones I > "recognize". It really doesn't matter how the returned value is represented - binary, text, XML, whatever. Either a human or some code must try to "recognize" it and further process it. Zope does not change this part of the procedure. ... > There are no real types on a web page. It is all text. I think you expressed a too narrow view of what constitutes "real types". As all object classes are "types", the "table" tag popularly employed on web pages represents an "object class" - and thus qualifies as a "type". ... > How am I to know what the correct syntax or arguments are? Documentation? > Is the help method you cite required in an implementation? No, it is optional (I just made up the example). :-) > > > Is everything just typed ascii or text? > > > >Text is the basic type - think in terms of parameter passing via URL. We > >construct arbitrarily complex types from text, think in terms of XML. > > Does Zope understand XML? http://www.zope.org/Members/Amos/XML-RPC > Can I query a ZODB with XPath, for example? http://zope.org/Wikis/zope-xml/XPath ... > >Click on "Add a Sub-Folder" or "Add a New Project". > > That isn't a method; that is a piece of html which sends a message to the > server. It is absolutely a method. The nice HTML form just reminds human user/programmers to provide the correct arguments!!! :-) > If I have to write html code to have my database populated and managed, there > is no hope of having high performance in the database. You are still confusing the documentation / user-interface with the invocation of Zope methods. I can certainly write a method that directly calls the SQLMethod that inserts rows into database table(s) without any HTML at all. However, it would be harder to show you / demo that method to you without the nice HTML-frontend. Here it is: http://www.txoutcome.org/scripts/zope/library/files/browse/newfolder/newfolder_b with argument list: name, description, submitter, keywords, links, objectid, origin ... > >Herein lies the innovation achieved by Zope - why do you insist on seeing > >the python call in-the-raw? What's wrong with working with a nice, > >integrated user/programming interface? with --> No complex and cryptic > >calling convention - just URL.. > > This is basically the point the the REST approach to the Web. I think > you might be interested in Roy Fieldings dissertation on this subject: > > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Makes sense - especially the last section: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2 It even compares HTTP to CORBA. > I think you have a common approach. I think it is great for web presentation > and interaction, but is not how one would build a service on the back end > with a lot of functionality, without it becoming incredibly complex. Zope does provide syntactical abbreviations and short-cuts for calling local objects residing in the same Zope instance. No need to be unnecessarily redundant when specifying the URI, if that's what you are concerned about. ... > We find that a large fraction of coding errors are caught in Java at > compile time. Zope does catch syntax errors at the time that code is saved. ... > > > It means I have to write code for any eventuality on the server side, > > > >Not true, Zope knows how to generate error messages :-). > > What if the data looks ok but is actually not intended for the object > invoked? When does the error message get invoked? How do I > even know there is an error? What if I want to get data > back in something other than html? How do I know what form of > the data the client wants? Zope does not offer any magic solutions to these. If the Client has any special needs, it has to tell the Server. If the Server can honor the special needs, then the Client will get the right data back - otherwise, an error message. The Client can have code to check the returned data for quality/correctness - however, there are theoretical limits to this, namely: If the Client knows what data it should get, why does it have to ask the Server? I would be most interested if CORBA or Java offers something special / magical with regards to this. ... > really like this approach, but I think it leads to unmanageable applications. If we think of the WWW as an application, it seems to work adequately. ... > But perhaps that is a wrong impression, because I don't understand what > it is trying to do. Trying to model web-applications with traditional programming framework (of classes, methods, types) is not easy. This is largely because the native "objects" (=types) in traditional programming frameworks are wrong for web-applications. This mismatch causes traditional programming frameworks to be quite inefficent for building web-applications, compared to Zope. When I finally understood enough about Zope, web-application development became quite easy. Just like all programming tasks, it is all about using the right tool for the job. I wrote a "Hello World" program in Zope for a session at the GCRC annual meeting last year. We were making comparisons between Zope and Coldfusion. It took me 5 seconds to produce and demonstrate the "Hello World" web-application via Zope. Maybe the extra complexity and extra work involved in implementing the same application in Java and CORBA gives some real benefits. On the other hand, maybe it is just extra complexity and extra work wasted or worse. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
