[gradebook2-dev] Using gradebook2 outside
juanarcadio at um.es
juanarcadio at um.es
Mon Jul 11 00:20:15 PDT 2011
Hi,
I did it without writing new interfaces and without moving java classes,
only moving spring components and creating alias in webapp. I attach a
patch whit this.
To use this "gradebook2 services", in the component of an external tool
/ quartz job you should include this:
<property name="gradebookToolService">
<ref bean="org.sakaiproject.gradebook.components.GradebookToolService"/>
</property>
<property name="gradebookComponentService">
<ref
bean="org.sakaiproject.gradebook.components.Gradebook2ComponentService"/>
</property>
And in your IMPL module, you should include this dependencies:
<dependency>
<groupId>org.sakaiproject.gradebook2</groupId>
<artifactId>gradebook2-api</artifactId>
<version>1.5.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.sakaiproject.gradebook2</groupId>
<artifactId>gradebook2-model</artifactId>
<version>1.5.0</version>
<scope>provided</scope>
</dependency>
El 07/07/2011 7:50, Jon Gorrono escribió:
> If we can assume that the id's passed in for these services are
> gradebook uid's, then we could avoid some work... that is, we could
> avoid trying to guess how how to get the siteid-> gradebook uid
> handled in the most futuristic way.... and later: the current
> overloading makes it pretty simple, but we'll eventually have to
> rework that... and we *could* choose to avoid that rework for this new
> code if we just assume that incoming id's have already been reduced to
> individual gradebook uid's
>
> Just a thought.
>
> On Wed, Jul 6, 2011 at 5:01 PM, Jeffrey Miller.CTR
> <Jeffrey.Miller.CTR at usuhs.mil> wrote:
>> 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
>>
>> _______________________________________________
>> gradebook2-dev mailing list
>> gradebook2-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/gradebook2-dev/attachments/20110711/905e3401/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 79206 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/gradebook2-dev/attachments/20110711/905e3401/attachment-0001.jpe
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exposeAPI2.patch
Url: http://collab.sakaiproject.org/pipermail/gradebook2-dev/attachments/20110711/905e3401/attachment-0001.ksh
More information about the gradebook2-dev
mailing list