LayerAccessArgs pagination considerations

The current situation

LAA stores page and limit properties on the instance to manage the size of the result set from any loadX( ) return set.

In the (assumed) common usage of the system:

$layerHeirarchyObject->find()->load()

the LAA object is lost after the return of data. So, any pagination properties set are also lost. However, we can assume that we would want to keep track of the current limit and page values and to be able to perform 'next' and 'previous' processes.

But what are the requirements

One of the problems right now is understanding the role of LAA and the Layer Hierarchy Objects (LHO) in general.

The system exists to help build interface pages from complex objects. We can assume that the Controller and the existing PaginationComponent are managing the set (page) of complex objects that were sent to the page.

So the LHO/LAA system is a helper system and the need for paginated results may be minimal.

Thinking beyond our app to an API

It's also important to keep in mind that the LAA system is local to our app. Foreign systems that use our API will receive LHOs, but no functionality associated with them. These consuming-apps could build any access systems they wanted to manage the received structures.

Likewise, we should work to be clear about when we are 'using our API' and when we are engaged in 'implementing our application'. Each Request represents an API call that any consuming-app could use and each Response is the result of an API call. But the behavior we have on the Response objects (eg: $response->IDs() ) is local to our implementation.

The LAA is entirely outside these two domains. The LHO data structure is a major kind of Response. There may be others that are not yet defined

Back to pagination

So, the future of LHO pagination hinges on whether it's part of the API or part of our local app implementation.

Since we're operating on API Responses, it appears it should be a part of the local implementation. If so, there is no need for the API to see or respond to pagination settings related to LHO/LAA behaviors.

The API will need to respond to pagination settings related to getting the stackSets themselves though.

Javascript implementation

Currently, we have no javascript equivalent of the LHO behaviors or the LAA, but I've always assumed we would need one. So, whatever LHO/LAA pagination solution we create will have to be duplicated

Persisting pagination settings

The core issue I'm concerned with, is how to persist the pagination settings for the LHOs. In the current version, the values must be maintained externally and passed to a find/load call, or the LAA must be defined separately and passed to one of the 'direct-to-object' calls (these are the Trait calls that accept a LayerAccessArg as their argument.

I would also be possible to create a separate Pagination object that could be managed and passed to the LayerAccessArg.

OrigamiStructures / StudioManagerScratch