Summary

Adjust styling according to the document attached here:
Repaso secciones .docx

Summary

Domain entities like EventSponsor, SubjectArea and CommitteeArea require a way of establishing an arbitrary sorting mechanism, as per the requirements elicited at the development of the FAWHC 2023 event and, in extension, to future events. This means that, as per customer request, some of the entities must be displayed in the UI following a desired order that can't be chosen nor inferred via parameters that define the shape of each domain object model.

Requirements

1. Define a property or set of properties that define the sorting order for an entity inside a collection. For example an order property shared in all the entities that have an arbitrary order when displayed in UI.
2. A way to avoid coupling between the domain models and the architectural concerns that are related to providing a way of implementing an arbitrary sort for collections, together with an approach that would allow for reuse for future cases that will make use of these features.

Architectural diagram

• Available at this Excalidraw link.
  

Draft of code archicture

Sortable interface

An object implementing the Sortable interface adds a property to represent a value under which it can be sorted when part of a list or a given data structure supporting a sorting method.

export interface Sortable {
  order: number;
}

SortableEntity interface

An object implementing the SortableEntity interface acts as a wrapper for an entity of type T, delegating its ordering as a value inside a structure on the order property. The intent of the SortableEntity interface is allowing a specific model entity not having to deal with knowing details about the order in which it is displayed or sorted when being used or managed as part of collections or data structures, effectively separating concerns between the domain model and architectural purposes for the handling of data.

export interface SortableEntity<T> extends Sortable {
  entity: T;
}

SortingService abstract service

An abstract service that Implements ascending and descending sorting methods for objects implementing the Sortable interface. This service is to be extended to use, extend and override, if needed, the sorting methods here provided.

Including this abstract service in the design allows for code reuse of two basic sorting methods that only depend on the Sortable interface, reducing the amount of coupling by abstracting completely the entities from the sorting functionality.

export abstract class SortingService {
  protected ascendingSortFn = (a: Sortable, b: Sortable): number => {
    if (a.order > b.order) {
      return 1;
    } else if (a.order < b.order) {
      return -1;
    }
    return 0;
  };

  protected descendingSortFn = (a: Sortable, b: Sortable): number => {
    if (a.order > b.order) {
      return -1;
    } else if (a.order < b.order) {
      return 1;
    }
    return 0;
  };
}

EntitySortingService service

Service to handle objects implementing the SortableEntity interface when processing fetch requests to retrieve entities of the T type, allowing to hide sorting and ordering implementation details when returning T-type collections.

• First generic type of the service, T, is the type of the managed entities, which can be a basic or composite type.
  Second parameter of the constructor
• Second generic type of the service, K, is a type that extends an Iterable that wraps a collection of SortableEntities of the aforementioned T type.

export class EntitySortingService<
  T,
  K extends Iterable<SortableEntity<T>> = Array<SortableEntity<T>>
> extends SortingService {
  public unwrap = (wrapper: SortableEntity<T>): T => wrapper.entity;
  public sortAndUnwrapAsArray = (iterable: K, asc: boolean = true): T[] => {
    return [...iterable]
      .sort(asc ? this.ascendingSortFn : this.descendingSortFn)
      .map((element) => this.unwrap(element));
  };
}

Details

Libs

• Add initial version of Event and Activity abstractions. Include minimal data.

Backend

• Add controllers and services to work with Events and Activities.
• Add initial tests in Jest for controllers and services.

Frontend

• Wire the Ionic app to consume mock data of an Event and Activities from the NestJS backend.
• Configure the Ionic app environments apiUrl.

Summary

• Check the comments in participant.interface.ts related to this issue

Summary

• Favicon and Page Title should be updated according to the event data.

Summary

Users must be able to load an image to be featured in a given instance event, with the possibility of the image to be displayed in a given global section of the application -- be it the background, header, or menu.

Implementing this feature will require

• Adding the featuredImage property to the Event schema and domain model, together with the image description.
• Adding the event image to the frontend code to be rendered.

Description

