I have only review MochiKit briefly. What I have used more is Prototype with Scriptaculous which Ajax and effects support which is pretty powerful. The project is also pretty popular so development is quite active. It appears MochiKit ranks up there among the Javascript libraries.
What I like about using these libraries is the cross-browser concerns could be handled outside of the RC development which can focus on what the UI does and not bugs and inconsistencies across browsers. That should save us a lot of time and effort.
As for the folder moving example, that is just a potential use of the plugin architecture. I am sure people will implement extensions we never intended, like all of the extensions for Firefox which has made the browser so popular. One feature I may add with an the extension is to add a few buttons to the toolbar to send the currently selected message to the Junk or other folder like the delete button.
And the way I would have it carry out the move is to have the Javascript capture that event, relay a JSON message back to the server to request that PHP carry out the move. And it would be great if the server could reject the move or return an error status which would relay the message to the user.
I think with the right tools (Firefox, Firebug, Venkman, JS libraries) it would not be all that difficult to build the revised UI. I am reading the book Pro Javascript Techniques by John Resig and he covers all of the work you need to do to deal with different browsers, platforms and versions. He pulls in examples which use code snippets from people like Dean Edwards and others. I already knew Javascript pretty well but he goes into such detail that I am learning a lot.
What I like about using static HTML with Javascript to develop the UI is that we can work on the HTML templates without the Javascript being active. Then once that is tested and functional we can add the Javascript, but we can also pair the Javascript with a different HTML template which is very simplified for the purpose of just working with the Javascript and verifying that it will function by just relying on blocks marked with id and class attributes. Someone who wants to contribute and just know HTML/CSS will still be able to contribute. And the same goes for someone who knows Javascript.
Brennan
On Wed, 17 Jan 2007 20:11:16 +0100, Mathieu Lecarme mathieu@garambrogne.net wrote:
I agree with clean separation of html, php and js. I agree too with the simplicity of json, wich is part of php 5.2 and an extension for lesser version. But full dynamic HTML website is very hard to build, and harder to debug. The first step is choosing a javascript library. I use mochikit for my work, but other exists. Firebug is a must have for developpement, with client side logging. The pragmatic approch is mixing generated html, and client side building. Generated javascript must be replaced with json, wich is an automatic javascript serialization. The other advantage of JSON is rpc scripting. The example of spam moving is not well choosed, javascript is for client side interaction, mail moving must be done when the server code is checking imap for new mail, and moving it with imap too. But, you can use a trash button to mark a mail as spam, and doing something with it on client side, like bayesian training. By the way, mail moving is better done with specific server tools like sieve, this way, with a classical mail client, the mail is on the right place too. Ingo do this for Horde.
http://json.org/ http://mochikit.com/ http://getfirebug.com/ http://fr3.php.net/manual/fr/ref.json.php a pure php implementation of json : http://mike.teczno.com/json.html http://www.horde.org/ingo/
M.
Le 17 janv. 07 à 19:11, Brennan Stehling a écrit :
A while back I suggested breaking up the code to clearly separate the PHP, Javascript and (X)HTML so that it would be much more flexible. A plugin system would be a good example of that.
What I suggested was an HTML template system where the application loads largely as static content which uses XHTML and CSS to draw each of the portions of the page with class and id attributes carefully placed to denote important areas, like the toolbar, folders and message box. From there Javascript would use AJAX functions to communicate with the server. On the server PHP would service the Javscript using the JSON protocol for a clean communication layer.
With this architecture you could create a very powerful plugin system. I would have a Javascript library control all changes on the UI, such as loading messages from the server and placing them into the message box. Consider when the static template loads after you log into the system the following Javascript would run:
function init() { var rcc = new RoundCubeClient(); rcc.LoadFolders(); rcc.LoadMessages(); rcc.StartMonitor(); // polls server for new messages }
In the LoadFolders and LoadMessages method they would run an AJAX request to get the data necessary to call the following code...
rcc.AddFolder("Inbox"); rcc.AddFolder("Trash"); rcc.AddFolder("Junk"); rcc.AddFolder("Work");
And this RoundCubeClient object would be all static.
This leads into what you could do with a plugin architecture. A plugin could do a good deal of work with just the Javascript and a little PHP on the server. Modern Javascript techniques show how you can extend Javascript objects with a little inheritance, so consider that a RoundCubeExtension object could be defined as a base class which developers could use a base for inheritance. They could override certain behavior, such as hooks which are fired off by the RoundCubeClient. The client would loop over all configured extensions and run their methods as appropriate. One method that a SpamExtension may run is ProcessMessages() which may loop over all messages and flag messages which match a certain criteria, like a X- Spam-Status header on the message. The client would cal this method after the main method ProcessMessages() on the default client is run.
On the server-side the PHP extensions could provide additional data and carry out actions on the server. The Ajax requests can make any GET or POST requests of the server. The SpamExtension may look at a message in the Inbox and see the X-Spam-Status is set to Yes and call this function.
rcc.MoveMessage(message, "Junk");
Internally this MoveMessage function would carry out the same action that happens when we drag a message from the Inbox to the Junk folder, but this would happen with the extension.
The last time I looked the server-side PHP code was emitting a significant amount of the Javascript and the HTML. If this sort of architecture looks appealing I would like development to start moving in that direction as soon as possible. We already have a lot of this all working, it just needs to be pulled apart a bit into the distinct components.
When it comes to the RSS reader, the Javascript and JSON calls back to the server do not need to know where the content comes from. We could just implement a message type and allow plugins to handle messages by type. The PHP code on the server has to emit the message in the required JSON format to define the message id, subject, and body of the message. And dealing with folders is another matter. The RSS reader could define folders which it handles itself and when you click on them they are completely handled by the extension.
This may sound pretty complex, but when each piece is built carefully it will work quite well together and creating new features will be very easy.
Brennan
On Wed, 17 Jan 2007 18:33:37 +0100, Michael Bueker m.bueker@berlin.de wrote:
Sam Bailey wrote:
- Create as a plugin or as a separate or joint project
According to the roadmap, a plugin API is in planning. I think an RSS reading feature is beyond the scope of roundcube, and I personally would consider it to be bloat.
But it seems a perfect model plugin, and many people will probably like the functionality. Even if browser have RSS plugin, you don't usually take your browser everywhere, but you do access roundcube from everywhere. So it has its purpose.
Keep the 2 cents ;)
~Mik
-- I remember 20 years ago when young lady was just getting into email she ask me if a virus could be spread by email. I just laughed and said no, it would never happen. It would require that email readers have the ability to execute code passed to them, and nobody would be stupid enough to write a mail program that would do that.
- Lord Apathy on /.
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net