[Building Sakai] UI frameworks WAS> Re: [Management] Gradebook Situation
Michael Wenk
mjwenk at ucdavis.edu
Thu Jul 29 22:52:10 PDT 2010
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/sakai-dev/attachments/20100729/54cd4644/attachment.html
More information about the sakai-dev
mailing list