[gradebook2-dev] Using gradebook2 outside

Jeffrey Miller.CTR Jeffrey.Miller.CTR at usuhs.mil
Wed Jul 6 17:01:46 PDT 2011


Right, a web service to extract grades from gradebook2 for a particular
site id. 

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


>>> John Bush <john.bush at rsmart.com> 7/6/2011 5:20 PM >>>
quartz jobs living in sakai is the place I was thinking about, so
falls into the sakai service/tool category

On Wed, Jul 6, 2011 at 2:17 PM, Thomas Amsler <tpamsler at ucdavis.edu>
wrote:
> What is the environment/context from where you would access the
> gradebook2 "external" service?
> e.g.
> - Other Sakai service/tool
> - External service that knows about Sakai site IDs
> - etc.
>
> In general, the gradebook2 "external" service caller would at least
> need the to provide the Sakai SiteId.
>
> Best,
> -- Thomas
>
>
>
> On Wed, Jul 6, 2011 at 9:11 AM, John Bush <john.bush at rsmart.com>
wrote:
>> 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
>>
>



-- 
John Bush
602-490-0470
_______________________________________________
gradebook2-dev mailing list
gradebook2-dev at collab.sakaiproject.org 
http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev

Classification:  UNCLASSIFIED 
Caveats: None



More information about the gradebook2-dev mailing list