Aha! My plan worked! I knew if I abandoned that long enough someone would make it look nice!
I need to read through this in more detail, but is it possible to have it not render the graphs if you don't have the other package (i.e. just have the nice tables, etc) and have the graphs if you do have the graphing package? I'd like for the config browser to be an example drop-in component you can use in any WW2 application and not have any more library dependencies. Great work! Jason > -----Original Message----- > From: Dag Liodden [mailto:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 4:29 PM > To: [EMAIL PROTECTED] > Subject: [OS-webwork] A new WebWork result, improvements to > the config-browser etc > > > Hi all! > > Today, instead of doing what I should have been doing, I had > a look at > the the config-browser app which seemed a little bit lonely and > abandoned. :) I thought it would be a good idea to have some sort og > visual representation of the namespaces, results and > interceptors in an > xwork package. So I decided to have a look at the JGraph > (http://jgraph.sourceforge.net) package and see if it would do. There > are no taglibs for JGraph, but there are some bits and pieces of code > which parse gxl-documents (Graph eXchange Language) and > renders them. I > ripped some of this out and created a new ResultType which > takes input > from a velocity template to create xml and renders the graph. > Actions with this resulttype can be included the src of > <img>-tags. The > new config-browser (styled with Tigris style-code) is > actually looking > quite good now (although, the layout algorithm isn't very good and > things are a bit cluttered - but hey, they're pluggable in JGraph :)) > > I have some screens posted at http://www.liodden.no/webwork > > For instance, to render a specific action with directed edges to it's > results, this is what's needed in the Velocity template: > > <!-- Macro defs --> > #macro(action $name) > <node id="$name" bgcolor="ff0000"> > <attr name="Label"> > <string>$name</string> > </attr> > </node> > #end > > #macro(result $r) > <node id="$r.name" bgcolor="0000ff"> > <attr name="Label"> > <string>$r.params.get("location")</string> > </attr> > </node> > <edge id="res-$r.name" from="$actionName" to="$r.name"> > <attr name="Label"> > <string>on $r.name</string> > </attr> > </edge> > #end > > <!-- The acutal code --> > <gxl><graph> > #action($actionName) > #foreach ($r in $config.results) > #result($r) > #end > </graph></gxl> > > I'm not sure I've used the most optimal approach to implement the > result-type, though. I need to get the Velocity template > parsed in the > appropriate context and then pass on the result while avoiding the > VelocityResult to write to the Response. So I've subclassed > VelocityResult, set the content-type on the response (so > VelocityResults's efforts to set it to text/html are ignored), pass a > PageResponse-wrapper to the rest of the chain to do it's work on: > > public void doExecute(...) > HttpServletRequest request = ServletActionContext.getRequest(); > HttpServletResponse response = ServletActionContext.getResponse(); > > PageResponse wrapper = new PageResponse(response); > > ServletActionContext.setResponse(wrapper); > response.setContentType(CONTENT_TYPE); > super.doExecute(finalLocation, invocation); > > // Do the rendering on wrapper.getContent() which will > contain the > nicely parsed velo-result > > This does seem a bit akward, but was the only way I figured out to do > this... This technique (or a better one), could be very > useful for a lot > of other result-types too. I actually like producing XML with > Velocity, > so e.g a JasperReports / Velocity integration would be very easy to > implements. The code above could be put into a utility class so other > result-types could just call > UtilClass.giveMeTheVelocityResultForThisInvocation() and take > it from there. > > What do you think? > > Cheers, > > Dag > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation > Program. Do you like what SourceForge.net is doing for the > Open Source Community? Make a contribution, and help us add > new features and functionality. Click here: > http://sourceforge.net/donate/ > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
