Excellent, It makes a lot more sense now that you explained why you did the things you do. I completely agree that the focus should be on improving the feature list and not on making it look "pretty".
<quote> 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. </quote> I'll start here. I'd like to get a little more information about your thoughts on this. I'm familiar with the Jboss JMX console, and I'm guessing that you're thinking along the lines of the work they did to define datasources in the simplified *-ds.xml instead of the verbose *-service.xml? so, does this at all impact the JCA Geronimo project? Ryan -----Original Message----- From: n. alex rupp [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2003 2:31 PM To: [EMAIL PROTECTED] Subject: Re: Fw: console-web This is good. I was hoping someone would bring this up, so I could explain my decision : ) ----- Original Message ----- From: "Sonnek, Ryan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
