Page tree
Skip to end of metadata
Go to start of metadata

Date

Angular meeting

Attendees

Notes

Slack Logs (times are all CST)

Tim Donohue [10:57 AM]
@here: just a friendly reminder that our next DSpace 7 UI Meeting starts shortly (top of the hour). The first 30 mins are in #angular-ui (and cover Angular UI updates). The second 30mins are in #rest-api (and cover REST API updates).

[11:00]
@here: It's now meeting time. As usual, we'll kick things off with Angular UI updates in this channel.

[11:01]
I don't have any updates to report on my end, but will hand this over to @art-lowel to kick us off.

Matteo Perelli [11:01 AM]
Hello!


Art Lowel [11:01 AM]
Hi

[11:01]
So a few updates this week:

[11:01]
first of all: the yarn PR has been merged

[11:01]
Originally the quick install docs relied on npm installing yarn as a global dependency (edited)

[11:02]
and the regular docs said to install yarn using their installer (because the yarn team discourages you from using npm to install it)

[11:02]
To be consistent, I removed yarn from the global npm dependencies, and added it as a requirement.


[11:02]
you can find installation instructions for your platform here:

[11:02]
https://yarnpkg.com/lang/en/docs/install/
yarnpkg.com
Yarn
Fast, reliable, and secure dependency management. (64KB)

Tim Donohue [11:03 AM]
Is this something worth revisiting later on? Wondering if we'll find the extra dependency to be problematic in the long term...or if it'll hopefully be worth it (as yarn is faster, etc)

Art Lowel [11:03 AM]
I don’t think it’s really a problem

[11:04]
the install is super simple

[11:04]
(a single command in unix systems)

[11:04]
and an installer for windows

Tim Donohue [11:04 AM]
Gotcha. Yes, I'm not implying we need to do anything now. Just noting we should keep this in mind in case we hit issues/complaints :wink:

[11:04]
So, for now, this all seems great

Matteo Perelli [11:04 AM]
I've tried it and seems good

Art Lowel [11:04 AM]
:y::skin-tone-3:

[11:04]
The rest services PR has been merged as well.


[11:05]
Here's what you need to know to use it:

[11:05]
- There is a DataService for each type of DSpaceObject.

[11:05]
(at the moment only ItemDataService and CollectionDataService, but making an additional one boils down to filling in the endpoint URLs.)

[11:05]
- These data services ensure resources get fetched from the rest api (the _mock_ rest api at this point), and stored in the ngrx store.

[11:05]
- The find methods in the DataServices return RemoteData objects

[11:06]
- RemoteData objects contain the status of the request (loading/failed/succeeded) and the data (or error message), as observables.

[11:06]
The following gist shows how you would use it in practice:

[11:06]
https://gist.github.com/artlowel/1826582c47e11ff3cb01c8b0946de593

[11:06]
In the component I specify that `collectionData` has the type `RemoteData<Collection[]>`

[11:06]
In the OnInit: `this.collectionData = this.cds.findAll();`

Tim Donohue [11:07 AM]
:arrow_up: It'd be great to add these tips/hints into a Wiki or README somewhere, if they aren't there already

Art Lowel [11:07 AM]
I will

Tim Donohue [11:07 AM]
Excellent, thanks!

Art Lowel [11:07 AM]
… and in the template, handle the different cases:

[11:07]
dedicated messages for `isLoading` and `hasFailed`
and the actual data for `hasSucceeded`

[11:07]
(of course in a more realistic scenario you might send the error to a notification service instead of handling it yourself)

[11:08]
The `async` pipe allows you to use observables in the template as if they were plain objects.

[11:08]
Because of the observables, the template will update automatically if the data in the store gets updated.


[11:08]
e.g. if a collection from this list is requested using a findById, and its short description has been changed on the server. Then the shortDescription field in this list will update as well.

Tim Donohue [11:09 AM]
Nice, this is sounding great. The example gist you linked to is also very helpful to "see" how this all looks

[11:10]
(And, as a sidenote, more of those would be useful going forward...either in gists or in links to actual code, once that gets going)


Art Lowel [11:10 AM]
true

[11:10]
Last time we agreed that if no progress had been made in the spinner PR that we'd accept it as is.

[11:11]
but I propose that for now we keep our options open:

[11:11]
we don't hide a page until everything is loaded

[11:11]
but we do have a LoadingService that needs to be notified if any component on a page is waiting for a result

[11:11]
because in general I think it's a good idea to have a canonical answer to the question: "has everything finished loading?"

