smartgwt and spring data issue

[mathias]

Hi,

we have a smartgwt pro app with spring services as serverobjects for all datasources.

We started looking at upgrading our daos to use Spring Data, but we have run into issues with pagination:

DataSource loading works with the limit and offset parameters to load data as we all know. However, Spring data uses something called a "Pageable" abstraction:

        PageRequest request =
            new PageRequest(pageNumber, PAGE_SIZE, Sort.Direction.DESC, "startTime");

The problem here, of course, is that if i wanted to convert the offset and limit to "pages" and "page sizes" there's no guarantee that the limit and offset values can be transferred evenly to an exact number of "pages"...

Is there a way around this? Can i configure the listgrid's dynamic loading somehow to guarantee that they always fetch 'even' pages, and therefor make it possible for me to create a pagerequest?

[Isomorphic]

It makes no sense to work with fixed paged boundaries in a dynamically resizable UI. You will just need to fetch multiple pages from this Spring API.

While you're in the midst of re-designing your data layer, we'd recommend looking at a switchover to SQLDataSource or at least JPADataSource. You could be writing a lot less code at your data layer, as well as avoiding having to come up with a solution for "head-scratcher" API designs like this one.

[mathias]

Thanks for your input, and i agree about the dynamic ui point, was just making research.

Turns out it seems i can write a custom Pageable Spring Data implementation that does take the limit and offset parameters, so i think i can make it work.


Thanks for the input, but there are a couple of reasons for our architecture:

1. There are lots of business logic that needs to happen between your datasource code and sql/jpa, so just mapping those directly in the datasource is a no-go.

2. we have several ways "in and out" of our system, not only the smartgwt app, so we want to have business logic in one place. Therefor, we have a thin web layer that takes the dsrequests, and then services that contain business/calls to data layer processing. Our reporting, rest (for iphone/android access), backoffice and SMS-communication entry points all call those same services, some of which existed prior to our smartGWT app.

3. We use Spring Security for a role based authentication process, and you have no good way to leverage that in the manner we need so that it also works in other parts of our system.

[Isomorphic]

This is a common set of objections, and in our experience, reflects a common set of misconceptions..

1. This is what DMIs, subclasses of server DataSource classes, Server Script etc are for. Typical large projects capture recurring business logic in a server DataSource subclass, so most operations require no *unique* business logic and hence need not be declared in the DataSource at all.

2. Your "thin web layer that takes the dsRequests" would still work identically regardless of the internal details of the DataSource implementation, as well as your existing REST entrypoints, although it would of course be better if you were just able to use RestHandler (but it sounds too late for that additional simplification).

3. Spring Security integration is covered on the wiki, and role-based enforcement applies to DSRequests via Declarative Security, with again of course the ability to add whatever custom logic you need, at several different phases of processing. We're not sure what gap is being perceived here.

[mathias]

I'm sure it's all misconceptions...

1. That would require tying our business logic to your libraries (subclassing DataSource), which we don't want to do.

We're also happy with the ioC spring container for a bunch of other reasons too (testing, modularity etc.)

2. See 1. Also yeah, it would be great if we could make our smartgwt code use our rest services instead of having lots of webcontrollers that take DSRequests etc. But back when we started out, we didn't really see a resthandler as an option. (and we didn't have smartphone apps...)

3. Last time i checked, there is a thread about relogin and securing the IDACall with rolebased security, is that what you mean? We're doing more than that, like returning different data sets depending on the role, different fields depending on the role, checking rights to perform specific operations etc. When we started out, you definitely didn't have anything to leverage that.

Anyway, thanks for the input.

[Isomorphic]

1. Tying business logic to the framework you're using happens regardless of framework. While some frameworks oriented on Java Beans allow some extremely trivial business logic to be implemented in a setter, that's a negligible effect - you still end up with substantially all of your business logic referencing whatever framework you're using.

As far as testing and modularity, the server framework can be run standalone from the command line and we use this capability to run our enormous test suite. No sure what specific concern you may have here.

2. Having SmartGWT call your REST services instead of using IDACall or RestHandler seems like an architectural step back in every way, as well as creating a need to write and maintain a bunch of code you don't need. The simplification we were pointing out was that, if you could start over, you could avoid having any custom REST services at all, since RestHandler addresses every use case you described.

3. Declarative Security does all that, and furthermore, creates client and server-side enforcement from a single definition. This makes it more expressive than any purely server-side security framework could ever be, because any such framework requires you to implement parallel enforcement in the UI (or the UI will confusingly allow operations the user can't do, then throw errors). Even before Declarative Security, the checks you're talking about could be straightforwardly achieved via DMIs, custom server-side DataSource subclasses, etc, like any other business logic.

[Isomorphic]

Just to let you know why we keep responding on this: the #1 way users fail with our software is that they adopt an architectural pattern from some third-party library and end up writing a bunch of unnecessary code while simultaneously crippling framework features that would "just work" if they had just followed best practices.

The reason given for this is always "encapsulation", "modularity" or some similarly difficult to evaluate claim - with the real root cause always being misconceptions about SmartGWT.

So when people say something like "we needed to use X library because.." we need to chase that down and show that in reality our best practices already cover the supposed need.

[mathias]

Listen, i don't want to get into a debate in a forum. I have tons of feedback i am happy to give you off-line that might be of interest to you, feel free to get in touch.

Let me just say that we've been using smartGWT since 2010, and that i don't think that it's constructive to dismiss arguments about architectural/framework selection decisions as "misconceptions" without knowing any details at all about the system in question.

if the arguments are "common" as you say, there's usually a reason for that.

Peace.

[Isomorphic]

We didn't try to initiate a debate, however, please consider what you said and where you said it.

Looking back at your first response, when you seem to be saying that there is no way to capture business logic in a DataSource, and when you say "you have no good way to leverage [Spring Security] in the manner we need" - these are things we need to respond to, for reasons previously explained.

Anyway if you prefer to communicate it privately, yes we'd love to get your feedback. We'll reach out via email.

[Isomorphic]

Oh also, about this:

if the arguments are "common" as you say, there's usually a reason for that.

There is. Other companies spend a huge amount on marketing trying to get attention for particular architectural patterns that appear good enough at first glance, but don't actually work in real world situations.

Remember we work with a *lot* of customers. We have enough visibility to watch the architecture trend du jour get picked up by several groups that started building their application at around the same time, and ruin that whole set of projects in the same way.

We do what we can to prevent this, but ultimately, if we tell people something is a bad idea it just sounds like yet another company's marketing! Fortunately, some people learn over time.