Long term efforts to improve the codebase about coral HOT 4 CLOSED

The Javascript needs to be refactored.

• There's been a tendency to copy and paste, rather than abstract, which means what should be trivial changes end up being hours spent making sure the simple change is implemented in many, nearly identical places.
• Because of the tangled JS, we're stuck using a very old version of jQuery, which lacks many new features, performance enhancements, and security fixes.

Improve Coral's Modularity

• I think this is well known and being addressed, but the lack of shared code across modules means innovations in one module often don't make it to others, meaning we're actually dealing with several codebases.
• Coral is flexible in its ability to function in combination with different modules, but all code that hinges on expressing a given configuration should be in as few places as possible, preferably one.
• In the resources module, for example, the module logic is peppered throughout class methods and controller files. Right now, a developer just has to learn through trial and error when they need to account for the fact that an organization could be native, or from the organization module.

from coral.

To supplement the interface point, here's an example of a feature we're working on at TAMU to import record data from an in house API:
TAMULib@2449358

Because there's a well defined interface for what an Organization is, the controlling code doesn't need to know what type of Organization implementations it's working with. It just knows getTitleText() will be callable. It doesn't care if that method is backed by a MYSQL query or an API request.

from coral.

Adopt a true MVC pattern.

Right now, our data classes are sprinkled with view and business logic and our controllers and views are merged into one entity. This greatly complicates modifying code or adding new features.

We should work toward using interfaces to define contracts for interacting with our data models.

In other words, code that works with an Organization implementation shouldn't have to know or care if it's representing a org module Organization, a resources module Organization, or importable organization data from a 3rd party API.

Our CSS needs attention.

It's ad hoc, and not easily reusable or extensible. Part of this is due to the over-reliance on IDs serving as jquery hooks (which also tightly couples our HTML to our javascript to our CSS, making it difficult to improve any of the three). Another part is the abuse of the !important declaration, which breaks the C in CSS and is difficult to identify and fix.

from coral.

Updated initial message part about the error messages with an example of real life issue.

from coral.