[gradebook2-dev] Using gradebook2 outside

John Bush john.bush at rsmart.com
Wed Jul 6 09:11:07 PDT 2011


I think this is a reasonable approach.   I don't know the inner
workings enough to call out methods, but I could tell you from a use
case perspective what I think would be useful based on what people
have been asking for.

1.  Grade Auditing - if would be useful to be able to spider all
gradebook data and be able to store calcuated grades and final grades
with a date/version type thing.  This when if there are ever grade
disputes this data can be mined.
2.  Bulk submit final grades - some people do not want to rely on the
UI to push grades out.  This may be a flaw in how we designed some
exports, like perhaps the instructor needs to hit the button and this
goes into a staging table, and then export by a job from there.  But I
can see the use case, where folks want to completely get around UI,
and just have a one time job that exports everything across a term or
group of sites.

Maybe this helps start some thinking about how this external service
might be designed.

On Tue, Jul 5, 2011 at 7:33 PM, Thomas Amsler <tpamsler at ucdavis.edu> wrote:
> On Tue, Jul 5, 2011 at 7:22 PM, Jon Gorrono <jpgorrono at ucdavis.edu> wrote:
>> Generally, I think it's best to just share only Interfaces, if possible
>>
>> But there are some cases where we have good reason to have the same
>> code server and client.. some examples are the names to keys to
>> hashmaps for common data, which are based on enums right now... that's
>> hard code...
>>
>> To refactor the (GWT) component service into a sakai component
>> service, we *have to* put some stuff in shared/lib ... you can
>> accomplish most of  the effective goal quickly by moving the whole of
>> the gradebook2 shared module into shared/lib... maybe even package it
>> together with the api
>>
>> ideally we would want to slim down that as much as possible.
>>
>> My personal preference would be to take the same approach that
>> Berkeley took with the original Gradebook which was to create
>> public-facing services to provide specific functions that outside
>> tools would need and keep the Gradebook2ComponentService a service
>> which is strickly for the GB2 to use.
>
> +1
>
>>
>> That would mean creating a specific implementation of services for
>> what you need. If this means abstracting the calculation units to do
>> on-the-spot grade calculations, then IMO that would be a better area
>> of focus than abstracting the ('GWT') Component Service
>>
>>
>>
>> On Tue, Jul 5, 2011 at 10:38 AM,  <juanarcadio at um.es> wrote:
>>>  A problem ocurrs when moving the services to the PACK module, some
>>> methods are using objects from  org.sakaiproject.gradebook.gwt.client.*
>>> and to use this services from the outside it's necesary to move the
>>> interfaces imported in the api classes to API's module (refactoring),
>>> and for final classes it's necesary to create an interface in the API
>>> module.
>>>
>>>
>>>
>>> El 01/07/2011 22:18, Thomas Amsler escribió:
>>>> I haven't tried Juan's patch yet but it should work for
>>>> Gradebook2ComponentService as well.
>>>>
>>>> - Thomas
>>>>
>>>> On Fri, Jul 1, 2011 at 11:01 AM, Jeffrey Miller.CTR
>>>> <Jeffrey.Miller.CTR at usuhs.mil>  wrote:
>>>>> Just curious, has anyone else taken a look at Juan's patch or tried it?
>>>>> Could the same scheme be used for the Gradebook2ComponentService?
>>>>>
>>>>> Jeb Miller
>>>>> Contractor, HJF
>>>>> Academic Technology Directorate
>>>>> Uniformed Services University of the Health Sciences
>>>>> 4301 Jones Bridge Road
>>>>> Bethesda, MD  20814-4799
>>>>> 301-319-0442
>>>>>
>>>>>
>>>>> Classification:  UNCLASSIFIED
>>>>> Caveats: None
>>>>>
>>>>>
>>>>>>>> <juanarcadio at um.es>  6/30/2011 2:47 PM>>>
>>>>> Hi,
>>>>>
>>>>> I moved GradebookToolService to the new pack module. In the war module
>>>>> I
>>>>> set alias (to remain the same ids).
>>>>>
>>>>> I had a problem in db file with the sessionFactory, concretely with
>>>>> hibernate objects like
>>>>> "org/sakaiproject/tool/gradebook/Gradebook.hbm.xml". I've got traceback
>>>>>
>>>>> error when the tomcat starts.
>>>>>
>>>>> I tried to comment those lines and it was surprising, it seems to work,
>>>>>
>>>>> I don't know if the commented lines are from an early version that used
>>>>>
>>>>> hibernate directly, and now it uses the gradebook-service from
>>>>> edu-services.
>>>>>
>>>>> The tool seems to work like before, and now I can use the API in other
>>>>>
>>>>> tools.
>>>>>
>>>>> I attach a patch. I must to review it, but it could be a first
>>>>> approach
>>>>>
>>>>> cheers,
>>>>> Juan Arcadio.
>>>>>
>>>>>
>>>>>
>>>>> El 30/06/2011 18:44, Thomas Amsler escribió:
>>>>>> Please see inline comments bellow:
>>>>>>
>>>>>> I think we should be able to create a component service and
>>>>>> add GradebookToolService and Gradebook2ComponentService to it.
>>>>>>
>>>>>> On Thu, Jun 30, 2011 at 7:53 AM, John Bush<john.bush at rsmart.com
>>>>>> <mailto:john.bush at rsmart.com>>  wrote:
>>>>>>
>>>>>>      ug, I have the same need.  We need to run through all the sites
>>>>> in
>>>>>>      a term and export final grades, I thought I was going to be able
>>>>>>      to write a quartz job to do that, but realizing what you just
>>>>> said
>>>>>>      that won't be possible will it.  The name
>>>>>>      Gradebook2ComponentServiceImpl threw me cause its not a
>>>>> component
>>>>>>      or a service in the normal sakai sense anyway.
>>>>>>
>>>>>>
>>>>>> We are not doing a good job in naming/packaging things. As you guys
>>>>>> have figured out, some of the names are misleading and don't make
>>>>> much
>>>>>> sense.
>>>>>>
>>>>>> I think that we can create a "real Sakai" component service by
>>>>>> exposing the GradebookToolService and Gradebook2ComponentService
>>>>> APIs.
>>>>>> We also need to rename/refactor things so that they make sense w.r.t.
>>>>>> [DAO, Service, internal, external, client, server]
>>>>>>
>>>>>>
>>>>>>      Exposing this in a component module might take some refactoring,
>>>>>>      there are a bunch of org.sakaiproject.gradebook.gwt.client
>>>>>>      packages in there, it doesn't look like a clean separation to me.
>>>>>>
>>>>>> The above is one of the maning issues. For example the interfaces
>>>>> in:
>>>>>> org.sakaiproject.gradebook.gwt.client.model.*
>>>>>>
>>>>>> should just be called:
>>>>>>
>>>>>> org.sakaiproject.gradebook.gwt.model
>>>>>>
>>>>>> .. because there is a server and client specific implementation. The
>>>>>> same is true for:
>>>>>>
>>>>>> org.sakaiproject.gradebook.gwt.client.exceptions.*
>>>>>>
>>>>>> It would take same refactoring but I think this is a real need so
>>>>> that
>>>>>> folks can leverage existing gradebook2 services.
>>>>>>
>>>>>> Comments?
>>>>>>
>>>>>> -- Thomas
>>>>>>
>>>>>>      I'm at a loss here as well, I need something very quickly done,
>>>>>>      and this is looking like a much bigger engagement all of a
>>>>> sudden.
>>>>>>      On Thu, Jun 30, 2011 at 6:07 AM,<juanarcadio at um.es
>>>>>>      <mailto:juanarcadio at um.es>>  wrote:
>>>>>>
>>>>>>          Hi,
>>>>>>
>>>>>>              This is Juan Arcadio, from the University of Murcia
>>>>>>          (Spain), we are running Sakai 2.7.1 in limited production
>>>>>>          pilot  with Gradebook2 1.3.0 from September 2010, (we had
>>>>>>          translated this version of GB2 to Spanish), as soon as
>>>>>>          possible we will migrate to Sakai 2.8.0 with GB2 1.5.0
>>>>>>
>>>>>>              We are developing some custom tools that use gradebook,
>>>>>>          and we have had some communication problems with gradebook:
>>>>>>
>>>>>>              * Writing in gradebook: We cant do it when users have
>>>>>>                never acceded gradebook2 in that site, more info in:
>>>>>>                https://jira.sakaiproject.org/browse/GRBK-1059
>>>>>>
>>>>>>              * Reading from gradebook: Gradebook2 includes new
>>>>> features
>>>>>>                that can't be acceded using gradebook-service from
>>>>>>                indie. The API of Gradebook2 is not avilable outside
>>>>> the
>>>>>>                tool, Gradebook2 doesn't deploy any items in
>>>>> components
>>>>>>                and therefore the API can not be used from other tools
>>>>>>                in Sakai. We could try to expose the internal API with
>>>>> a
>>>>>>                component module.
>>>>>>
>>>>>>          Any suggestions? Anyone has face the same needs?
>>>>>>
>>>>>>          Best wishes,
>>>>>>          Juan Arcadio.
>>>>>>          --
>>>>>>
>>>>>>          _______________________________________________
>>>>>>          gradebook2-dev mailing list
>>>>>>          gradebook2-dev at collab.sakaiproject.org
>>>>>>          <mailto:gradebook2-dev at collab.sakaiproject.org>
>>>>>>
>>>>> http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>      --
>>>>>>      John Bush
>>>>>>      602-490-0470
>>>>>>
>>>>>>      _______________________________________________
>>>>>>      gradebook2-dev mailing list
>>>>>>      gradebook2-dev at collab.sakaiproject.org
>>>>>>      <mailto:gradebook2-dev at collab.sakaiproject.org>
>>>>>>      http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev
>>>>>>
>>>>> Classification:  UNCLASSIFIED
>>>>> Caveats: None
>>> _______________________________________________
>>> gradebook2-dev mailing list
>>> gradebook2-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev
>>>
>>
>>
>>
>> --
>> Jon Gorrono
>> PGP Key: 0x5434509D -
>> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
>> GSWoT Introducer - {GSWoT:US75 5434509D Jon P. Gorrono <jpgorrono - gswot.org>}
>> http{sysdev.ucdavis.edu}
>>
>



-- 
John Bush
602-490-0470


More information about the gradebook2-dev mailing list