You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2001/11/25 04:50:11 UTC
[phoenix] Mock UI for Management Console
Hi,
I just went and put together a Mock UI for the Phoenixs Management Console.
You can check it out in jakarta-avalon-phoenix/console/src/mockui. It makes a
few assumptions about how things will be managed.
It also has no icons yet. You can see where I think that Icons should be
included by looking for brackets. (i) means an icon should be used in
addition to the associated text. [i] indicates the icon will replace the text
while [bi] indicates that icon will be button-like.
-----------------------------
Assumptions
-----------
Firstly it assumes that you will be managing a single instance of Phoenix at
any particular time. This will always be true in our current architecture.
When we eventually allow management of clusters of Phoenix servers we will
have to reasses this assumption.
The second assumption it makes is that you manage a single application at are
time and are unlikely to be switching between different apps regularly. Thus
if you choose to edit app X then app X will take over all of the screen real
estate.
The third assumption it makes is that when ever you make modifications to
configuration parameters (config parameters, permissions etc), it will
require a restart of the relevent component before they are "activated". This
is to make coding Blocks/other components easier and more fault tolerant. So
in many cases you are not directly modifying the current object but creating
a new object that will be picked up next time app starts up.
The UI
------
There is basically a few different types of screens/forms in the UI. The four
common types of form are;
1. display a table of attributes + operations for a set of objects
2. display a single objects attributes + operations
3. display a table to generate querys against objects
4. display status/results of action
Table UI
--------
(1) is used in a couple of places like displaying all the extensions,
applications and loggers in the kernel. It is also used to display the
Manageable services exposed by blocks, the loggers used by application, the
permissions applied to application.
The tables usually have the the name of the component in the first column (if
it has a string based primary key). In the last column there is a set of
operations that can be performed on component (usually things like delete,
undeploy, restart, enable etc). These operations are usually based on current
state of object.
The rows in table are sortable by clicking on the column names. This will
sort them by the specified column.
The table UI usually also has an "add" or "create" button at top left hand of
table - at least if the type stored in table supports creation in such a
manner. There is also a "query" button at top right hand of screen for when
you want to see only items that match a specific query.
Currently clickling on the name field will goto a page that
displays full attributes of specified object. Whereas the table may give an
abridged version the single-object version will give full view. See Object UI
for further discussion about this.
It may be that in the future you may be able to select the whole row (magic
using javascript) however not sure which version is more usable.
Object UI
---------
The Object UI describes a single object. After the page title is a list of
attributes of object and following that a list of operations.
In some cases the Object UI allows you to edit the values of the object and
then save them. The Object UI may also allow you to execute operations on
objects - in some cases passing parameters.
Some examples of Object UI screens include;
* the create screens associated with each table
* property sheets associated with Container components
* base pages for application/phoenix
Query UI
---------
The query API is probably the most primitively developed screen at this stage
but this reflects it's lesser importance. Essentially the query screens allow
you to select criteria of the object to display. The criteria essentiallly
consists of; attribute name + relation + value
There is currently no way to do OR or NOT criteria
Status UI
---------
Whenever an action is invoked it usually returns some form of results or
indicates some sort of status. The Status UI is where this occurs. Usually
this page just contains a title, some text describing the status of the
operation and results of operation. At the end of the page is a link back to
originating page.
Help
----
Currently there is no help on any of the screens. I was thinking of doing two
things to rectify this. Place a little "?" besides things that have help
describing what they are (like column names). Clicking on this may result in
small popup window displaying help or maybe it could display in status bar.
The other way of providing help I was thinking about was placing a help
button in some standard position on each page (upper right corner above
title?). This button would display help about current screen and describe
what is meant to happen in it etc.
-----------------------------
So what does everyone think? I wouldn't mind some feedback on the ease of
navigation and cognitive congruence (ie is it easy to use and does it match
how you would do things?) Also do the assumptions I made seem reasonable? Any
other Usability issues?
Now the actual presentation of it may be a bit lame and without the icons it
may be a bit ugly ... but I never claimed to be a graphic artist ;) Anyone
who has better skills in presentation layer should feel free to produce some
better looking pages ;]
Anyways I plan to put the basic infrastructure in place sometime in next few
weeks. Possibly next weekend. Basically it will consist of a servlet that
connects to the MBeanServer via a RMI adaptor and presents a little data to
user and maybe a few of the options. However it wont be much for now - unless
of course someone wants to volunteer to do that bit ;)
--
Cheers,
Pete
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
Rehi,
Oh I should probably mention you just open up index.html in that directory
and navigate from there. If you can't navigate for some reason or something
doesn't make sense feel free to say so.
--
Cheers,
Pete
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
On Sun, 25 Nov 2001 22:55, Paul Hammant wrote:
> I disagree. I've worked on (green screen) apps for 12 years and
> web-apps in the last six. I've never seen a screen/page orientated app
> that does not have a stack of screens/pages you've navigated through to
> get to where you are.
right. But I hope to make it only two "contexts" within the app. So in the
left corner there is essentially two buttons that will take you to default
page in each "context" (namely the "Phoenix Console" button and the
"Application" button).
I hope to have one level depth in each "context" and thus there is no real
need for a stack in that way.
> Besides, I think you'll find that you do end up going fiveor six levels
> deep in the end.
Maybe. But I specced it and the only real case I can come up with is when I
would customarily popup a dialog box in a heavy GUI app. And those dialogs
always return to last screen ... and thus I wouldn't put them in the "nav
stack".
Anyways off to start hacking on it now
--
Cheers,
Pete
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>GUI - Good enough as is to put into code.
>>
>
>Good enough is never good enough. If you have criticisms then I would prefer
>to hear about them earlier rather than later - it will mean less work for me
>;)
>
True enough. You (we) will never avoid refactor points though.
>The list of all the possible paths in the top level screen is
>
>applications/create
>applications/list
>applications/query
>extensions/create
>extensions/list
>extensions/query
>
>[...]
>
>So you can see you never deep in any editing tree so I am not sure I see any
>advantage to a navbar. What you think about that ?
>
I disagree. I've worked on (green screen) apps for 12 years and
web-apps in the last six. I've never seen a screen/page orientated app
that does not have a stack of screens/pages you've navigated through to
get to where you are. For most of those apps, some form of visible
display of where you are really helps the user have a minds eye view of
the system.
Besides, I think you'll find that you do end up going fiveor six levels
deep in the end.
applications/list/maintainApp/stopConfirm
applications/list/copyApp
applications/mountNew
It matters little though as, on merit, a nav bar can be added later.
>Well it is just standard JMX code where you also have to catch a
>RemoteException aswell. It is a bit ugly but it is likely that the majority
>of server console is done via a reflection API style code. Anyways heres the
>JMX snippet
>
>final ObjectName object = new ObjectName(":type=deployer");
>final String method = "deploy";
>final Object[] args = new Object[] { "file:///opt/avalon/ftpserver.sar"};
>final String argTypes = new String[] { "java.lang.String" };
>mBeanServer.invoke( object, method, args, argTypes );
>
Ugly. Perhaps, like for Bay, there is room for a set of delegate
classes that make these calls strong java APIs that fit the facade pattern.
>It should be usable now. To enable Leos work just startup Phoenix with the
>"--remote-manager" option. Unfortunately at this stage there is no sample
>client code but hopefully I will get to this next week.
>
:-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
On Sun, 25 Nov 2001 21:03, Paul Hammant wrote:
> Peter,
>
> GUI - Good enough as is to put into code.
Good enough is never good enough. If you have criticisms then I would prefer
to hear about them earlier rather than later - it will mean less work for me
;)
> You're missing a nav bar...
>
> Home > Regional > Countries > Australia > States and Territories >
> Victoria > Cities and Regions > Melbourne
> (
> http://dir.yahoo.com/Regional/Countries/Australia/States_and_Territories/Vi
>ctoria/Cities_and_Regions/Melbourne/ )
>
> ... but other than that it is fine.
It was a deliberate choice to not have one. See assumption 3 ;) I had a think
and I can only see an admin focusing on one aspect at a time - ie either
Phoenix Server as a whole or Application as a whole.
As such I can't really see a need for any nested navigation bar. At most you
will have a maximum of two levels for any screen like
The list of all the possible paths in the top level screen is
applications/create
applications/list
applications/query
extensions/create
extensions/list
extensions/query
logs/create
logs/list
logs/query
ConfigurationRepository
LogManager
PackageRepository
SystemManager
While the list of all the possible paths in the Application is
configuration/list
configuration/edit
service/list
service/view
logs/create
logs/list
logs/query
permissions/create
permissions/list
permissions/query
So you can see you never deep in any editing tree so I am not sure I see any
advantage to a navbar. What you think about that ?
> >Anyways I plan to put the basic infrastructure in place sometime in next
> > few weeks. Possibly next weekend. Basically it will consist of a servlet
> > that connects to the MBeanServer via a RMI adaptor and presents a little
> > data to user and maybe a few of the options. However it wont be much for
> > now - unless of course someone wants to volunteer to do that bit ;)
>
> I am quite interested in the RMI API. I'd like to start a Swing
> management console that could be opened inside Jesktop (or standalone).
> I'd also like to make beanshell commands for the functions you are
> offering:
>
> james = PhConnect("localhost:8231","admin","password");
> james.start();
Well it is just standard JMX code where you also have to catch a
RemoteException aswell. It is a bit ugly but it is likely that the majority
of server console is done via a reflection API style code. Anyways heres the
JMX snippet
final ObjectName object = new ObjectName(":type=deployer");
final String method = "deploy";
final Object[] args = new Object[] { "file:///opt/avalon/ftpserver.sar"};
final String argTypes = new String[] { "java.lang.String" };
mBeanServer.invoke( object, method, args, argTypes );
It should be usable now. To enable Leos work just startup Phoenix with the
"--remote-manager" option. Unfortunately at this stage there is no sample
client code but hopefully I will get to this next week.
--
Cheers,
Pete
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
On Mon, 26 Nov 2001 20:42, Ulrich Mayring wrote:
> Peter Donald wrote:
> > Making a programming langauge out of XML is wrong but representation of
> > DK ... now thats a good idea ;)
>
> Should this not read "making a >procedural< programming language out of
> XML is wrong"?
yep - thats what I meant.
--
Cheers,
Pete
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Donald wrote:
>
> Making a programming langauge out of XML is wrong but representation of DK
> ... now thats a good idea ;)
Should this not read "making a >procedural< programming language out of
XML is wrong"?
XSLT as a declarative programming language fits nicely into the
"XML-world", I think.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
On Mon, 26 Nov 2001 19:45, Paul Hammant wrote:
> > XML, XSL , LTPJB, XUL
>
> Is not Stefano's cryptic parting words of wisdom hinting (amongst other
> things) that we should avoid new solutions when existing ones will work.
if we avoided solutions when existing ones work then we would still be using
assembly. If it can be done faster, better, easier, cheaper by developing a
new technique then do it is my opinion ;)
> I.e. build a classic facade API for management of Phoenix, build
> presentation layers with that using existing technologies. (Servlets,
> JSP, struts ; Swing). Just because we can develop fancy & perfect
> solution using markup languges does not necessarily mean that the
> existing technologies are wrong.
http://www.javaworld.com/jw-08-2001/jw-0824-myth.html
It discusses why using "procedural knowledge" (PK) to define what should is
essentially an assembly step (ie declarative knowledge or DK) is wrong.
Making a programming langauge out of XML is wrong but representation of DK
... now thats a good idea ;)
Phoenix is pretty much based on the same principles outlined in that article
;)
--
Cheers,
Pete
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Paul Hammant <Pa...@yahoo.com>.
> XML, XSL , LTPJB, XUL
Is not Stefano's cryptic parting words of wisdom hinting (amongst other
things) that we should avoid new solutions when existing ones will work.
I.e. build a classic facade API for management of Phoenix, build
presentation layers with that using existing technologies. (Servlets,
JSP, struts ; Swing). Just because we can develop fancy & perfect
solution using markup languges does not necessarily mean that the
existing technologies are wrong. After all, we are all pushed for time.
"Your scientists were so pre-occupied with whether or not they could
they didn't stop to think if they should" - Jurassic Park quote.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
On Mon, 26 Nov 2001 23:29, Ulrich Mayring wrote:
> Peter Donald wrote:
> > I have a kinda different view. IMHO all GUI apps should be designed to be
> > passive - only respond to events. Whether the initiater of these events
> > is a user, a database or whatever should be irrelevent.
> >
> > Unfortunately this is rarely the case - most GUI apps put their logic
> > inside their event handlers (ug) rather than separating it into separate
> > logic components. Because of this the view code becomes so interwoven
> > with the logic most people assume it has to be this way ;(
>
> I believe you're saying that instead of responding to XML data the GUI
> could also respond to events and that would be an equivalent model of a
> data-driven application. I think that is correct in specific cases, but
> consider the content of events and XML data. An event is something like
> "Button 3 pressed" or "Pull-down menu 1, item 4 activated" - an
> inherently layout-oriented process.
Not how I model it ;) My events (maybe the term action would be better)
usually consist of things such as
* list people in crew X
* remove person 2 from crew X
* create task X
* create task X with params 1, 2 and 3
* create crew template X from crew 2
* dispath crew 1 to task 3
...
I try to separate my domain events/actions/whatever completely from my
presentation layer. GUI events only serve as glue and I usually just extract
all the parameters from them and delegate to the "real" event.
> If I write XML that encodes these
> events, then that's just a matter of putting angle brackets around the
> events. In that case there is a conceptual equivalency between events
> and XML data. However, I think that XML data makes it possible to use a
> semantically richer event content that is not layout-oriented, but
> data-oriented. Then, every time I change the data model, the GUI would
> adapt automatically.
agreed.
--
Cheers,
Pete
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Donald wrote:
>
> I have a kinda different view. IMHO all GUI apps should be designed to be
> passive - only respond to events. Whether the initiater of these events is a
> user, a database or whatever should be irrelevent.
>
> Unfortunately this is rarely the case - most GUI apps put their logic inside
> their event handlers (ug) rather than separating it into separate logic
> components. Because of this the view code becomes so interwoven with the
> logic most people assume it has to be this way ;(
I believe you're saying that instead of responding to XML data the GUI
could also respond to events and that would be an equivalent model of a
data-driven application. I think that is correct in specific cases, but
consider the content of events and XML data. An event is something like
"Button 3 pressed" or "Pull-down menu 1, item 4 activated" - an
inherently layout-oriented process. If I write XML that encodes these
events, then that's just a matter of putting angle brackets around the
events. In that case there is a conceptual equivalency between events
and XML data. However, I think that XML data makes it possible to use a
semantically richer event content that is not layout-oriented, but
data-oriented. Then, every time I change the data model, the GUI would
adapt automatically.
Spreadsheets like Excel are a simple example of this. If you change the
data model (e.g. by adding rows or columns) the GUI automatically
changes and gives you standard buttons to manipulate the new rows and
columns. Once I've seen a desktop database, where you could say "If this
db field has a value, then display a button, if it is empty, then
don't".
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
On Mon, 26 Nov 2001 21:34, Ulrich Mayring wrote:
> Peter Donald wrote:
> > This can be generalized in an XML workflow language. Theres a few
> > attempts in opensource and commercial alike that attempt this. Many are
> > even independent of the rendering technology (ie XML vs Swing vs
> > whatever).
>
> Yes, and my personal pet idea is that the workflow modelling and the
> user interface modelling should be in the same XML language. I believe
> in data-driven applications, even though this idea is not very popular
> with users of procedural programming languages. Users of declarative
> programming languages have never written anything else than data-driven
> applications, so some mainstream people tend to ignore this concept.
>
> If we're talking about data-driven user interfaces (instead of
> layout-driven), then XML and XML Schema are of course a natural fit for
> the data that is supposed to drive things.
I consider layout is just another set of data. I did some work for some
usability labs and while I didn't get to play with some of this directly I
did see them do some great stuff.
You know how many applications these days have a "simple" mode and a "expert"
mode. These would just be different Views on same Controller/Model. So people
with vastly different interaction requirements (data entry vs data
management) just mean a switch xml files.
Very very fast prototyping environment and very very good for satisfying
multiple different types of users.
> Usually applications are divided into the three main concerns of logic,
> data and presentation.
Controller, Model, View ? yeppo.
> The problem is that in a "classic" app the GUI is
> really a bunch of custom and active logic that pulls data to fill in the
> blanks. In a data-driven application the GUI is a bunch of passive and
> generic logic and the data is pushed into it.
I have a kinda different view. IMHO all GUI apps should be designed to be
passive - only respond to events. Whether the initiater of these events is a
user, a database or whatever should be irrelevent.
Unfortunately this is rarely the case - most GUI apps put their logic inside
their event handlers (ug) rather than separating it into separate logic
components. Because of this the view code becomes so interwoven with the
logic most people assume it has to be this way ;(
--
Cheers,
Pete
--------------------------------------------------
Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Donald wrote:
>
> This can be generalized in an XML workflow language. Theres a few attempts in
> opensource and commercial alike that attempt this. Many are even independent
> of the rendering technology (ie XML vs Swing vs whatever).
Yes, and my personal pet idea is that the workflow modelling and the
user interface modelling should be in the same XML language. I believe
in data-driven applications, even though this idea is not very popular
with users of procedural programming languages. Users of declarative
programming languages have never written anything else than data-driven
applications, so some mainstream people tend to ignore this concept.
If we're talking about data-driven user interfaces (instead of
layout-driven), then XML and XML Schema are of course a natural fit for
the data that is supposed to drive things.
Usually applications are divided into the three main concerns of logic,
data and presentation. The problem is that in a "classic" app the GUI is
really a bunch of custom and active logic that pulls data to fill in the
blanks. In a data-driven application the GUI is a bunch of passive and
generic logic and the data is pushed into it.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Peter Donald <pe...@apache.org>.
On Mon, 26 Nov 2001 09:34, Uli Mayring wrote:
> My idea is that a user interface can be described in XML. Then we have an
> XML schema that goes over the user interface we just wrote and tells us if
> it's a legal user interface or not. Hand-crafting a GUI is a pretty buggy
> and obnoxious process, writing some XML and checking against a schema is
> much better in my mind.
Hell yes !!!!
You may want to have a look at the XUL project at mozilla. They essentially
describe the GUI for all mozilla based applications using an XML format.
Unfortunately this is in C/C++ ;( However there is a jXUL project in progress
that I am eagerly awaiting to deliver.
XUL (XML UI Language IIRC) describes things at the level of screen components
and has things like <button>, <form/> and so forth.
Another project that I loved and cloned ages ago was IBMs BML (Bean Markup
Language). It worked with raw beans which you could also use to assemble
GUIs. It was somewhat more raw and still required programming skills but it
was still better than writing code.
Another option would be to have a look at the XML description language used
by QT (a cross-platform C/C++ UI toolkit). Its relatively nice and their GUI
builder (just creates an XML file) is great. Itis the same thing used in the
K desktop on the *nixes.
> There are probably many more points. I saw this particular light, when I
> started to use Cocoon1. I wrote several "quick'n'dirty" applications that
> were needed in a hurry. So instead of writing a frontend I used the web
> browser and at the server side Cocoon1 to do the logic. I wrote several
> XSP taglibs to help model the applications. Each application screen is an
> XML/XSP file residing on the web server and its logic is encoded in
> XSP taglib calls. User input goes via standard HTML forms.
kool.
> The only negative aspect of those browser-based Cocoon1 apps is program
> flow. The only way you can send a user somewhere else is by using a
> redirect. You can dynamically calculate the target location for the
> redirect, but when your apps become larger you quickly lose yourself in a
> web of dynamically-built redirects. The "if this, go there, else do that
> except if that is so" type of statements must be centralized in one place,
> so you can manage the workflow of large applications sensibly. You don't
> want to distribute these statements over hundreds of XML/XSP files.
This can be generalized in an XML workflow language. Theres a few attempts in
opensource and commercial alike that attempt this. Many are even independent
of the rendering technology (ie XML vs Swing vs whatever).
--
Cheers,
Pete
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Uli Mayring <ul...@denic.de>.
On Sun, 25 Nov 2001, Paul Hammant wrote:
> Here a related idea thought about some months ago. It would be possible
> with "Long Term Persistence for Java Beans" - LTPJB - (ex of swing
> conection, now in JDK1.4) to XSL style to a complete Swing app or just
> an entire panel and stream that over TCP/IP to a handler client.
Sounds like an interesting idea, if perhaps a bit weighty (don't know
enough about LTPJB to really say). The question is what do we want to
accomplish with XML/XSL in this case? We're not just using it to be
buzzword-compliant, right? :)
My idea is that a user interface can be described in XML. Then we have an
XML schema that goes over the user interface we just wrote and tells us if
it's a legal user interface or not. Hand-crafting a GUI is a pretty buggy
and obnoxious process, writing some XML and checking against a schema is
much better in my mind.
The next thing is that changing a UI is a lenghty process, what with
distributing the new app to every desktop. Changing an XML file on the
server means no distribution and instant updates.
Then, we have many tools to dynamically manipulate XML, be they Cocoon or
whatever. UIs could adapt to new situations at run-time, if we based them
on XML.
There are probably many more points. I saw this particular light, when I
started to use Cocoon1. I wrote several "quick'n'dirty" applications that
were needed in a hurry. So instead of writing a frontend I used the web
browser and at the server side Cocoon1 to do the logic. I wrote several
XSP taglibs to help model the applications. Each application screen is an
XML/XSP file residing on the web server and its logic is encoded in
XSP taglib calls. User input goes via standard HTML forms.
A really quick and dirty solution, which to my surprise is still in use
today. When the users need a new screen or new functionality I can provide
that in ten minutes. They just call me and minutes later they have their
new feature. Comparing that to the Swing-GUI apps we have in use: those
are never updated, because no-one has the time. If you know you need a new
window for just one week, you don't bother to put it in.
The only negative aspect of those browser-based Cocoon1 apps is program
flow. The only way you can send a user somewhere else is by using a
redirect. You can dynamically calculate the target location for the
redirect, but when your apps become larger you quickly lose yourself in a
web of dynamically-built redirects. The "if this, go there, else do that
except if that is so" type of statements must be centralized in one place,
so you can manage the workflow of large applications sensibly. You don't
want to distribute these statements over hundreds of XML/XSP files.
The Cocoon project's answer to that was at first the Sitemap. Then
people realized the Sitemap wouldn't do all that and talk started about
Flowmaps and Linkmaps. I don't know the current status of these
discussions, but I do think that these concepts are a little too specific
to Cocoon. The Cocoon-folks probably don't want to deal with Swing GUIs
and such. Also, if I'm not mistaken, it is quite adventureous to change
the Sitemap dynamically at run-time.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Paul Hammant <Pa...@yahoo.com>.
Uli, Peter,
>>I am quite interested in the RMI API. I'd like to start a Swing
>>management console that could be opened inside Jesktop (or standalone).
>>
>
>Another wild and unrelated idea, I've been tossing in my head for almost
>two years now. Apache fop can render XSLFO to AWT events (haven't tried,
>as AWT is icky), perhaps it would be possible to make it render to Swing
>for full-fledged GUI frontends.
>
>Since fop can also render to XML, it would probably be trivial to make it
>render to XHTML for browser-based frontends.
>
Here a related idea thought about some months ago. It would be possible
with "Long Term Persistence for Java Beans" - LTPJB - (ex of swing
conection, now in JDK1.4) to XSL style to a complete Swing app or just
an entire panel and stream that over TCP/IP to a handler client. One
the the demos for LTPJB was very close. The difference for that over
previous serialization was that LTPJB serializes the whole class as well
as the instance settings. i.e. methods are serialzed too. The
implication is that XML could be generated to a very strong Swing GUI
and sent to a client that has *no* element of the applications code
base. Server pushes pages and hadles version upgrades. HTTP/HTML's
request/reply contract for Swing GUIs. If all HTML were XHTML a Swing
GUI could be generated for each page and you might have the perfect web
browser. You could split your browser's functionality between server
and client depending on client footprint and connectivity.
It was also really dangerous stuff. If you had an instance for any Java
app, you could serialize it to XML and have an inspectable /alternate/
source notation form for Java. Nothing would be safe... you'd have to
dynamic proxy your own application internally just to prevent
reverse-engineer by LTPJB.
Hmm, just thought.... maybe some conditional code in "Store" that gives
a LTPJB serialization scheme for Fede's excellent block.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Uli Mayring <ul...@denic.de>.
On Sun, 25 Nov 2001, Paul Hammant wrote:
> I am quite interested in the RMI API. I'd like to start a Swing
> management console that could be opened inside Jesktop (or standalone).
Another wild and unrelated idea, I've been tossing in my head for almost
two years now. Apache fop can render XSLFO to AWT events (haven't tried,
as AWT is icky), perhaps it would be possible to make it render to Swing
for full-fledged GUI frontends.
Since fop can also render to XML, it would probably be trivial to make it
render to XHTML for browser-based frontends.
Why that? Well, instead of ranting on and on and stepping on everyone's
toes agains, I'll just say that the following very brief statement is my
personal opinion and overly broad:
An application consists of data, user interface and logic(*). Most people
agree that data should nowadays be represented in XML. I say that the UI
and at least parts of the logic should too. The Schemox people have the
right idea (http://www.schemox.org).
Ulrich
(*) LP-freaks forgive me. I was one of you and have strayed from the path
:)
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] Mock UI for Management Console
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
GUI - Good enough as is to put into code. You're missing a nav bar...
Home > Regional > Countries > Australia > States and Territories >
Victoria > Cities and Regions > Melbourne
(
http://dir.yahoo.com/Regional/Countries/Australia/States_and_Territories/Victoria/Cities_and_Regions/Melbourne/
)
... but other than that it is fine.
>Anyways I plan to put the basic infrastructure in place sometime in next few
>weeks. Possibly next weekend. Basically it will consist of a servlet that
>connects to the MBeanServer via a RMI adaptor and presents a little data to
>user and maybe a few of the options. However it wont be much for now - unless
>of course someone wants to volunteer to do that bit ;)
>
I am quite interested in the RMI API. I'd like to start a Swing
management console that could be opened inside Jesktop (or standalone).
I'd also like to make beanshell commands for the functions you are
offering:
james = PhConnect("localhost:8231","admin","password");
james.start();
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>