[11:11]
and that way we can still choose to implement a spinner or a loading bar for the entire page later on.

[11:11]
OK?


Tim Donohue [11:12 AM]
notes it looks like @wwelling and @jcreel256 aren't around today (as I know they were tasked with looking at the Spinner PR: https://github.com/DSpace/dspace-angular/pull/43)

Hardy Pottinger [11:12 AM]
Spinner feels a bit like the final coat of paint, honestly

Tim Donohue [11:13 AM]
Sounds reasonable to me as well for now. Does this mean we just keep the spinner open for feedback? Are we closing it for more discussion?

Art Lowel [11:13 AM]
I think I better close the current issue, and write a new one with the proper explanation of the idea (edited)

[11:13]
Lotte won’t mind :wink:

[11:14]
(she wrote the current PR)

Tim Donohue [11:14 AM]
Yes, that's what this sounds like to me as well. A new discussion / proposal ticket sounds like the right direction (& closing current PR). We can always reuse/borrow Lotte's code later as needed

Art Lowel [11:14 AM]
indeed

Tim Donohue [11:15 AM]
Sounds like excellent progress since last week (in general)

Art Lowel [11:15 AM]
This was all I had though

Antoine Snyers [11:16 AM]
so is the issue still open to discuss the rest-services now that the PR is merged?

Art Lowel [11:16 AM]
I’ll definitely keep the current issue open until the tests and docs are all there


[11:17]
for big changes to the way things work, I think we better open separate issues

Tim Donohue [11:17 AM]
agreed

[11:18]
Looking at the "Ready" column in our Waffle, are there more UI tickets we can now create? (I just see the Collection homepage): https://waffle.io/DSpace/dspace-angular

Art Lowel [11:18 AM]
yes

[11:18]
so I’ll be working on creating those as well in the next week

Tim Donohue [11:19 AM]
excellent! So, this is a great opportunity for all @here to start to create actual, visible UI screens! Anyone is obviously welcome to claim these tickets or play around a bit to see what you come up with (and ask for help as needed)


[11:20]
And, we've got a good example in https://github.com/DSpace/dspace-angular/issues/63 of what this work will look like

[11:21]
Do we have any other questions or comments here regarding next steps on the Angular UI work? Anyone interested in volunteering now to look at starting to create specific UI components?

Hardy Pottinger [11:22 AM]
tdonohue made me look, using the word "example" :slightly_smiling_face:


Tim Donohue [11:23 AM]
Since we have some extra time here, I'll take this opportunity to mention that the DSpace Steering Group has given us (DuraSpace) the go ahead to create a *new DSpace logo* (in prep for DSpace 7). We are currently running a competition on 99designs.com, and will be sharing & allowing all you to vote on the results (to select the new logo)

[11:25]
The logo competition ends next week, and we'll do some initial narrowing from the 50ish options we will get to some good candidates, and then open up the voting process to everyone. We'll see where that takes us, and the final decision will be made based on votes & with consultation with DSpace Steering (edited)

Art Lowel [11:25 AM]
can you link to the competition?

Tim Donohue [11:25 AM]
is looking for the link

Tim Donohue [11:27 AM]
Here it is. Keep in mind, there's a LOT here...and we will cut this list down before voting (so none of these are guaranteed to be in the vote quite yet): https://99designs.com/logo-design/contests/design-logo-popular-open-source-repository-software-world-705894/entries?utm_swu=8976

[11:27]
But, that said, we have some nice looking candidates so far

[11:27]
(and some others that are obvious no's...at least to me)

[11:28]
You are welcome to send me feedback on this list already if you see a few you really hope will be in the vote. But, the contest isn't final yet, so more will be coming in.

[11:29]
And if we decide that none of these are "great", we do have that option to redo the contest (pending Steering approval of course, as it costs $$)

[11:29]
But, we are nearing the end of our first 1/2 hour here...so, we probably shouldn't comment on logos here :slightly_smiling_face: Feel free to ping me later though via slack or email

Art Lowel [11:30 AM]
Thanks for the info though, it was news to me

Hardy Pottinger [11:30 AM]
neat

Tim Donohue [11:31 AM]
It's all "new" since last week... we only kicked off this competition last week...though we had approval to do so earlier (and I didn't want to say much until we decided how to do select the logo)

[11:31]
Ok, with that, we are into the second 1/2 hour. Let's move this over to #rest-api

