geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "n. alex rupp" <rupp0...@umn.edu>
Subject Re: console design
Date Fri, 21 Nov 2003 07:04:03 GMT
Jeremy made some great points in here.  The two types of applications are
sufficiently specialized that they will require their own component structures.
I'm not concerned at all with thick client UI development and believe we can
offer more features faster with a thin-client approach, *and* that they'll be of
higher quality.  My primary concern is for implementing the types of features
that Jeremy mentioned, and I've made a list of them in the wiki (to which I'll
be adding Jeremy's examples).

I can tell you that the web console will be modular and that it won't use MVC.
That last part might alarm you.  It shouldn't, and my reasons for that will
become clear as you get more familiar with the app and as I produce more
literature on the topic.  I always try to isolate the concerns of the different
components in the app, and I'm always looking for new ways to break down large
systems and make them more modular.

So if by MVC you really mean separation of concerns, then please don't worry.
If, on the other hand, you want to figure out how to structure an n-tiered web
application in the same way Xerox designed thick-client UI widgets in 1980,
well. . . .

My plans for the console-web module are in the wiki and I invite you both to
please read it.  I keep it up-to-date.

Night,
--
N. Alex Rupp (n_alex_rupp@users.sf.net)

<snip/>

> All for that, provided the resulting applications work.
>
> If you look at the console for JBoss, then it exposes the raw MBean
> structure. This is useful to a container developer or experienced admin,
> but almost totally useless to a typical user. The Weblogic console, on
> the other hand, dumbs the configuration down to meet the needs of the
> typical user, but doesn't give enough utility to the experienced admin.
>
> And, of course, neither works for shell-level access where you end up
> editing XML and copying files around.
>
> I'm not really a UI person, but I would like to see us reach a
> compromise where the console is easy to use for a new or inexperienced
> user, but offers a way to expose the raw details to the experienced one.
>
> For example, the 'basic' UI for creating a JDBC DataSource might prompt
> for the vendor type, and then offer a wizard to step through connection
> setup (properties like server name, username, password, ...); the
> advance version would allow for fine control over the pooling policy,
> choice between XA-, Local- and non- transactional, SQL to be issued,
> security (including reauthentication), ...
>
> Another thing not to forget is the ability to import/export
> configuration details. For example, I would want to set up the above
> JDBC DataSource in my staging environment and then be able to
> export/import that exact configuration into production without having to
> type anything back in.
>
> --
> Jeremy


Mime
View raw message