> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Pedro Mota
> Sent: Friday, June 23, 2000 10:00 AM
> To: [EMAIL PROTECTED]
> Subject: [jBoss-Dev] EJX v2 proposal
>
>
> Hi all:
>
> Here is a proposal for a improved EJX GUI. Using EJX I've
> found it is very .xml oriented. You have to edit two or
> three .xml files to get your application deployable in
> jBoss2. I want to present a better (in my opinion)
> alternative.
>
>
> PROPOSAL
> -----------------------------------------------------------
>
> Make an improved EJX GUI. One that can make your .xml files
> "behind the scenes" while you concentrate on the components
> that make your application and how they relate to each
> other.
It is true that we need a new abstraction for assembling applications.
Presenting the user with the online environment is the right visual one to
do it. You assemble your stuff. We generate the files for you.
> DESCRIPTION
> -----------------------------------------------------------
>
> I've found the NOMENCLATURE of jBoss2 code very clear. This
> has inspired me :-) this proposal. I like the names
> Application, Container... etc.
>
> (1) The user will work with these concepts to construct the
> application. User is not the correct word, the applica-
> tion assembler is a better one. I see EJX as an appli-
> cation assembler tool. In fig.1 are the basic concepts
> the assembler will see.
>
> Fig. 1 -> http://perso.wanadoo.es/dwillis/fig1.gif
>
> EJX should be able to read jBoss config files to
> show the esternal resources (like datasources, mail
> sessions, jms services, etc).
>
> I think the best way to show this information is
> graphically (I learn to program 16 years ago on a Mac,
agreed, it puts a very simple and intuitive context on what we are trying to
do here.
It might also be difficult ;-) but you seem up to the task.
> I am very graphical oriented :-) This way we could
> show relationships between components with a simple
> line connecting two items. We could see quickly
> components with unresolved references (ie, an ejb
> with an ejb-reference not connected to any other bean,
> or an ejb with a resource reference not connected to
> any external resource). EJX could analyze these
> references and see if they are satisfied, and show
> a list of conflicts. Going far, far (far away from
> this galaxy :-) EJX could, using the new verification
> classes in jBoss2, verify the complete application
> to see if it is EJB 1.1 compliant (EJB 2.0 compliant
> in the future).
>
>
> IN-DEPTH
> -----------------------------------------------------------
>
> Here are the steps the app. assembler will do to create or
> modify an application.
>
> (1) New/Open application
>
> Fig. 2 -> http://perso.wanadoo.es/dwillis/fig2.gif
>
> (2) This would be show to the app. assembler
>
> Fig. 3 -> http://perso.wanadoo.es/dwillis/fig3.gif
>
> (3) Clicking in the Application area would show the common
> properties/actions of the Application.
>
> (4) Clicking in the "Web containers" area would show the
> common properties/actiosn of web containers.
>
> - Web containers administration (I don't know if there
> any, hehehe). Ability to add/modify/remove configu-
> rations.
>
> (5) Clicking in "EJB Containers" area would show...
>
> - EJB containers administration. Ability to add/modi-
> fy/remove container configurations.
>
> - EJB persistence managers administration config?
>
> - Other common EJB configurations.
>
> (6) Clicking in a particular container would show the
> specific properties of this container.
Yes that is a natural navigation of the data. Exposing the files is
unnatural I agree.
> (7) Every item (application area, web containers area,
> a particular container, external resource) should
> have a pop-up menu to do the same things that can
> be done through the properties page.
>
>
> RELATIONSHIPS
> -----------------------------------------------------------
>
> Using this graphical interface only to display in a fancy
> way an application and its components would be useless. I
> think that it offers a lot more than just displaying
> beatiful colored rectangles ;-)
why, sounds like a plan to me.
>
> Here is an idea to construct an application just drawing
> lines from component to component.
>
> (1) Every container would have handles to show references
> to external components.
>
>
> (2) The application assembler will create these handles
> (ie. ejb-references, resource references, etc) and
> then selecting the "line tool" will connect this
> handle to another component. EJX will ask the nece-
> ssary information to complete the request.
>
> Fig. 4 -> http://perso.wanadoo.es/dwillis/fig4.gif
>
> This way if we see a handle not connected to any
> component, we know there is an unresolved reference.
> EJX will check these situations to show the app.
> assembler a list containing all the conflicts found.
>
>
> PLUGIN ARCHITECTURE
> -----------------------------------------------------------
>
> I like a lot the plugin architecture of EJX. These plugins
> show a properties page when an item is selected. How does
> EJX will know when to show the correct plugin? Well, I
> see it's a matter of SCOPE.
>
> For example, an ejb container configuration plugin has to
> be shown when we select "EJB Containers". This is the
> scope of the plugin.
>
> This scope could declared in a xml file associated with
> the plugin or something similar.
>
>
> THAT'S ALL FOLKS
> -----------------------------------------------------------
>
> Here are some ideas to improve EJX. I think some are
> valuables. If this mail has made someone begin to think
> about more possibilities... well, "mision cumplida" (I
> can't translate this, sorry ;-)
>
Mission accomplished....
hell no pedro!
Mission impossible, but you seem up to the task :)
> kind regards
>
> Pedro Mota
>
> -----------------------------------------------------------
> P.S. The most dificult part doing this new EJX I see is in
> the routing of lines (is there any CAD/CAE developer
> here? :-)
TJ3 does this extensively so I am sure we can do a simple one graphically
speaking. What is going to be difficult is the interpretation of each of
these lines and what they mean... but we are running way ahead of ourselves
here... I find it very interesting though.
marc
>
>
>
>
>
> _______________________________________________________
> �Tienes cuentas de e-mail GRATIS en Excite Espa�a!
> A tu disposici�n en http://correo.excite.es
>
>
>