Mark Wood [12:04 PM]
I presume that someone will ensure that we don't wind up with a design that is too close to any owned by dSPACE. (You know: the other one.)

Tim Donohue [12:05 PM]
@mwood: Yes, we'll keep an eye out for that. Their logo is rather simple though: https://www.dspace.com


REST meeting

Attendees

Notes:

Slack Logs (times are all CST)

Tim Donohue [11:31 AM]
Ok, we're into the second 1/2 hour. Time for REST API updates :wink: Take it away, @bollini

Terry Brady [11:32 AM]
Hello

Andrea Bollini [11:32 AM]
we have great progress this week thanks to @mwood and @terrywbrady


[11:32]
https://jira.duraspace.org/browse/DS-3482

[11:33]
has been solved. It was about the build process

[11:33]
now our rest7 branch build successful on Travis and this give us much more confidence accepting change also in dspace-api

Tim Donohue [11:34 AM]
Big thanks to @mwood for that one :clap:

Andrea Bollini [11:34 AM]
there are still some issue with dependencies but these have been moved to a separate ticket https://jira.duraspace.org/browse/DS-3524

[11:35]
if I understand correctly @mwood has already started some investigation so he could be interested to assign the new ticket

Mark Wood [11:35 AM]
I will take a look at it

Tim Donohue [11:36 AM]
Thanks, @mwood


Andrea Bollini [11:36 AM]
now the question is should we immediately move to the master? or what...

Tim Donohue [11:37 AM]
That was the question I was also planning to ask today, @bollini :slightly_smiling_face: Is there any reason why we *shouldn't* move REST API development over to `master`? I'd lean towards moving ASAP now that Travis can validate PRs for us

Mark Wood [11:38 AM]
We can always branch again if we need to break something for an extended period.

Terry Brady [11:38 AM]
The master branch isn't serving any other purpose. I say go for it

Andrea Bollini [11:38 AM]
I'm sure that we will make dramatic changes to the rest7 webapp over the next months but this will be always true

[11:38]
so for me, we should move to the master

Mark Wood [11:39 AM]
We can break rest7 without disrupting general work, because nobody but us is using it yet.


Andrea Bollini [11:39 AM]
this is my idea as well

Mark Wood [11:39 AM]
And the longer we stay branched, the harder it is to merge.

Tim Donohue [11:40 AM]
Ok, let's vote. Add a :+1: to this if we should move to `master`. Add a :-1: if you think we stay on `rest7`


Andrea Bollini [11:40 AM]
how simple it is?

Tim Donohue [11:41 AM]
There we go. Looks like we move over to `master`. It seems like it shouldn't be hard to switch to `master`...just create a PR against `master` from `rest7`. The only question in my mind is whether any PRs currently against `rest7` should be merged before or after moving to `master`

Andrea Bollini [11:41 AM]
I propose after starting from https://github.com/DSpace/DSpace/pull/1666

