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: Fw: console-web
Date Mon, 03 Nov 2003 20:31:08 GMT
This is good.  I was hoping someone would bring this up, so I could explain my
decision : )

----- Original Message ----- 
From: "Sonnek, Ryan" <Ryan.Sonnek@bpc.com>
To: <geronimo-dev@incubator.apache.org>
Sent: Monday, November 03, 2003 11:07 AM
Subject: RE: Fw: console-web


> Just trying to help out where I think I can.  I'm new to geronimo, and to
> try and understand what the hell is going on, I thought starting small would
> be good.  UI does not impact the underlying system, but it DOES provide a
> great chance to learn what is going on under the covers.
>
> Removing html from the jsp custom tags is just one of my pet peeves.  It
> completely restricts someone that does not the system what is going on from
> making improvements.  I hate to see any application ignore the role of the
> "designer" (which I am not claiming to be!  I know about as much "layout" as
> a blind monkey)

Here lies a tricky paradox.  You're admittedly not a skilled designer, and
unless you're willing to put a significant investment into training yourself in
that area, you won't be one anytime soon.  On the other hand, I *am* a skilled
designer--that's where I cut my teeth in this industry.  I've been designing for
nearly a decade now and I know the ropes, (but Jeremy and David's son have
taught me a few tricks in the last year, and I've always benefitted from Dain's
discerning eye).  But what's better, I'm also a developer.  I can develop
client-side components in ecma-script, interactive UI engines using flash,
director, whatever you like.  And I can write middleware components, web apps,
ejbs, custom tag libraries in JSP, XSLT processors, servlet frameworks, all
that.

Now, when most people think about "separation of concerns" between designers and
developers, there is an implication that the developers are trying to shield
their code from the designer, so as not to confuse them with business logic.
But here, that is not the case.  I, the designer, have decided to use custom JSP
tag libraries to hide the presentation logic from the developers, so as not to
confuse them with HTML and other complex presentation logic.  Since this
application does not yet deal with any business logic, I've not yet needed to
separate the concerns of the component architecture.  But I've plans to do that
very soon as we move past the basic JMX client application into more complex
server and container management.

So, when the time comes to write a good web application, it makes sense for me
to build pluggable design components using custom JSP tag libraries and a heavy
reliance on CSS.  That way, I know that I can guarantee the visual outcome of
the work.  And I enjoy working with presentation logic; enough to write
fine-tuned component tag libraries.  Dropping HTML into the tag libraries is the
only practical route for me.  I *am* concerned with making the material more
approachable for newcomers, and I'm already beginning to notice flaws in the
structure and preparing to refactor.

I've made a distinction between separating the concerns of the archetectural
components and separating the concerns of the developers.  From my perspective,
developers of this console must have a solid understanding of both ends of the
product (being the presentation logic and the JMX interfaces), or be willing to
accept certain abstractions in order to ensure the quality of the end-product.

> But all I'm really trying to do is find a way to understand what's going on
> and help out where I can.  I see this as a great learning experience for me
> to be exposed to JMX and hopefully I can branch out from there and help
> other places.

Therefore, you rock : )

> If anyone has ideas on an area that could use work, like
> testcases, or someplace that would be a good introduction, I could start out
> there.

I have an idea where you could start out.  I am interested in building a set of
very simple DataSource objects that encapsulates all of the information
contained in MBeanInfo, MBeanAttributeInfo and MBeanOperationInfo objects so
that data can be easily be accessed and printed to the screen in a "polished"
format.  This involves string parsing and very little else.   I want to remove
the parsing logic out of the presentation tags for the console.  I also want to
break up the MBeanAttributesTag object into three (or more) tags which nest
inside of an MBeanInfoContextTag object.  I want to the screen output to be more
modular than it is. And I could always use more comparators : )

I also need to start incorporating a servlet framework into this process, as I'm
getting to the point where it would be nice to be able to validate incoming form
data, and it would also be nice to keep a repository of objects in the session
context which have been summoned using invocations and can be used as the input
parameters for other invocations--this will involve building wrappers for the
presentation components as above, but will probably involve more use of
reflection, because we can't be guaranteed there's an MBean interface for the
return types.  The code for matching objects by type and presenting them in the
"MBean Operation Information" table, probably in some kind of drop-down menu,
needs to be written.  Code governing the placement and behavior of the "invoke"
buttons needs to be written--you shouldn't have an invoke button if you don't
have all of the parameters available to invoke a method, right?   There's other
stuff, too, which we could get into.

I've got a ton of work I could use help with, and I'm happy to work closely with
you, so you don't feel lost in the code.  And we *can* always shoot for more
abstraction if it makes it easier for you to contribute : )  If any of the above
interests you, then by all means let's collaborate now and finish up some of
these features.

> I am just looking for a way into this project, and would be glad to look in
> another area.

I think it's important we all remember that there is no portion of this project
which isn't going to be challenging.  It doesn't matter where you get
involved--the entrance threshold is daunting wherever you look, because we've
set the bar really high.  But if you've got experience developing presentation
logic, I'd be happy for the help.

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


Mime
View raw message