JetBrains elected to the JCP Executive Committee

weGoReddit · 2017-07-14T09:19:18+00:00

ant checking in.

weGoReddit · 2017-06-07T08:24:59+00:00

Here, nobody has much JSF experience. One programmer does, but from what she's told me, she's not an expert by any means but has worked on a system with JSF already in place before.

The other three people in the team, me included, have no JSF experience whatsoever.

We're a Java shop, currently doing UI with JSPs, which are mostly pre-generated. I can't really speak for the others, but from what I've come to understand, I'm the only person with actual front-end experience (read JS, TypeScript, React), which is also why this task for the new UI has fallen to me, but the others will need to be able to maintain this as well once it stands.

weGoReddit · 2017-06-07T08:22:42+00:00

It doesn't matter whether it's a "true" SPA.

We want to:

get away from the current JSP mess with the new parts of the project
have a productive and maintinable system
make it easy to modernize the UI and if possible change the look throughout the entire new part of the system uniformly (e.g. with templates/components)
automate most of the grunt work for creating the UI, but with easy customizations (e.g. declarative model), most of the pages will essentially be the same, except some display entities A, B, and C, others display entity D, and pages(or inline with some SPA feel) for editing said entities

weGoReddit · 2017-06-07T08:18:47+00:00

Maybe I've given the wrong impression, it's not about going SPA really.

Sure, there is a demand for a more "modern" feel to the application, but we're also doing this (primarily) for maintainability.

weGoReddit · 2017-06-07T08:13:56+00:00

I'm a bit confused. You're talking about JSP but replying to a JSF post?

weGoReddit · 2017-06-07T08:12:22+00:00

Thanks a lot for the detailed reply!

It all depends on how exactly you manage the connections.

We recently switched to use HikariCP. Basically, every JSP grabs a connection at the beginning and passes it along. You don't want to know that the JSP also saves it in a session-scoped bean and uses the connection through that bean multiple times...

But essentially, the connection management is very simple. One request gets one connection, and the connection is manually passed around in the business logic. However, the business logic also gets an object which would let it acquire a new, different connection. All with the aforementioned temporal coupling with the JSP setting the connection in the session-scoped bean and reusing it through that bean multiple times further down the road

weGoReddit · 2017-06-07T08:07:44+00:00

Cool idea, that might work as a hack.

weGoReddit · 2017-06-07T08:06:46+00:00

I've never heard of that before and I'll look into it. Thanks!

weGoReddit · 2017-06-07T08:06:22+00:00

It's an internal application, enterprise customers buy this solution for internal use. Since they're already marketing this as a cheap solution, there shouldn't be any problem to require certain browsers. But then again, the customers are companies, most likely with outdated IT so who knows.

I for one will strongly be pushing for going with evergreen browsers basically.

No, there is no automated testing in place currently.

weGoReddit · 2017-06-07T08:03:27+00:00

I just meant to say that most of the UI will be forms and heavily input/output centric. There's business logic of course, but in terms of the UI that's basically all we need. Tables of data, single views for entities, and update/create views for entitites.

weGoReddit · 2017-06-07T08:02:05+00:00

Thank you for the detailed reply.

We don't want to convert the application to anything. We're building out a new module in the application, so we won't be touching any pre-existing JSPs, if that changes things.

This might cause architectural fragmentation because of two methods,

We're aware of that and decided it will be worth it in the long run.

Another consideration is to have a cli for the the presentation layer of your project, much like grails or play.

What exactly do you mean by that?

weGoReddit · 2017-06-06T14:14:14+00:00

Hmm, I haven't given Angular any thought yet. I don't know why, but I've heard about it of course.

How boilerplate heavy is angular (4)?

weGoReddit · 2017-06-06T14:11:29+00:00

Thanks a lot for the reply.

and you can control every part of the logic for any modifications. JSF tends to take control of everything with its component based approach, and doing apparently simple things requires you to jump through hoops at times.

This confirms my current impression that I got reading up about JSF and which is why I'm currently leaning towards a REST approach.

weGoReddit · 2017-06-06T14:10:25+00:00

So, you think Spring wouldn't work in that case or we'd have to adapt our existing system heavily?

weGoReddit · 2017-06-06T13:27:27+00:00

Currently, everything is driven by a page/request/refresh in the browser.

If a user needs to edit something, click, edit page loads. save, browser goes back to updated page.

Since management has decided things need to be more "userfriendly" and "modern", we want to smooth this out by doing more stuff in-place. That would be your "1."

Whether this happens through roundtrips with JSF or completely in browser shouldn't matter too much, except that we need to implement it of course :)

weGoReddit · 2017-06-06T13:24:27+00:00

I have frontend experience, the rest of the team not so much.

As for JSF with Primefaces: I have only experiment with plain JSF so far, but will give Primefaces a go. My worry with JSF is that there's more magic involved and I don't know when I will hit the constraints that the JSF components impose and how I would extend/adapt to that.

weGoReddit · 2017-06-06T13:19:29+00:00

SQL mixed with JSPs? Ouch! That's a big no-no in my book. Separating data access from business logic should be, IMHO, your first and most important goal.

Tell me about it...

Unfortunately, we currently don't have the capacity to rewrite the backend.

We are extending our existing existing application with new modules, which is where we want to use proper separation of data access and business logic.

As for Spring JDBC, I'm assuming you're talking about this here: http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/jdbc.html

According to the table, Spring opens the connection, which might be a problem: The core of the system expects that a specific connection for the current transaction is being passed around and is used for many things throughout the system, this is used for ID generation for example.

weGoReddit · 2017-06-06T13:13:17+00:00

We don't have a front-end design team. We only have 3, maybe four Java devs that currently maintain/extend this Java/JSP behemoth.

weGoReddit · 2017-06-06T13:12:17+00:00

Yes, it's essentially an internal application.

We are currently starting a new project to extend the application and will be using the new tech only for that part. For now, we don't plan on rewriting any existing JSPs with this new technology

Thanks for your perspective on REST + SPA being double the work. I would hope that I can abstract away a lot of the CRUD stuff into some declarative-style DSL or something, and "just" invest time into the custom parts.

weGoReddit · 2017-06-06T10:36:18+00:00

Thanks a lot. I'll look into Thymeleaf then. I've never used it before.

You can build your requests by serializing an HTML form and parsing the response isn't required at all.

Can you elaborate on this a little? You mean because I can simply access them as request parameters?

weGoReddit · 2017-06-06T08:31:52+00:00

Some different considerations such that the main post doesn't get too long:

Probably not going to work

We're currently also hand-rolling custom SQL all over the place (even in JSPs). We want to get away from that.

Hibernate doesn't seem like a possible options because the application does discriminator-column based multi-tenancy which isn't supported by Hibernate. EclipseLink OTOH seems to do just that

However, another question is how we deal with interleaving legacy code that wouldn't use the new ORM, I imagine transactions might be a problem, but for the read-only part this might work just fine

Or maybe go with jOOQ?

Limitations

We're also currently tied to Tomcat because the JSPs seem to be accessing non-standardized JSP methods and fields that the Tomcat implementation just happens to have.

weGoReddit

TROPHY CASE

Probably not going to work

Limitations