[Building Sakai] Fwd: UI frameworks WAS> Re: [Management] Gradebook Situation

Robert Gérin-Lajoie robert.gerinlajoie at gmail.com
Fri Jul 30 07:05:28 PDT 2010 

---------- Forwarded message ----------
From: Robert Gérin-Lajoie <robert.gerinlajoie at gmail.com>
Date: 2010/7/30
Subject: Re: [Building Sakai] UI frameworks WAS> Re: [Management] Gradebook
Situation
To: Michael Wenk <mjwenk at ucdavis.edu>
Cc: Steve Swinsburg <steve.swinsburg at gmail.com>, "
management at collab.sakaiproject.org" <management at collab.sakaiproject.org>, "
sakai2-tcc at collab.sakaiproject.org" <sakai2-tcc at collab.sakaiproject.org>,
"Chambers, Sara J" <schamber at indiana.edu>, Jacques Raynauld <
jacques.raynauld at hec.ca>


Hi Michael,
here in Montreal we agree with you. We choose GWT back in version 1.4,
without using GWT Ext for various reasons, one of them beeing the licensing
issue. GWT excell in developping and deploying rich client side applications
as our OpenSyllabus project illustrate.

Now, with GWT 2.1 getting out, things are getting better and better, this is
a complete and integrated UI framework to work with.

The UIbinder and MVP approach, the new data presentation widget, the
debugging and tracer facility are all components of a global UI framework,
an Web 2.0 strenght one.

Robert Gérin-Lajoie
U. Montreal

2010/7/30 Michael Wenk <mjwenk at ucdavis.edu>

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
>
> _______________________________________________
> 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100730/0ccfe6d6/attachment.html

More information about the sakai-dev mailing list