Grouper Developers Forum

[David Langenberg <>]

+1

Dave

On Thu, May 10, 2012 at 10:58 AM, William G. Thompson, Jr. <> wrote:

Choice of frameworks is always best left to the folks having to use them. :)

That said, it's probably worth while to also consider
other-than-technical concerns.   For instance if a goal of the project
is to encourage participation and keep the bar to engagement low, you
might want to tend towards well-known and widely adopted approaches vs
internal anti-frameworks (even if they would win on strictly technical
merits).

Best,
Bill

On Mon, May 7, 2012 at 5:35 PM, Chris Hyzer <> wrote:
> 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=""#" > href="http://attributeUpdateRequestContainer.attributeDefToEdit.id" target="_blank">attributeUpdateRequestContainer.attributeDefToEdit.id}&action="${action}'); > return false;"
>
>               > >
>               > >
>               ><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
>
>

--
David Langenberg

Identity Management

The University of Chicago