--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > Gettting back to the pagination, I think that only UI may keep the > state becuase only UI knows the execution context. That is, only UI > knows what had been shown and what should be shown next.
Sounds like we agree. > In my solution, I use an intermediady persistent storage and two > state paramentes: the initial "request ID" and the range of records > to be returned for a requested page. So, I do not see any reasons > why a pagnation may not be a business service. I don't know that I'd call it a "business" service. Would it qualify as a service provider in the context of SOA principles? I'm not sure. * It isn't providing a "coarse-grained business" function. It is a technical function intended to conserve network and memory resources. If network and memory were free, we wouldn't paginate. * Depending on what the requestID is used for, it may not be stateless, which is typically viewed as a key characteristic. With the info thus far, I lean toward what Anne mentioned in her post, this capability probably belongs positioned in the application, not as a business service provider. -Rob