The event id and the apiUrl for a given version of the app are hardcoded in environment.ts file at first. Before working on the platform as a SaaS, both strings must be able to be retrieved from a hardcoded string in the environment file, both for Angular and Ionic apps.

Update @capacitor/android and @capacitor/ios dependency versions to match @capacitor/core 4.4.0 version.

This tasks requires to write a readme that:

• Includes a succint initial description of what Conferentia is.
• Includes a list with brief descriptions of the usage of each folder in the workspace.
• Includes a list of scaffolding commands for the different projects.
• Includes a list of scripts to run in the workspace.

We must provide a connection between the Nest JS server APIs and the Sanity CMS data sources, using TypeScript for the task.

Some information on how to do that can be found at this article: https://stackoverflow.com/questions/71647459/how-to-query-sanity-client-with-nestjs

Summary

There's inconsistencies between the naming used for properties defined in Sanity schemas and domain models, both for Activity and ActivityType entities.

• Fix usages of snake_case in favor of camelCase
• Activity must be related to an ActivityType via the type alias, to avoid name bloating.

Description

Code duplication is starting to appear in backend services related to fetching domain entities. Check SponsorService, SubjectAreaService and CommitteeService fetch methods.

Summary

Fill the sections detailed in the attached document.

Texto a incluir y estructura.docx

Goal

• Adapt the Activity, Speaker, ActivityType, etc. models from previous versions to the current one, based on the needs for the first JEA event that will use this new version of the app.
• Identify which properties from the previous models needed to be updated when adapted to Sanity CMS.

Checklist

• Adapt Actividad model.
• Adapt TipoActividad model.
• Adapt Disertante model.
• Adapt Lugar model.
• Adapt User model.
• Add and slice the remaining models that are to be adapted

Summary

• Add Sponsor domain model. Check on v3 definitions.
• Add Sanity CMS schema for Sponsor entity
• Add retrieval of Sponsor instances as part of the fetching of the Event data.
• Add backend service and controller to work with Sponsor entities.
• Build right sidebar in Home page to host the sponsor images in full view.
• Work on the responsiveness of the right sidebar to show the sponsors at the bottom for mobile view.
• Add FAWHC sponsors as listed in sent documentation.

Details

package.json file must be bundled with shorthand scripts to serve, build and test the apps and libs included in the workspace.

Tasks

• Add scripts to serve the apps in local dev environment
• Add scripts to build the Ionic app and the NestJS backend app
• Add scripts to test the apps and libs

Summary

Determine if models like IFrontendEnvironmentConfig, ConferentiaRoute and ConferentiaRouteData should be moved to a specific architecture-related models library

Generate the initial content based on the 1st notice:
1era Circular Workshop Franco Argentino inglés.pdf

Summary

• Add frontend component to display Subject Area information.
• Add the corresponding Sanity schema to load the Subject Areas programatically.

Summary

The models included in the models library must include documentation on what their purpose is, focusing on explaining what the idea behind each of the models is.

Summary

Using the @angular/platform-browser module, we should be able to change the page title depending on the current hosted event.

Description

This issue aims at providing a reusable and SSoT solution for the definition of navigable routes and their related pages, avoiding duplication of navigable routes/pages definitions.

Building a SSoT solution would allow the app to programatically define and configure the navigable routes and pages. The work done at [FE-#41] must be improved when addressing the current issue.

Details

• The list of navigable routes must be single-sourced
• The list of shown routes in the left-side menu must be read from the navigable routes
• The mechanism set un app.component.ts to assign the current page title to header must be improved

Include descriptions in how to proceed with the addition of new applications

• ionic/angular: https://nxext.dev/docs/ionic-angular/generators/application.html
• nestjs:
• etc.

An example on how to proceed with multilanguage support for the README.md file:
https://github.com/jonatasemidio/multilanguage-readme-pattern

Follow the next link as an example for the sidebar: https://cehc-2.sciencesconf.org/resource/page/id/14

Description

Information from Events should be loaded based on the user data, according to the event they've registered themselves to.