Client rewrite for RoundCube

Brennan Stehling brennan at offwhite.net
Mon Aug 28 19:39:45 CEST 2006


I will do what I can to help out.

What we can do is start by knocking out the code for the data model and then define the various methods and events which will draw the web screens using that data model.  I think we also want to define the server-side endpoints as well.

And with Javascript I have seen how some projects simulate namespaces, so we could create the following objects.

Controller
----------
RoundCube::Main
RoundCube::UI

Data
----
RoundCube::Message
RoundCube::Contact
RoundCube::Folder

Each of these objects can be populated with JSON, which has PHP support.

http://www.json.org/

Using JSON would reduce the amount of code we would need to use to serialize the model over AJAX requests.

Brennan

On Mon, 28 Aug 2006 09:41:51 +0200, "Thomas Bruederli" <roundcube at gmail.com> wrote:
> Hi Brennan,
> 
> I understand your concepts for enhancing the client code of RoundCube
> and I mostly agree with your ideas. The current code is very straight
> forward and grew with the application. It currently counts about 3900
> lines! All actions are held in one object and are (mostly) invoked
> using one method: rcube.command();
> 
> I already wanted to split the code into task-specific files such as
> mail, address book and settings where all methods are added to the
> main class using rcube_webmail.prototype.nnn. Also creating some new
> classes for list functionality etc. was in my mind.
> 
> There also popped up some plans and suggestions to make the client
> even more ajaxy and eliminate full page loads when switching between
> list, view and compose mode. Probably that's something we could
> include in this concept.
> 
> Actually I agree with a rewrite as you suggested, the only
> disadvantage I see, is that this will take some time and it will stop
> the current development because merging could become very difficult.
> That's also the reason, why I cc-ed the mailing list because that's a
> task that concerns all developers. For me, it's no problem because
> I'll go on holiday for more than a month soon and will not work on the
> project then.
> 
> Best regards,
> Thomas
> 
> 
> 2006/8/25, Brennan Stehling <offwhite at gmail.com>:
>> My approach with the frontend would be to make it much more object
> oriented
>> and event-driven.  Each mail folder would be represented by a folder
> object
>> which would hold a series of  message objects.  And when you need to add
> a
>> message to the display, you simply add a message to the folder object.
>> Adding it will trigger an event to update the display.  Essentially I
> would
>> create a model in Javascript to represent the system and have the
> screens
>> rendered from that model.
>>
>> The current frontend code is writing out HTML DOM directly when the
> backend
>> requests it.  And there is no good way to trigger an event based on
>> something happening with a message or folder.  Like when you move a
> message
>> from the current folder to another (or folder at this point), I would
> simply
>> use the following code.
>>
>> inboxFolder.remove(message1);
>> trashFolder.add(message1);
>>
>> A controller object (MailAgent) may wrap this behavior.
>>
>> mailAgent.moveMessage(message1, inboxFolder, trashFolder);
>>
>> Internally when the folders are changed at the model level they can
> trigger
>> display events which update the screen as needed, like updating the page
>> Title for the current count, the folder tray and the message tray.  The
>> counts to show are the counts for the messages held by the folder
> objects.
>> It is no longer just dictated from the server-side.
>>
>> And at the UI level you would have those objects: PageTitle,
> MessageTray,
>> FolderTray, etc.  In the FolderTray you would simply have it bound to
> the
>> Folder object which holds  a collection of Message objects.  And since
> the
>> Message objects have date and string values it would be very easy for
> the
>> MessageTray to sort them on those properties.
>>
>> Notice that at this point there is no HTML DOM being managed.  By
> separating
>> those conceptual areas you can have project volunteers focus on what
> they
>> know best.  I know XHTML, CSS and Javascript well and if all I did was
> help
>> out by handling the UI portion of the Javascript I would be productive
> at
>> it.  I would not have to concern myself with how I need to interact with
> the
>> mail system.  I would just work with the methods and properties
> available on
>> the objects I had available to me.  I would work against the API of the
> mail
>> model.
>>
>> The same is true for the mail model.  A developer could focus on
> enhancing
>> the model to do some amazing stuff.  Like when the message is moved from
> one
>> folder to another it would trigger the server-side interaction to make
> that
>> happen.  If that fails, they can have the message returned back to the
>> folder it came from to ensure UI properly matches the server-side state.
>> And they would do so without touching any HTML DOM.
>>
>> Brennan
>>
--
Brennan Stehling
Offwhite.net LLC
brennan at offwhite.net





More information about the Dev mailing list