Is there any prospect of some form of friendlier developer GUI to Zope, perhaps a Java client. Features such as Syntax highlighting of DTML, and a better error description system, would greatly enhance the ease of use of Zope. Further, such a system would not need to replace the present HTML interface, but could be used optionally. I may be showing my newbieness here, but I guess a good first step might be a Java conduit to the Zope database - perhaps one already exists.
I am not knocking the hard work that developers have put into the system, however I suspect these are the questions that many Zope newbies will be asking.
This is something that has been rumbling since the earliest days of Zope. On the one hand, a huge part of the Zope story is "through- the-web". On the other, HTML (as we are all well aware) is a pretty restrictive user interface. Aside from the amount of time and effort required, I think one thing that has kept any serious efforts at a native or Java applet UI from happening is the fact that no matter what you implement or how well it is done, there are still going to be a significant number of people who don't like it and won't use it because "its not their tool". People understandably have differing tools preferences (emacs, dreamweaver, the list is endless). In light of this, we have tried to take a standards-based "maximum interoperability" approach. Our approach to date has been to provide support for things like FTP, WebDAV, and XML-RPC in an effort to work with as many standards-based clients as possible. We are also keeping an eye on developments in the Mozilla community, and the things they are working on look like they could be very promising as a foundation for eventually providing a much more usable and robust interface to Zope without losing the benefits of the through-the-web model. Such a thing would fit better with our standards-based approach than a totally non-std java interface, and using XUL and some of the other Moz technologies would allow Zope to provide a rich interface and still remain easily customizable. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
We are also keeping an eye on developments in the Mozilla community, and the things they are working on look like they could be very promising as a foundation for eventually providing a much more usable and robust interface to Zope without losing the benefits of the through-the-web model. Such a thing would fit better with our standards-based approach than a totally non-std java interface, and using XUL and some of the other Moz technologies would allow Zope to provide a rich interface and still remain easily customizable.
And don't forget the ZIE-project using Microsoft's proprietary API to enhance the UI ;-) As I understand it, XUL is proprietary Moz-tech, right? With a web browser installation rate at approximately 70-30 it's impossible to ignore Microsoft, where one likes it or not. //johan
At 16:33 15/10/99 , Johan Carlsson wrote:
We are also keeping an eye on developments in the Mozilla community, and the things they are working on look like they could be very promising as a foundation for eventually providing a much more usable and robust interface to Zope without losing the benefits of the through-the-web model. Such a thing would fit better with our standards-based approach than a totally non-std java interface, and using XUL and some of the other Moz technologies would allow Zope to provide a rich interface and still remain easily customizable.
And don't forget the ZIE-project using Microsoft's proprietary API to enhance the UI ;-) As I understand it, XUL is proprietary Moz-tech, right?
With a web browser installation rate at approximately 70-30 it's impossible to ignore Microsoft, where one likes it or not.
When Mozilla 5.0 is released, I can see that balance reshift the other way round in no time. IE5.0 against Netscape 4.x is M$'s win, certainly for a web site developer, but Moz 5 is an Open Source development. XUL can and will be implemented by others, because of that. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
[snip using Mozilla's XUL for Zope] Johan Carlsson wrote:
And don't forget the ZIE-project using Microsoft's proprietary API to enhance the UI ;-)
Yes, cool, though in Linux it's hard to use that. :)
As I understand it, XUL is proprietary Moz-tech, right?
Only for some values of 'proprietary'. Perhaps a trifle more proprietary than Zope itself -- the Mozilla license is open source but a less liberal one than Zope's. In theory XUL could be used by other browsers; the source is open.
With a web browser installation rate at approximately 70-30 it's impossible to ignore Microsoft, where one likes it or not.
I'm very very curious about what will happen to the web browser market next year when Mozilla is out. It's going to be very interesting indeed. Regards, Martijn
Johan Carlsson wrote:
And don't forget the ZIE-project using Microsoft's proprietary API to enhance the UI ;-)
Yes, cool, though in Linux it's hard to use that. :)
Again, how runs Linux without technical skills? Not to many I believe. ZIE aren't for technically skilled people, but for a 60 years old lady here in Sweden that we usually to call "Agda at the postoffice". But hey, I run Linux ;-) //johan
Again, how runs Linux without technical skills? Not to many I believe.
I recently installed Redhat 6.1 and it was a dream. Believe me, Linux's usability is advancing very quickly, I wouldn't be surprised if it was ready for Agda and her postoffice within 6 months.
ZIE aren't for technically skilled people, but for a 60 years old lady here in Sweden that we usually to call "Agda at the postoffice".
While I respect anyone who contributes their time to Open Source in any way, I would be concerned that developing Zope in a single platform direction is counter-productive. I would rather see those talented programmers working on something that everyone can benefit from (not just Linux users, but Mac users too!), not just a large minority (or even a small majority). If there were no alternative to IE as a more flexible client platform, then I would be more supportive, but the fact is that when we have Java and Swing, which are, or will soon be, supported by all popular web browsers on the vast majority of platforms, I don't see the point in going down the Microsoft road. Again though, if people really want to write M$ specific opensource code, then respect to them, they are still contributing code to the public good. Ian. -- Ian Clarke Email: I.Clarke@strs.co.uk Homepage: http://www.gnu.demon.co.uk/ Also see: http://freenet.on.openprojects.net/ "All we see and all we seem is but a dream within a dream"
Johan Carlsson wrote:
Johan Carlsson wrote:
And don't forget the ZIE-project using Microsoft's proprietary API to enhance the UI ;-)
Yes, cool, though in Linux it's hard to use that. :)
Again, how runs Linux without technical skills? Not to many I believe.
No, not many, though if you're managing Zope you are supposed to have some technical skills, right? Though I agree nicer GUIs could make things easier for less technical people. And it'll change quite rapidly now; people are putting Linux (and Mozilla) in all kinds of computer like devices; I recall a recent announcement by Nokia, ofr isntance.
ZIE aren't for technically skilled people, but for a 60 years old lady here in Sweden that we usually to call "Agda at the postoffice".
Ah, I was under the impression these efforts were more aimed towards making the Zope *management* interface nicer. If you're talking about a shell on top of Zope so that people can easily change the contents of a web page easily, I agree completely that we can't ignore MS for now. :) Regards, Martijn
Doesn't Java (as a pretty much universally accepted client side language) figure in this anywhere? Would it really be that difficult to create a Java conduit to the Zope database? It could support the various permissions based access and stuff, and then support plugins for editing the different types of object. In this manner, say, the makers of SquishDot could create a custom SquishDot editor plugin, and such like. I will freely admit that I haven't looked at the Zope Database too closely, but is this feasible or am I talking rubbish? I am an experienced Java coder, and as such would be willing to lend a hand to such an effort (although my time is very limited at present). It would be quite easy to get the ball rolling though by writing a Java API for putting, and retrieving, Zope objects via a TCP stream. Ian. -- Ian Clarke Email: I.Clarke@strs.co.uk Homepage: http://www.gnu.demon.co.uk/ Also see: http://freenet.on.openprojects.net/ "All we see and all we seem is but a dream within a dream"
Doesn't Java (as a pretty much universally accepted client side language) figure in this anywhere? Would it really be that difficult to create a Java conduit to the Zope database? It could support the various permissions based access and stuff, and then support plugins for editing the different types of object. In this manner, say, the makers of SquishDot could create a custom SquishDot editor plugin, and such like. I will freely admit that I haven't looked at the Zope Database too closely, but is this feasible or am I talking rubbish?
I am an experienced Java coder, and as such would be willing to lend a hand to such an effort (although my time is very limited at present). It would be quite easy to get the ball rolling though by writing a Java API for putting, and retrieving, Zope objects via a TCP stream.
Ian.
Preferably by using XML-RPC. It just stroke me that using XML-RPC as the communication layer between any client tool and Zope would be the best way to separate client-logic from Zope-logic. Is that a good idee? Are there any free JavaScript implementations of a XML-RPC client out there? //johan
Preferably by using XML-RPC. It just stroke me that using XML-RPC as the communication layer between any client tool and Zope would be the best way to separate client-logic from Zope-logic.
Is that a good idee?
It sounds good to me but then I am a Zope newbie. Certainly it would be better to have a generic "automatic" interface to the Zope database, than one for Java, one for (perhaps) a Windows app, etc etc.
Are there any free JavaScript implementations of a XML-RPC client out there?
If by JavaScript you mean Java (Javascript is the somewhat crappy language that can be embedded in HTML - Java is the cool language from which Applets are made) then I am sure the answer is yes - XML is well supported on Java. Ian. -- Ian Clarke Email: I.Clarke@strs.co.uk Homepage: http://www.gnu.demon.co.uk/ Also see: http://freenet.on.openprojects.net/ "All we see and all we seem is but a dream within a dream"
Ian Clarke wrote:
It sounds good to me but then I am a Zope newbie. Certainly it would be better to have a generic "automatic" interface to the Zope database, than one for Java, one for (perhaps) a Windows app, etc etc.
Why not create a client app that uses HTTP (XML-RPC, or straight HTTP POST/GET) to do the things that the Zope management interface does through a web browser now? Does it need to talk to the ZODB directly? Doug
Ian Clarke wrote:
Doesn't Java (as a pretty much universally accepted client side language) figure in this anywhere?
<flamebait type="language holy war"> I don't know of any language that is "universally accepted". Use whatever language *you* want to use. For Zope, Python might be a better fit. Or maybe even JPython. </flamebait>
Would it really be that difficult to create a Java conduit to the Zope database?
The conduit already exists. XML-RPC lets you call any method in the Zope API -- from ANY language that supports XML-RPC.
It could support the various permissions based access and stuff, and then support plugins for editing the different types of object. In this manner, say, the makers of SquishDot could create a custom SquishDot editor plugin, and such like.
Creating this UI (plugins, etc.) is vastly more complex than creating a communication channel. IMO, Mozilla/XUL would be easier for product developers to support: 1) it is semantically closer to the HTML interface that they must already create, and 2) it can share a lot with the default HTML interface.
participants (7)
-
Brian Lloyd -
Doug Hellmann -
Ian Clarke -
Johan Carlsson -
Martijn Faassen -
Martijn Pieters -
Terrel Shumway