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 [9:52 AM]
@here: a reminder that we'll be holding our first DSpace 7 UI text chat meeting via Slack (starting in this channel) at the top of the hour. This is a status update meeting, so there's no formal agenda, but relevant links are at: https://wiki.duraspace.org/display/DSPACE/DSpace+7+UI+Working+Group

Tim Donohue [10:00 AM]
@here: It's DSpace 7 UI Meeting time! I'll get things started...

[10:01]
First off, as a reminder, we'll be meeting for an hour. The first 30 mins will be in this channel & include updates on Angular UI work (over the last week

[10:01]
The second 30 mins will be in #rest-api channel, where we'll do the REST API updates

[10:01]
@art-lowel : would you like to get us started here with updates on Angular UI work?

Art Lowel [10:01 AM]
ok

[10:01]
The PR for the first version of the HAL serializer is ready
https://github.com/DSpace/dspace-angular/pull/61

[10:02]
It takes a model class as a param to its constructor

[10:02]
e.g.: `new DSpaceRESTv2Serializer(Bitstream)`

[10:02]
It can use any model that has @autoserialize annotations

[10:02]
e.g. https://github.com/artlowel/dspace-angular/blob/rest-services/src/app/core/shared/dspace-object.model.ts#L14

[10:02]
The PR also contains a validator, that can use JSON schema to ensure documents fit the spec

[10:03]
Weeding out malformatted responses before you start makes serialization easier, as you don't have to test whether everything exists before you do something with it

[10:03]
JSON Schema is something like XSD for JSON

[10:03]
I started with the default hal json-schema - we can expand on it later by adding rules more specific to dspace.
http://hyperschema.org/mediatypes/hal

[10:03]
but our current mock responses don't fit that default hal schema (something about the structure of the `_embedded` element).
So the validator isn't used yet.

[10:04]
Building on the serializer PR, there's also a PR that adds a CollectionDataService and an ItemDataService
https://github.com/DSpace/dspace-angular/pull/62

[10:04]
These services offer a `findById` method, and a `findAll` method with an optional `scope` param, for Items and Collections

[10:04]
The PR *doesn’t* have all the required documentation and tests at the moment.

[10:04]
I'd also like to refactor it, as there is too much code duplication between the Item and Collection Services, and their corresponding actions, reducers and effects.

[10:04]
But these services can be used to start making UI components such as collection homepages and item view pages

[10:04]
So I suggest that people review them as they are, and that we merge them ASAP so other work can start

[10:05]
Their issues will stay open until docs, tests and refactoring are complete.

Tim Donohue [10:05 AM]
Nice, sounds like some good progress here :wink:

Art Lowel [10:05 AM]
do you agree/disagree with that approach?

Tim Donohue [10:06 AM]
So, to clarify, we need to merge the HAL serializer first, #61 (ASAP). Then we'd merge the Collection/Item services (#62) and work to refactor them later?

Art Lowel [10:06 AM]
yes

[10:06]
the HAL PR should be up to snuff

Bram Luyten (Atmire) [10:06 AM]
joined #angular-ui

Art Lowel [10:06 AM]
the other one isnt

Tim Donohue [10:07 AM]
That seems reasonable assuming the refactor work in #62 is still made a priority. It sounds like that's important and shouldn't be forgotten

Art Lowel [10:07 AM]
I’d still like other people to test them first

[10:07]
yes the issues will remain open until that is completed

Hardy Pottinger [10:07 AM]
"merge first" = "enforced testing" :wink:

Tim Donohue [10:08 AM]
@art-lowel : How does one go about testing the HAL Serializer (#61)? Is that one really just a code review (that we later test in #62)?

Art Lowel [10:08 AM]
I just hurried to get something out there people could start developing against

[10:08]
code review, and review of its unit tests

Tim Donohue [10:08 AM]
makes sense

Art Lowel [10:08 AM]
I made it against the unit tests

[10:08]
but it worked in practice when I was working on #62 :slightly_smiling_face:

Tim Donohue [10:09 AM]
Do we have a volunteer who wishes to help/perform a code review of PR #61? @wwelling is this of interest to you? I can also help, but might appreciate a second pair of eyes (my Angular is a tad rusty and needs brushing off)

Art Lowel [10:11 AM]
this part has very little angular specific code in it btw

James Creel [10:11 AM]
I have put a little time into the mock responses which need reconciling with the schema, so I may be of some service

Art Lowel [10:11 AM]
If you’re good with java, you should be able to work it out

Tim Donohue [10:11 AM]
Thanks @jcreel256. If you can help review #61, I'd appreciate it. I will also review it (though I have meetings all morning, and may not get to it till this afternoon)

[10:12]
How about a volunteer here on testing #62 as well? Anyone interested in helping move along the Collection/Item services?

Art Lowel [10:12 AM]
That one is more complex though

[10:13]
although I tried to give somwhat of an explanation in the PR description

Tim Donohue [10:13 AM]
Is there a recommended testing approach? Or is this another code review (for now), until we get UI components built out?

Art Lowel [10:14 AM]
I’d say, use it: create a component that uses CollectionDataService.findAll for example

[10:14]
and use it to list collections somewhere

[10:14]
then use the redux dev tools to see what state changes occur

Antoine Snyers [10:15 AM]
I’ll take a look at it :wink:

Tim Donohue [10:15 AM]
Thanks @antoine , sounds great! I can again look at the code, but not sure I'll get to testing. So, please let us know what you find!

[10:16]
Ok, we are 15mins into the meeting already. Other major updates to share while we are all here?

Art Lowel [10:16 AM]
I've looked up why yarn was removed from the universal starter project

[10:16]
The only mention I can find about this is: _“I"m going to remove yarn.lock since it causes too much merge conflicts”_ in this PR:
https://github.com/angular/universal-starter/pull/262#issuecomment-261736701

[10:16]
Looking in to it, merge conflicts with the lock file seem to be a problem with yarn, there is an open issue about it on github.

[10:16]
But it is a problem inherent with the use of lockfiles, so it also affects npm-shrinkwrap

[10:16]
Since the lock files for both tools are automatically generated, there's a chance they'll clash when two people independently add dependencies to them.

[10:17]
For now the solution to this issue seems to be to take `origin/master`'s version of the lock file, and then running yarn install again. That way yarn will merge them for you.

[10:17]
https://github.com/yarnpkg/yarn/issues/1776#issuecomment-269539948

[10:17]
Since npm shrinkwrap lockfiles have the exact same problem I don't see this as a dealbreaker for yarn.

[10:17]
It will need to be automated as best we can in an npm script, and explained in the docs.

Tim Donohue [10:17 AM]
+1 to docs / automation here

[10:18]
It also doesn't sound like a dealbreaker to me. So, as there are benefits (and since yarn is "backwards compatible) I'm OK with us trying out Yarn

Art Lowel [10:18 AM]
:y::skin-tone-3:

[10:19]
last time @wwelling said something about using OpaqueToken for the config.

[10:19]
I did some reading about it, and I can see the benefits of injecting environment variables. It makes it easier to mock them during tests for example.

[10:19]
so that idea has my +1

Tim Donohue [10:20 AM]
Sounds good

Art Lowel [10:20 AM]
but I’m not sure I understand the details well enough to write a task for someone else to do it

[10:20]
so I wanted to ask @wwelling if he could write the issue, or implement it himself

Tim Donohue [10:20 AM]
@wwelling or @jcreel256 , any chance you could help out here (writing a task or implementation)?

[10:21]
We can touch base with them post meeting as needed. I don't want to wait too long for a response (in essence of time) :wink:

Art Lowel [10:21 AM]
makes sense

James Creel [10:21 AM]
excuse us, multitasking :slightly_smiling_face:

Tim Donohue [10:22 AM]
Are there other updates (either from @art-lowel or anyone else here)? Or other questions/topics folks want to discuss regarding Angular UI?

William Welling [10:22 AM]
I can create the task.

Tim Donohue [10:22 AM]
thanks @wwelling!

William Welling [10:22 AM]
I have some questions about the spinner feature.

[10:23]
Do we still intend to have a spinner that intercepts route change and displays conditional on pending asynchronous requests?

Tim Donohue [10:23 AM]
aforementioned "spinner" (PR): https://github.com/DSpace/dspace-angular/pull/43

William Welling [10:23 AM]
I recall saying a Guard CanActivate may be able to achieve this, but it may be easier than that.

[10:24]
Yes, I am curious on the requirement of this feature.

Art Lowel [10:24 AM]
Yeah, I believe last time we agreed you’d look in to it, and perhaps come up with an alternative

William Welling [10:24 AM]
A single page app should have notification when pending data is being requested, but I dod not think any navigation should be affected.

Art Lowel [10:25 AM]
The CanActivate would prevent you from navigating to the route before it was loaded?

William Welling [10:25 AM]
The navigation should occur immediately displaying whatever is available. A notification should only be for the asynchronous requests. If we end up having to wait between navigations it will be a poor user experience.

[10:26]
Such as selecting next page of a pagination or selecting a item from a list. The requests should be minimal and only retrieve data that is needed at the time and if it takes longer we should make other affordances.

[10:27]
The practical use of a user affected spinner is creation, save, or update where the completion of a request is necessary for any further user interaction.

Art Lowel [10:27 AM]
That’s a good point

William Welling [10:27 AM]
@art-lowel yes, that is correct. But could activate and set a process that enables the spinner and waits for the one to complete its asynchronous tasks.

James Creel [10:28 AM]
I've got to duck out for another quick meeting, and I will join the REST discussion a little late.

Tim Donohue [10:28 AM]
As we are running short on time here, I wonder if it'd be worth considering creating a (discussion) ticket for this in GitHub, so that @art-lowel and @wwelling can discuss in more detail & come to consensus? (and others can take part too)

Art Lowel [10:28 AM]
We can use the spinner issue that’s already there

William Welling [10:28 AM]
Ok

Art Lowel [10:28 AM]
https://github.com/DSpace/dspace-angular/issues/24

Tim Donohue [10:28 AM]
In general, I wonder if such detailed discussions (and even requirements gathering/clarification) could be done more in GitHub Issues?

Hardy Pottinger [10:29 AM]
+1 github discussions

Tim Donohue [10:29 AM]
It might make these text chat meetings go a bit more smoothly, as it means we can bring *proposals* here, rather than having all the discussions here :wink:

[10:30]
But, it sounds like @wwelling has some good ideas here, I'd just recommend figuring out the final details/requirements in the ticket and come back with a proposal (as needed)

[10:31]
@here: As it has now been 30 mins, the meeting will now move into REST API discussions in #rest-api channel. If there are further angular-ui discussions, you can still hang out here, but my attention will move to #rest-api

Andrea Bollini [10:31 AM]
anyway, it is useful to have an half hour appointment to be sure that some discussion happen

Tim Donohue [10:33 AM]
Yes, this mtg structure is a work in progress here...i'm sure these first few Slack mtgs will be a bit "rough", but hopefully it will smooth out a bit more as we learn how to fit discussions into time allotted. Nonetheless, feedback is welcome :wink:


REST meeting

Attendees

Notes:

Slack Logs (times are all CST)

Andrea Bollini [10:22 AM]
in the #angular-ui is running the first half of the weekly dspace 7 meeting, we move here in 10 minutes

Tim Donohue [10:31 AM]
@here: we are now into the REST API updates portion of our meeting. @bollini, would you like to kick us off here?

Giuseppe Digilio [10:32 AM]
joined #rest-api

Andrea Bollini [10:32 AM]
ok since our last video call we are slowly moving thing ahead

[10:32]
first: the initial sourcecode is now on DSpace/DSpace https://github.com/DSpace/DSpace/tree/rest7/dspace-spring-rest

[10:33]
second: we have tracked some urgent activities here https://jira.duraspace.org/browse/DS-3423

[10:34]
third: some discussion around the mock data has started, see https://github.com/DSpace-Labs/hal-jsonapi-comparison/pulls

[10:34]
fourth: we have an empty repository for the REST contract here: https://github.com/DSpace-Labs/Rest7Contract

[10:35]
this is more or less my agenda for the today chat

Tim Donohue [10:35 AM]
@bollini: good progress here as well!

Andrea Bollini [10:36 AM]
current source code is very rough and there are several issue. some already spot by @terrywbrady

Tim Donohue [10:36 AM]
Starting at the source code itself, I know @terrywbrady has been working to get things "running", so it sounds like we need a little concentration on docs & fixing builds (to allow other developers to jump in)

[10:36]
(ha, we said the same thing)

Terry Brady [10:36 AM]
I am trying to get the rest7 branch to run on our test server

[10:37]
progress since yesterday, but I am not yet seeing the /api/core/xxxs calls returning data

[10:37]
I am trying to troubleshoot that issue

[10:37]
It will be good to have this common branch to work from!

Andrea Bollini [10:37 AM]
if you access the / of the dspace-spring-rest do you see the hal browser?

Terry Brady [10:38 AM]
How do I access that? [myserver]/?

Andrea Bollini [10:39 AM]
are you deploying the war as root? is so, yes

[10:39]
I have it under localhost:8080/dspace-spring-rest

Terry Brady [10:39 AM]
I am using the old mvn/ant workflow so I am not yet convinced that I am deploying the right stuff

Andrea Bollini [10:40 AM]
mmm... I see

Tim Donohue [10:40 AM]
I wonder if it'd be useful to begin "drafting" some build/deploy documentation (either in a PR to the README, or in a Wiki page)?

[10:40]
It sounds like it's possible we need clarification there...and it might point out where the difficulties are

Andrea Bollini [10:41 AM]
yes, it is the idea behind the readme in the webapp

Hardy Pottinger [10:41 AM]
more howtos are great, and will help us get more people to test for us

Tim Donohue [10:41 AM]
Right, so this README is the one we should enhance: https://github.com/DSpace/DSpace/tree/rest7/dspace-spring-rest

Terry Brady [10:41 AM]
I see 5 dirs in the webapps folder, and I am unclear where to find the war for spring rest

Andrea Bollini [10:42 AM]
I'm not sure that it is packaged at all

[10:42]
again, right now I focus on having things working in eclipse so the packaging process is not complete/tested

Tim Donohue [10:43 AM]
So, it sounds to me like we need a new ticket here (a subticket of https://jira.duraspace.org/browse/DS-3423). We need a ticket to fix the build/deploy process

[10:43]
As it sounds like the WAR may only be "runnable" in an IDE at this time

Andrea Bollini [10:44 AM]
ok we can open an issue for that

[10:44]
should we focus on a fast solution to improve later or we need a clean build process right now?

Tim Donohue [10:44 AM]
I think the stumbling point we have here is that it's unclear what "works" and what doesn't. A fast solution is perfectly fine as long as it's one that others can reproduce (and we can clean it up later)

Andrea Bollini [10:45 AM]
I'm asking because I see three current stops for the build

[10:45]
ok, so we can disable dspace-solr and the mvn-enforcer plugin for now and focus on the war packaging

[10:45]
the issue spot by the mvn-enforcer plugin is more or less the goal of the https://jira.duraspace.org/browse/DS-3482

Terry Brady [10:46 AM]
Let's try that. I am hoping to find an entry point to be able to contribute to the project.

Mark Wood [10:47 AM]
That sounds like a place I could get started, too.

Tim Donohue [10:47 AM]
Yes, I say disable Solr & mvn-enforcer for now. I just added a note to DS-3482 about enforcer, and we can re-enable it later

Andrea Bollini [10:47 AM]
me and @lap82 can help on that as well tomorrow in the Italian afternoon

Andrea Pascarelli [10:47 AM]
joined #rest-api by invitation from @bollini

Tim Donohue [10:48 AM]
that sounds great, @bollini and @lap82

Terry Brady [10:48 AM]
thanks

Andrea Bollini [10:48 AM]
ok before to move to the other points last words about the current code

Andrea Pascarelli [10:48 AM]
Hello everybody!

Tim Donohue [10:48 AM]
Hi @lap82, welcome :wink:

Andrea Bollini [10:49 AM]
we have initial endpoints for items (only metadata are shown), bitstreams (metadata, atttributes and link to bitstreamformat)

[10:49]
just few hours ago I pushed a fix version to have also the bitstreamformat endpoint so to navigate from bitstream to the registry

[10:50]
once we solve the issue with the build it will be very useful to have volunteer to look to the test framework

[10:50]
https://jira.duraspace.org/browse/DS-3484

Tim Donohue [10:50 AM]
sounds good

[10:52]
It seems like it's best to first get the build running, so folks can get a closer look at how this works/looks. Then maybe we can get others volunteering for the various tickets (all grouped under https://jira.duraspace.org/browse/DS-3423)

Tim Donohue [10:52 AM]
notes I have to run to another meeting in 10mins

Andrea Bollini [10:52 AM]
ok, about the mock data

[10:52]
we have this PR https://github.com/DSpace-Labs/hal-jsonapi-comparison/pull/2

Tim Donohue [10:53 AM]
Should we merge that PR as-is and fix all the "wrong" links at once? (as it sounds like this PR was based on previous wrong links)

Andrea Bollini [10:54 AM]
I have sent this PR to @jcreel256 https://github.com/TAMULib/hal-jsonapi-comparison/pull/1/files

[10:54]
it changes the way that relations are linked

James Creel [10:55 AM]
and fixes some outright typos, thanks @bollini

Andrea Bollini [10:55 AM]
in a HAL document say a Collection you should always have the link to the relation also when it is empty

[10:56]
this because the relation link is also used to discover where you need to post new content to update the relation or add new links

Tim Donohue [10:56 AM]
That all looks reasonable to me. I don't have objections to these changes (though if we find future reasons why this won't work well with Angular UI, we can always revisit it later on)

Andrea Bollini [10:57 AM]
ok, so we can just wait for a fast review from @jcreel256 and when merged in the TAMUE repo I will merge in our dspace-labs

Tim Donohue [10:57 AM]
And, I think this is exactly what we had discussed & approved last week (that we don't want all sub-objects listed in their parent objects, e.g. items in collections) :wink:

Andrea Bollini [10:58 AM]
the next step for me is to add other mock-data aside the current ones where we show how these linked collection can be embedded in the initial request

Art Lowel [10:58 AM]
That would be interesting

[10:58]
esp if it can be done in a flat structure

Andrea Bollini [10:59 AM]
ok do you have any preference about which relation to embed in the samples?

Art Lowel [11:00 AM]
bundles and bitstreams in an item

[11:00]
that will be immediately useful for the design of the item view page

Tim Donohue [11:00 AM]
is going to have to run to another meeting. I would encourage you to continue discussions here though (or even jump back into #angular-ui if there's more questions/comments there). I'll be lurking & can copy these discussions into "Notes" on the wiki later today

Andrea Bollini [11:00 AM]
ok I will provide samples for item so that other can also help adding more. Today or tomorrow

Art Lowel [11:00 AM]
no rush :slightly_smiling_face:

Andrea Bollini [11:01 AM]
last question about the new repository for the rest contract https://github.com/DSpace-Labs/Rest7Contract

[11:01]
should we use the github issue to discuss around specific decision?

[11:02]
an example, in the current implementation I have skipped to include the uuid in the object attribute as it can be seen in the self link

Art Lowel [11:02 AM]
yeah, I just added an issue about that to the comparsion repo

[11:02]
https://github.com/DSpace-Labs/hal-jsonapi-comparison/issues/3

[11:03]
but perhaps that should be on the new Rest7Contract repo?

Tim Donohue [11:04 AM]
has one last thing to quickly mention. Next DSpace 7 Meeting will be next week (Feb 23 @ 16:00 UTC). I'd like to use Google Hangouts again, as the limit is 25 attendees these days. More info later

Andrea Bollini [11:04 AM]
yes, the hal-xxx repo is temporary imho as soon as we have more samples we should move all the staff in the rest7contract repository

Art Lowel [11:04 AM]
sounds good

Andrea Bollini [11:05 AM]
I plan to do that as soon as we have mock data build on something that is shared across the developers like the data in the current demo.dspace.org

[11:06]
otherwise anytime that we build some mock data we will have changes due to different databases or hard-time trying to build manually relations with random uuid

Art Lowel [11:06 AM]
indeed

[11:06]
ideally it would still be something that we could easily deploy locally

[11:06]
because if there was a single server like demo.dspace.org

[11:06]
and the spec changes

[11:07]
things in the UI might break until we become compliant (edited)

[11:07]
so it would be good if a UI dev could deploy an older version to work with (edited)

Andrea Bollini [11:08 AM]
yes, we can share the initial AIP of the demo.dspace.org and just use these information for now

[11:09]
@art-lowel can you reopen the question on the rest7contract?

Art Lowel [11:09 AM]
sure

Andrea Bollini [11:11 AM]
ok so there is lot of work to do before next hangout meeting. Unfortunately @terrywbrady @mwood @jcreel256 are on a different timezone but me and @lap82 will do our best to help to get all of you, and anyone else that like to join, started also on the webapp code

Mark Wood [11:11 AM]
Thank you.

Terry Brady [11:12 AM]
Thanks for keeping things moving. I will just post questions here as they arise

Andrea Bollini [11:12 AM]
good

[11:14]
I'm leaving from the office now. Keep in touch

Art Lowel [11:14 AM]
bye


  • No labels