Re: Proposal for Web Admin Console

[Anne S <hy...@gmail.com>]

The following is an email I sent to Danny Angus and the James PMC last
Friday. I look forward to hearing responses to this plan.

On 7/8/05, Danny Angus <da...@gmail.com> wrote:
> Hi Anne,
>
> Can you confirm that your proposal has been accepted by Google Summer of Code?
>
> If so can you provide us with your plan, so that we can discuss your
> involvement and our next steps.
>
> d.
>
> P.S. it might help communication if we know what timezones we're all
> in, I am in BST/GMT.
>

Hi Danny,

Yes, I can confirm that. Sorry about not getting to this sooner; I've
had to clarify some tax/school information with Google before I was
finally cleared.

My plan:

1. Build the console first. The GUI, layout, etc elements, NOT the
plugins and James-specific code. I'm working on this right now. The
way I'm designing it is:


Plugins, to display a page on the James console, will create a
ConsolePage object. This ConsolePage object will then store various
elements for display.

For form elements, I created an interface called ConsoleQuestion that
defines public String getQuestion, public String getHTML, and public
String getDescription. Classes that
implement ConsoleQuestion will store a question, then an answer field
for the answer. The question will be returned via getQuestion, and the
_HTML_ for the answer field will be returned via getHTML. This is
important, as each class implementing ConsoleQuestion will be allowed
to create its own way of answering that question. There will be
classes such as ConsoleTextfield, ConsoleList, ConsoleTextarea, etc.
getDescription will return a human-readable string describing what
should be in the answer field. For example, a ConsoleQuestion class
would return (strings can be changed by plugin) "Password:" for
getQuestion, the HTML for a PASSWORD field for getHTML, and "Password
must be a combination of letters and numbers" for getDescription. The
console would (presumably) format the text of getDescription as small
text under the input field.

I also created a ConsoleText class to store raw text/HTML for direct
display on the console, and a ConsoleMenuItem to represent a single menu
choice (icon associated as well to the choice).

So a plugin to the console could use any of the above classes (or
derivatives) to build a page (adding various elements to a
ConsolePage) for display to the user.

A plugin will then send over the ConsolePage to a template JSP page to
be written out for display.

NOTE: 99% of the HTML code for the console will be written out in one
or two JSP template pages, so the console L&F can be easily changed.
Do not be confused by the presence of a function called getHTML: all
it will do is write out VERY SPECIFIC HTML code for that particular
class. For example, in my current iteration of ConsoleTextfield,
getHTML returns only (INPUT TYPE=textfield size=some_size
name=some_name value=default_text class=consoletextfield).

The rest of the GUI still has a few details to be ironed out, but I
don't believe there will be a problem.

NOTE: Despite the fact that I say such things as "created" or "written
already", nothing is set in stone. I merely wrote out a few classes
such as ConsoleQuestion, ConsoleTextfield, ConsolePage, etc to see how
things should work. I am not married to this approach, so nobody
should consider it to be the final word. If anybody has input, I would
welcome it.



2. Currently, I'm planning out a two-parter for the actual
James/plugin code: Plugins and a communications overlay over James.

First the plugins. In the architecture I'm thinking of, plugins will
be added to the console and handle the grunt work, such as building
pages for display to the user, processing form data, figuring out what
the user wants, etc. These plugins will then communicate over XML-RPC
(or some other protocol, again I'm not married to this choice) to the
communications overlay on James. This overlay will handle the actual
work, adding users, changing forwarding settings, editing config.xml,
etc.

This division of labor is an important distinction, as James and the
console may be located on different machines, for example. In this
case, James/ the communications layer will be located on one machine,
and the console/plugins will be located on the second machine. Also,
other people may choose not to use this console, and instead integrate
James into their own console (for example, Plesk, CPanel). Other
consoles can drop this project's console and communicate directly with
the communications overlay on James.

Plugins will implement a ConsolePlugin interface which will define two
methods: public ConsolePage doMenu, public ConsolePage doForm. Links
from menu options on the
console would be processed by doMenu, while doForm will handle forms
processing. Of course, doMenu would receive relevant data on which
menu item was clicked, and same for doForm. The methods would return a
ConsolePage object that describes what the next page should contain.

As for timezones, I am in the US, Central Standard Time.

Previous posts to this thread have involved icon discussion. I should
note that I have acquired the permission of several artists to use
their images in this project. Several have also noted that they would
be honored to create some custom icons for us. If anyone wants, I can
forward their permission emails to you/the mailing list.


I'd like to hear what you think of this architecture, and any
modifications/other archs that you think would work better.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org