[sakai2-tcc] Roster2 to replace Roster

Matthew Jones matthew at longsight.com
Tue Sep 17 10:32:06 PDT 2013


It seems like this would ideally be part of entitybroker and not part of
kernel, since kernel doesn't actually have a webapp right? Then you
wouldn't have to worry about the xml/json/html feed types. I don't think it
would be a real entity though, just custom types.

Let me know once you get going, I'll review it and also contribute toward
some effort on that calendar.


On Mon, Sep 16, 2013 at 5:38 PM, Adrian Fish <adrian.r.fish at gmail.com>wrote:

> CLOG will benefit from the same approach as well. I can do the REST target
> in kernel if nobody else has time at present. I presume just a JSON feed of
> all the pairs for a particular sakai tool id, localised to the current
> user, will do the job? What about caching though? I presume that'll be
> abstracted away behind the resource loader call?
>
> Cheers,
> Adrian.
>
>
> On 16 September 2013 22:34, Adrian Fish <adrian.r.fish at gmail.com> wrote:
>
>> ... and I this one:
>>
>> https://jira.sakaiproject.org/browse/RSTR-62
>>
>>
>> On 16 September 2013 16:59, John Bush <jbush at anisakai.com> wrote:
>>
>>> I created this one:
>>>
>>> https://jira.sakaiproject.org/browse/KNL-1122
>>>
>>>
>>> On Mon, Sep 16, 2013 at 6:58 AM, Aaron Zeckoski <azeckoski at unicon.net>
>>> wrote:
>>> > It's more that the i18n data would load from the ResourceLoader (which
>>> > mostly means loading from the properties files in that vast majority
>>> > of cases and not from the database).
>>> > -AZ
>>> >
>>> > On Mon, Sep 16, 2013 at 9:49 AM, Adrian Fish <adrian.r.fish at gmail.com>
>>> wrote:
>>> >> If I read things correctly, yes. Roster2 will replace Roster in trunk
>>> if and
>>> >> when the i18n packs are loaded from the db. That will mean 2.10,
>>> think.
>>> >>
>>> >> Cheers,
>>> >> Adrian.
>>> >>
>>> >>
>>> >> On 16 September 2013 12:08, Neal Caidin <neal.caidin at apereo.org>
>>> wrote:
>>> >>>
>>> >>> Does this mean that some changes will be made to Roster2 and it will
>>> be
>>> >>> targeted for 2.10/Trunk?
>>> >>>
>>> >>> Thanks,
>>> >>> Neal
>>> >>>
>>> >>>
>>> >>>
>>> >>> Neal Caidin
>>> >>> Sakai CLE Community Coordinator
>>> >>> neal.caidin at apereo.org
>>> >>> Skype: nealkdin
>>> >>> Twitter: ncaidin
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sep 16, 2013, at 4:40 AM, Adrian Fish <adrian.r.fish at gmail.com>
>>> wrote:
>>> >>>
>>> >>> Alright, already ... :)
>>> >>>
>>> >>> If it's not JIRA'd, could one of you fine fellows raise a ticket? I
>>> like
>>> >>> Matthew's generic REST target idea; it does sound like people have
>>> done this
>>> >>> a couple of ways, so standardising going forward makes sense.
>>> >>>
>>> >>> Cheers,
>>> >>> Adrian.
>>> >>>
>>> >>>
>>> >>> On 13 September 2013 15:35, John Bush <jbush at anisakai.com> wrote:
>>> >>>>
>>> >>>> Right that is the other benefit, anyone who just talks in English
>>> and
>>> >>>> wants to change the instructional text on the site editor page...
>>> >>>> Problem solved.  Without that you end with forked nightmares, been
>>> >>>> there done that.
>>> >>>>
>>> >>>> On Fri, Sep 13, 2013 at 7:30 AM, Matthew Jones <
>>> matthew at longsight.com>
>>> >>>> wrote:
>>> >>>> > We are making heavy use of the dynamic translations. If you're
>>> just one
>>> >>>> > school, maybe it's not a huge time saver but it is for managing
>>> dozens.
>>> >>>> > Still the flexibility it gives for a single school (being able to
>>> put
>>> >>>> > up a
>>> >>>> > clarifications, warnings or new information immediately) is pretty
>>> >>>> > great. It
>>> >>>> > saves on a lot of code changes, keeping custom forks up dated and
>>> >>>> > providing
>>> >>>> > much quicker fixes. Even though there was a bug where it was
>>> going to
>>> >>>> > the DB
>>> >>>> > a lot more than expected (soon to be fixed in 2.9.x SAK-23887),
>>> it was
>>> >>>> > still
>>> >>>> > worth it to save on the code changes/redeploys. So i'd say having
>>> this
>>> >>>> > feature consistent for everything is a good thing.
>>> >>>> >
>>> >>>> >
>>> >>>> > On Fri, Sep 13, 2013 at 10:24 AM, Adrian Fish <
>>> adrian.r.fish at gmail.com>
>>> >>>> > wrote:
>>> >>>> >>
>>> >>>> >> There's also jquery's way:
>>> >>>> >>
>>> >>>> >> https://code.google.com/p/jquery-i18n-properties
>>> >>>> >>
>>> >>>> >> It uses standard java property files so translations can handled
>>> with
>>> >>>> >> the
>>> >>>> >> same tools. It doesn't solve the dynamic updating of i18n props
>>> >>>> >> though. How
>>> >>>> >> important is that though? How often do people actually need to
>>> >>>> >> dynamically
>>> >>>> >> update translations, and is it worth the overhead of hitting the
>>> db or
>>> >>>> >> cache
>>> >>>> >> to get them?
>>> >>>> >>
>>> >>>> >> Cheers,
>>> >>>> >> Adrian.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On 13 September 2013 15:10, John Bush <jbush at anisakai.com>
>>> wrote:
>>> >>>> >>>
>>> >>>> >>> There's at least one thing I'd like to see addressed.
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> https://source.sakaiproject.org/contrib/roster2/trunk/roster-app/src/webapp/roster-translations-ca.js
>>> >>>> >>>
>>> >>>> >>> I don't find that an acceptable way of doing localization.  Its
>>> not
>>> >>>> >>> consistent with the rest of Sakai, and it won't work with the
>>> dynamic
>>> >>>> >>> manipulation of bundles.  It makes it harder for anyone who is
>>> used
>>> >>>> >>> to
>>> >>>> >>> working with properties to maintain this stuff, since tools
>>> won't
>>> >>>> >>> support this arbitrary js format.
>>> >>>> >>>
>>> >>>> >>> It easy to address, I had to do it for gb2.  You need to just
>>> create
>>> >>>> >>> a
>>> >>>> >>> servlet that loads this the data from the ResourceLoader and
>>> then
>>> >>>> >>> transforms it into your javascript format.
>>> >>>> >>>
>>> >>>> >>> Also, I'd like verification that there aren't any FERPA issues
>>> >>>> >>> introduced.   I see
>>> https://jira.sakaiproject.org/browse/RSTR-16, but
>>> >>>> >>> its worth asking just to be sure.
>>> >>>> >>>
>>> >>>> >>> On Fri, Sep 13, 2013 at 6:54 AM, Steve Swinsburg
>>> >>>> >>> <steve.swinsburg at gmail.com> wrote:
>>> >>>> >>> > I proposed it years ago. Better integration, better support,
>>> more
>>> >>>> >>> > features, same UI as old roster tool.
>>> >>>> >>> >
>>> >>>> >>> > Cheers,
>>> >>>> >>> > S
>>> >>>> >>> >
>>> >>>> >>> > Sent from my iPad
>>> >>>> >>> >
>>> >>>> >>> > On 13/09/2013, at 23:45, Aaron Zeckoski <azeckoski at unicon.net
>>> >
>>> >>>> >>> > wrote:
>>> >>>> >>> >
>>> >>>> >>> >> Those notes were from the conference back in June and have
>>> just
>>> >>>> >>> >> been
>>> >>>> >>> >> slightly reorganized. I am not sure who proposed replacing
>>> roster
>>> >>>> >>> >> with
>>> >>>> >>> >> roster 2 but maybe that person can add the reasoning. I am
>>> not
>>> >>>> >>> >> aware
>>> >>>> >>> >> of anything myself.
>>> >>>> >>> >>
>>> >>>> >>> >> On Fri, Sep 13, 2013 at 9:31 AM, May, Megan Marie <
>>> mmmay at iu.edu>
>>> >>>> >>> >> wrote:
>>> >>>> >>> >>> I don’t see rationale in the notes.   Can you please provide
>>> >>>> >>> >>> something
>>> >>>> >>> >>> substantial for those of us not on the call?
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> From: sakai2-tcc-bounces at collab.sakaiproject.org
>>> >>>> >>> >>> [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On
>>> Behalf Of
>>> >>>> >>> >>> Neal
>>> >>>> >>> >>> Caidin
>>> >>>> >>> >>> Sent: Friday, September 13, 2013 7:37 AM
>>> >>>> >>> >>> To: sakai2-tcc at collab.sakaiproject.org 2
>>> >>>> >>> >>> Subject: [sakai2-tcc] Roster2 to replace Roster
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> From the TCC - CLECC call -
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> https://confluence.sakaiproject.org/display/TCC/TCC+CLE+Action+Items
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> For the folks on the call, there was consensus that Roster2
>>> >>>> >>> >>> should
>>> >>>> >>> >>> replace
>>> >>>> >>> >>> Roster for 2.10/trunk.
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Steve Swinsburg says this is not a lot of work to make
>>> happen.
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Consensus on this one?
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Cheers,
>>> >>>> >>> >>>
>>> >>>> >>> >>> Neal
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Neal Caidin
>>> >>>> >>> >>>
>>> >>>> >>> >>> Sakai CLE Community Coordinator
>>> >>>> >>> >>>
>>> >>>> >>> >>> neal.caidin at apereo.org
>>> >>>> >>> >>>
>>> >>>> >>> >>> Skype: nealkdin
>>> >>>> >>> >>>
>>> >>>> >>> >>> Twitter: ncaidin
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> _______________________________________________
>>> >>>> >>> >>> sakai2-tcc mailing list
>>> >>>> >>> >>> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>> >>
>>> >>>> >>> >>
>>> >>>> >>> >>
>>> >>>> >>> >> --
>>> >>>> >>> >> Aaron Zeckoski - Software Architect -
>>> http://tinyurl.com/azprofile
>>> >>>> >>> >> _______________________________________________
>>> >>>> >>> >> sakai2-tcc mailing list
>>> >>>> >>> >> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>> > _______________________________________________
>>> >>>> >>> > sakai2-tcc mailing list
>>> >>>> >>> > sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>> --
>>> >>>> >>> John Bush
>>> >>>> >>> 602-490-0470
>>> >>>> >>>
>>> >>>> >>> ** This message is neither private nor confidential in fact the
>>> US
>>> >>>> >>> government is storing it in a warehouse located in Utah for
>>> future
>>> >>>> >>> data mining use cases should they arise. **
>>> >>>> >>> _______________________________________________
>>> >>>> >>> sakai2-tcc mailing list
>>> >>>> >>> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> _______________________________________________
>>> >>>> >> sakai2-tcc mailing list
>>> >>>> >> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>
>>> >>>> >
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> John Bush
>>> >>>> 602-490-0470
>>> >>>>
>>> >>>> ** This message is neither private nor confidential in fact the US
>>> >>>> government is storing it in a warehouse located in Utah for future
>>> >>>> data mining use cases should they arise. **
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> sakai2-tcc mailing list
>>> >>> sakai2-tcc at collab.sakaiproject.org
>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> sakai2-tcc mailing list
>>> >> sakai2-tcc at collab.sakaiproject.org
>>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>> > _______________________________________________
>>> > sakai2-tcc mailing list
>>> > sakai2-tcc at collab.sakaiproject.org
>>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>
>>>
>>>
>>> --
>>> John Bush
>>> 602-490-0470
>>>
>>> ** This message is neither private nor confidential in fact the US
>>> government is storing it in a warehouse located in Utah for future
>>> data mining use cases should they arise. **
>>>
>>
>>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130917/736ac312/attachment-0001.html 


More information about the sakai2-tcc mailing list