Grouper Developers Forum

[Chris Hyzer <>]

TomB has something in his schedule about UI tech stack, so here is the email thread about it.

 

To start, I would mention that I think we should focus on the usability of the UI and not the underlying technologies.

 

That said, J I would like to keep it the same as the current lite UI, which is Ajax, Java, with an internal anti-framework that addresses issues that I have seen with maintaining struts/spring/etc frameworks.  The problem with the admin UI was that it was hard to tell from the JSP source which Java method was being called.  When there is indirection from the view to the controller, this can be a problem.  However, it is possibly less easy to customize.  Here is an example.  This is JSP source from the lite UI:

 

              <a href="#" onclick="ajax('SimpleAttributeUpdate.editAction?attributeDefToEditId=${attributeUpdateRequestContainer.attributeDefToEdit.id}&action="${action}'); return false;"

              onmouseover="Tip('${grouper:escapeJavascript(navMap['simpleAttributeUpdate.editActionImageAlt'])}')"

              onmouseout="UnTip()"

              ><img src="../../grouperExternal/public/assets/images/application_edit.png" height="14px" border="0"

              alt="${attributeUpdateRequestContainer.text.editActionImageAlt }"/></a>

 

You can easily see that the SimpleAttributeUpdate class and editAction method will be called when this link is clicked.  No need to dereference a navigation file(s) or controller class.  It is not a free-for-all though, due to security.  The classes must be in the whitelisted package, and the methods must have a certain signature, and it must be a post (or a whitelisted get).  Most of the lite UI and proposed 2.2 UI will not be flow-like, but rather, will be random access ajaxy, so I don’t think webflow makes sense (in addition that there is indirection between the view and java class).  If there are customizations, we could take some requirements and make it happen, let me know specifically what people are interested in above and beyond just patching the code which would not be too difficult.

 

There is also no function-specific _javascript_ here, it is all in the framework.  So the java on the other side can do things on the screen without _javascript_:

 

e.g. add an alert popup:

 

        guiResponseJs.addAction(GuiScreenAction.newAlert(GrouperUiUtils.message("simpleAttributeUpdate.errorCantEditAttributeDef", false)));

 

e.g. replace a div with a JSP:

 

      guiResponseJs.addAction(GuiScreenAction.newInnerHtmlFromJsp("#bodyDiv",

        "/WEB-INF/grouperUi/templates/simpleAttributeUpdate/simpleAttributeCreateEditInit.jsp"));

 

This is sort of like the architecture of GWT but not quite.  The key is that we don’t have to maintain _javascript_ (except for the framework) for each function.

 

Anyways, I would like to keep this architecture because it is working very well, it is easy to develop with, it is easy for people who don’t know it to maintain it, it would be consistent with the current UI (which we will still maintain for at least a little while), and it would make the UI have the ability to be delivered sooner than if we start from scratch.  Shilen, the other UI developer for 2.2, has reviewed it briefly and said it was a good direction (if not correct me J ).

 

As far as ajax frameworks, until now we have used dhtmlx and jquery (among other things), but I think we should try to switch to dojo (and jquery when useful)) if not too much trouble, and if it is a problem for some reason, then stick with dthmlx or jquery-ui.

 

Thoughts?

 

Thanks,

Chris