[sakai2-tcc] [Building Sakai] UI frameworks WAS> Re: [Management] Gradebook Situation
Steve Swinsburg
steve.swinsburg at gmail.com
Fri Jul 30 00:48:27 PDT 2010
Hi Mike,
I wasn't commenting on the viability of GWT as a framework, just remarking on the comment that since GWT is mentioned the most then that implies everyone is using it and hence it's the most obvious candidate. FWIW, Wicket can do all those items you mentioned as well and one could argue that since two core tools are using Wicket, then it is the most obvious choice.
Mark made a valid point earlier that this discussion has gone on for years and never reached consensus so I doubt it will reach consensus again, without losing developers. If one framework was chosen, what's to stop someone from creating the hooks necessary to develop in another framework.
I'm especially interested in a decent review of these frameworks, that is, if a server side framework is a direction we want to take, considering the long history of Sakai 3 apps being client side.
cheers,
Steve
On 30/07/2010, at 3:52 PM, Michael Wenk wrote:
> Steve,
>
> I don't know if anyone's recommending Ext GWT, which is the library with the licensing issue. However, the only reason we went with it was the fact that we needed a spreadsheet style grid, and it was really the only choice at the time for various reasons. Now, there's at least two candidates out there, quite possibly more.
>
> Anyways, I would not recommend Ext GWT for various reasons, and they are not related to its license. That being said, I would specifically recommend GWT itself. Why? Flexibility. It will let you do almost anything. Want to develop your app like a web page? Easy. Want to develop it like a desktop app? Easy. Want to just to a few parts of your app in java, and the rest in javascript? Yep, real easy.
>
> However the major reason I would recommend it is the tools that it gives you. Hosted or Developer mode is amazing. It lets you do a combined client/server debug which I have not seen in any other tool. And its fast. Want to change something in the client? Change the file, click save, and then refresh the browser. Boom, you're running. That and Speed Tracer are very useful. The dev cycle is extremely fast and it for the most part interacts well with things like Firebug and the like.
>
> Many of the choices made with GB2 were done in GWT 1.4/1.5 and back then, I would have probably not recommended GWT. However with version 2.0 and likely 2.1 I would strongly recommend it. Its awesome, works great and produces incredibly efficient code.
>
> Mike
>
>
> On Thu, Jul 29, 2010 at 5:46 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> It would be dangerous to just go with GWT because that is most talked about. AFAICT, the reason GWT gets so much attention is because of this licensing problem with a plugin, which is hardly a positive for it. And then we'll end up with the JSF mess again.
>
> I'd be very interested in participating in a proper review process for a server side framework, in my mind Apache Wicket is a very viable option and we have several tools written in it already (SiteStats, Profile2 and a number of contrib ones).
>
> All that aside, if Sakai 3 is all about the client side, might be a moot discussion.
>
> cheers,
> Steve
>
>
>
> On 30/07/2010, at 9:51 AM, Chambers, Sara J wrote:
>
> > Thanks Eli. My concern is not about coming up to speed on whatever technology stack and application architecture is selected, I'm mostly voicing an interest in having a set of pros and cons that are vetted thru a technology group made up of at least the contributing institutions. S3 may be far enough along to do this in one fell swoop. And then again as new tecnologies are considered. Same sort of thing for S2. Its the vetting process I'm mostly interested in. Maybe we have an informal process in place already that just needs to be communicated/formized (for both code lines).
> >
> > Sjc
> >
> > --------------------------
> > Sent from my BlackBerry Wireless Device
> >
> >
> > ----- Original Message -----
> > From: Eli Cochran [mailto:eli at media.berkeley.edu]
> > Sent: Thursday, July 29, 2010 05:41 PM
> > To: Chambers, Sara J
> > Cc: Eli Cochran <eli at media.berkeley.edu>; 'michael.feldstein at oracle.com' <michael.feldstein at oracle.com>; 'markjnorton at earthlink.net' <markjnorton at earthlink.net>; 'management at collab.sakaiproject.org' <management at collab.sakaiproject.org>; 'sakai2-tcc at collab.sakaiproject.org' <sakai2-tcc at collab.sakaiproject.org>; 'sakai-dev at collab.sakaiproject.org' <sakai-dev at collab.sakaiproject.org>
> > Subject: UI frameworks WAS> Re: [Management] [Building Sakai] Gradebook Situation
> >
> > The curious thing about Sakai 3 is that it doesn't have a server-side UI framework at all. The UI is built using client-side technologies which makes sense since the UI is, after-all, presented on the client.
> >
> > Sakai 3 uses a collection of client-side JS, HTML and CSS libraries that work together very well, an interesting mix of jQuery, jQuery UI, various jQuery plug-ins, TrimPath, Fluid, etc. Not a formal framework, but in the process of building the product, a client-side framework is emerging, one that is homegrown and tightly tied to the needs of the project.
> >
> > I know that there is concern that many institutions are heavily invested in JAVA and do not have front-end coding skills. But having worked now with a number of JAVA developers who have made the switch to client-side coding, the switch is not that difficult. The Javascript language is very mature and very well understood (both it's strengths and weaknesses) and it's easy to find good books, and other resources that can get a smart programmer up to speed.
> >
> > - Eli
> >
> > On Jul 29, 2010, at 12:28 PM, Chambers, Sara J wrote:
> >
> >> I agree that we should have one sever side ui framework and one for the client side. More importantly one standard toolset covering the entire application architecture (obviously S2 amd S3 will have differences). Seems we should articulate the pros and cons of each option and pull together a technical committee to make the selection. Actually IU would like to see a tech committee established to vet all technology decisions for Sakai and especially for S3 since that's our future. The contributing community is too finite to further divide contributors by multiple tools at the same level in the architecture. I'm personally not opposed to client side and server side UI dev but believe we should have one agreed upon toolset for each. IU is not a GWT shop but if the Sakai technology committee decided that was going to be the standard tool going forward for example, then we would come up to speed on it. What we don't want to do is support multiple tools at each level and/or be
> >> locked out of making local customizations because a tool or service was developed in a "non-standard" toolset. Just my .02
> >>
> >> Sara
> >> --------------------------
> >> Sent from my BlackBerry Wireless Device
> >>
> >>
> >> ----- Original Message -----
> >> From: Michael Feldstein [mailto:michael.feldstein at oracle.com]
> >> Sent: Thursday, July 29, 2010 01:48 PM
> >> To: markjnorton at earthlink.net <markjnorton at earthlink.net>
> >> Cc: Managers <management at collab.sakaiproject.org>; sakai2-tcc <sakai2-tcc at collab.sakaiproject.org>; Sakai Developers <sakai-dev at collab.sakaiproject.org>
> >> Subject: Re: [Management] [Building Sakai] Gradebook Situation
> >>
> >> Not for the principle UI framework, but for the principle *server-side* UI framework. Many of the participating Sakai 3 schools are moving toward client-side development, but not all. Of those that are not, the server-side framework I hear mentioned the most is GWT these days. I have no strong opinion (and certainly no expert opinion) on which server-side framework would be best, but just from a skillset management perspective, I think we do need to make allowances for shops that don't have strong client-side development skills to be able to contribute.
> >>
> >> - m
> >>
> >>
> >> --
> >> Oracle
> >> Michael Feldstein | Principal Product Manager
> >> Phone: +1 8188172925 | Mobile: +1 9179218895
> >> Oracle Academic Enterprise Solutions
> >> 25 Christian Hill Road | Great Barrington, MA 01230
> >>
> >> Green Oracle Oracle is committed to developing practices and products that help protect the environment
> >>
> >> -----Original Message-----
> >> From: Mark Norton [mailto:markjnorton at earthlink.net]
> >> Sent: Thursday, July 29, 2010 1:22 PM
> >> To: Michael Feldstein
> >> Cc: Clay Fenlason; Noah Botimer; Managers; sakai2-tcc; Sakai Developers
> >> Subject: Re: [Building Sakai] [Management] Gradebook Situation
> >>
> >> On 7/29/2010 1:05 PM, Michael Feldstein wrote:
> >>> I personally think it's very important for us to support one (though preferably only one) server-side UI framework in Sakai 3, and GWT is the obvious candidate.
> >> Why would you nominate GWT for the principle UI framework? My experience with it is that it is brittle and hard to debug. I also note that Kuali Student went down the GWT path and is now moving to something else (TBD). Isn't Sakai moving away from a server side framework towards RESTful interfaces like JSON?
> >>
> >> Sadly, I really don't think we are going to agree on a UI framework.
> >> We've had discussions on this topic for YEARS without resolution.
> >>
> >> -1 for GWT.
> >>
> >> FWIW, Mark Norton
> >>
> >>
> >>
> >>
> >>
> >> =======
> >> Email scanned by PC Tools - No viruses or spyware found.
> >> (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15540) http://www.pctools.com/ =======
> >> _______________________________________________
> >> management mailing list
> >> management at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/management
> >>
> >> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> >> _______________________________________________
> >> management mailing list
> >> management at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/management
> >>
> >> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> >
> > . . . . . . . . . . . . . . . . . . .
> >
> > Eli Cochran
> > manager of user experience
> > user interaction developer
> > ETS, UC Berkeley
> >
> > "Do not solve the problem that’s asked of you. It’s almost always the wrong problem."
> > - Don Norman
> >
> >
> >
> >
> > _______________________________________________
> > sakai-dev mailing list
> > sakai-dev at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >
> > TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>
> --
> Michael Wenk
> mjwenk at ucdavis.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100730/d4a683af/attachment-0001.html
More information about the sakai2-tcc
mailing list