Dag Liodden wrote:
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
