[sakai2-tcc] [Building Sakai] UI frameworks WAS> Re: [Management] Gradebook Situation
Steve Swinsburg
steve.swinsburg at gmail.com
Thu Jul 29 17:46:57 PDT 2010
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"
More information about the sakai2-tcc
mailing list