Tim Donohue [11:42 AM]
That's fine by me, as long as the PR shouldn't make the merge to master more difficult (doubtful, but you'd know better than I do, @bollini)

Andrea Bollini [11:43 AM]
no sorry, I mean. We merge to the master now


Tim Donohue [11:43 AM]
oh, sorry. I misread your previous statement :slightly_smiling_face:

Andrea Bollini [11:43 AM]
I will open the PR to merge rest7 in the master just after the meeting @tdonohue you will merge ok?

Tim Donohue [11:44 AM]
Sounds good to me. That will mean that @terrywbrady will need to recreate PR 1666 against master (but it shouldn't be hard to do, just need to make that PR against a different branch now)

Terry Brady [11:44 AM]
Will do

Tim Donohue [11:44 AM]
Yes, @bollini I'll merge it right after Travis approves :slightly_smiling_face: (edited)

Andrea Bollini [11:44 AM]
ok. The other update is about the Rest contract

[11:45]
our initial draft https://github.com/DSpace-Labs/Rest7Contract/pull/4 have some comments from @terrywbrady

[11:45]
I will update the pr with the missing pieces right after the meeting, more detailed discussion should happen on dedicated issue

[11:45]
do you agree?


Tim Donohue [11:46 AM]
Yes, detailed discussions likely need separate issues. It'd be good to just get the basics merged and work from there

Andrea Bollini [11:47 AM]
ok so I will wait for 1 extra days after this additions before to merge

[11:47]
in this way we can start to propose pr, open discussion etc. on the rest7contract


[11:48]
ok, last news is about https://jira.duraspace.org/browse/DS-3513

[11:48]
Provide an entry endpoint that exposes the known endpoints via the HAL browser

Terry Brady [11:48 AM]
For now, I would support frequent merges to the contract. Once it has more details, we may want more close reviews


[11:49]
I put some questions into that ticket. I am using this ticket as an opportunity to understand the framework better.

Tim Donohue [11:49 AM]
I agree with @terrywbrady here that getting the basics/"framework" of the contract quickly is important (and need not wait for close reviews). This should be a "living" document

Andrea Bollini [11:49 AM]
@terrywbrady has started some work on that, I will provide a feedback by tomorrow

[11:51]
I don't have other updates for this week. Do you have anything that you want to discuss? maybe we can talk a bit more about DS-3513

Terry Brady [11:51 AM]
@bollini , thanks. I am finding that many of the methods assume that you have retrieved a DSO from the database. I am trying to write a REST endpoint that is not tied to a specific DSO and I am finding the accessibility of methods a challenge.

Andrea Bollini [11:52 AM]
this is just the initial implementation so we can move any methods that we need to reuse to support/utility classes

[11:53]
the only thing that make me worry about your current approach is the overcomplexity added to the restcontroller

[11:53]
I think that it is much easier just add a separate controller for this task

Terry Brady [11:54 AM]
Ah, I was not aware that there could be more than one.

[11:54]
That makes sense to me.

Mark Wood [11:54 AM]
Please, someone note that in the issue.


Andrea Bollini [11:54 AM]
when I say that we want to centralize all the request over a common controller I mean to use inheritance

Terry Brady [11:55 AM]
Does it make sense to generate Link objects inside of the Info object that I have proposed? I would like for a user to go to /api and see HAL links to all of the known endpoints: /api/core/items, /api/core/collections, etc

Andrea Bollini [11:56 AM]
I will provide you the initial implementation, the challenge of this specific ticket is to find a smart way to automatically build all of these links

Terry Brady [11:56 AM]
Sounds good. I appreciate it!

Andrea Bollini [11:56 AM]
I want our /api controller to discover the defined endpoints, instead of coding them one by one

Mark Wood [11:57 AM]
I've done a little work with Java annotation processing, if that would be useful.

Tim Donohue [11:57 AM]
@bollini, I agree, that would be ideal (autodiscovering endpoints)

Andrea Bollini [11:58 AM]
yes, we can use annotation or interfaces and spring bean discovering

Mark Wood [11:58 AM]
Ah, that (Spring) sounds even better.

Terry Brady [11:58 AM]
@bollini , should I reassign 3513 to you for now? I will be interested to learn from your approach to the issue

Tim Donohue [11:59 AM]
Sounds like good ideas/progress here on DS-3513. I was going to say something similar...it'd be good to get notes back in that ticket on this idea/approach

Andrea Bollini [11:59 AM]
ok, I will make a first implementation just to give the point. We can see how to proceed to add more autodiscovery capabilities

Terry Brady [11:59 AM]
I will look for a different ticket to tackle next.

Mark Wood [11:59 AM]
Do we want to discover at compile time or runtime?

Andrea Bollini [12:00 PM]
runtime

[12:00]
this will be the key to add extendibility to the rest api

Mark Wood [12:00 PM]
Spring is sounding better still.

Tim Donohue [12:01 PM]
yes, ideally runtime. If we find great complexity with that, we can revisit this. But, it sounds like we have some good ideas on how this could be achieved

[12:01]
Ok, so, we're at 30 mins here now. I want to be conscious of everyone's time today.

[12:02]
So, while discussions are welcome to continue in #rest-api or #angular-ui, we'll close up the "official meeting". Next week, we'll meet at this same time via Google Hangouts

Andrea Bollini [12:02 PM]
it looks like we have covered all the open topic in the proper time :slightly_smiling_face: good job!

Tim Donohue [12:03 PM]
Oh, and I forgot to mention, because of Daylight Saving Time (in USA now, and most of Europe soon), if we start to find that 16UTC isn't working well, we can switch meeting times. But, for now, I'd like to stay consistent. Let me know if this becomes problematic for you though

[12:03]
Thanks all! Talk to you next week, if not sooner!

Art Lowel [12:04 PM]
Thanks Tim, see ya


Terry Brady [12:04 PM]
I will take a closer look into the collection/community endpoints to see if there is more functionality that I can add there.

Andrea Bollini [12:05 PM]
ok @terrywbrady thanks

  • No labels