I agree with you guys. If there were a lot to do, like invent a navigation system, manage complex page flow, etc, then lets use a framework.
However…
What is there now in the lite UI is easier than using spring webflow since we don’t need that stuff in this ajax application. There isn’t a lot of framework
code to maintain, understand, etc, and I can document what developers need to know in a concise wiki (well, we would need to do that with spring webflow too). The original Grouper Admin UI used your mindset with struts, and it is really difficult to debug
/ edit / enhance. The requirement of easy development has been taken into account in the lite UI and the 2.2 UI so the application is very straightforward for any java developer, not just spring webflow developers. Not to mention in 2 years there will be
a better web framework and you will be pestering me to change everything to that one.
J If anyone has tried to augment the lite UI, and has feedback Im happy to take that into account.
Shilen had some tasks in the lite UI and he had nothing but positive feedback and didn’t ask me any questions about it, just dove right in (easy to use)…
Bottom line is, we shouldn’t use frameworks just because they exist… we should use them if they help us out in some way, and in this particular case I don’t
think it is the case.
In the call yesterday we discussed this and decided to focus more on the front-end frameworks (yes, dhtml widget, css, tag library, and mobile etc frameworks
do help us out a lot!)…
Thanks,
Chris
From: David Langenberg [mailto:]
Sent: Thursday, May 10, 2012 1:10 PM
To: William G. Thompson, Jr.
Cc: Chris Hyzer;
Subject: Re: [grouper-dev] v2.2 UI tech stack
+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
The University of Chicago
|
