73 Beiträge markiert mit "Spring"

You are evaluating a business app platform for your next internal tool, or you run on a platform such as CUBA and are planning your next move. Either way the same question shows up in the planning meeting: do we adopt a platform with its own model for entities, screens and tooling, or do we write a normal Spring Boot app and add a UI to it?

If you want a Jmix alternative that stays plain Java, webforJ, the full-stack Java framework, is that choice. You build views in Java that plug into your own Spring Boot app, use your own Spring Data repositories, pick your own security setup, and keep a project layout you could explain to any Spring developer on day one.

Your team has a backlog of internal tools, a deadline measured in weeks, and a quiet worry about what happens when a drag-and-drop platform meets the first requirement it can't express. Rapid development in Java for the web doesn't need a proprietary builder. With webforJ you generate a working project in a minute, assemble screens from ready components, and keep every line as normal Java that your IDE, your build, and your reviewers already understand.

You have a database that has been running for years. The tables are in good shape, a few Java services already read them, and now someone wants a screen where people can browse the rows, search them and fix a value without opening a SQL client.

A Java web front end for a database needs four things: an entity mapped to the table, a repository, a grid, and a form. With webforJ, the full-stack Java framework, you write all of it in Java. Spring Data JPA reads the table, the SpringDataRepository adapter hands it to a webforJ Table, data binding drives the edit form, and route annotations lock the screen down. No separate front-end project, no REST layer in between.

Many Java teams run a React or Angular front end that only exists to show what their Spring backend already knows. Every feature gets built twice, once on each side of a REST layer, by two sets of people with two toolchains.

If you want to replace React with Java, or move from Angular to a Java UI, you can do it one screen at a time. Each screen becomes a webforJ view that calls your Spring services directly, and the front end and its REST layer fold into one Spring Boot project.

Almost every business app starts with the same screen: a username, a password, and a Sign in button. Building it by hand means a dialog, two required fields, an error message and a button that shouldn't be clicked twice, before you've checked a single credential.

A Spring Boot login page with a Java UI takes one component in webforJ. Login brings the dialog, the fields, the checks and the error message, so your code only has to decide whether the credentials are right.

Your team maintains an app built around action classes, JSP views, and a mapping file. It works, the business rules inside it are valuable, and every new screen still means touching three or four files in different places. If you are planning a Struts to Spring Boot migration, or weighing an Apache Struts alternative, the short answer is webforJ, the full-stack Java framework, with your Spring Boot services plugged in: each action and JSP pair becomes one Java view with a route, the markup and tag libraries become Java components, form beans become validated data binding, and your services carry over unchanged.

Your team has a JSF app with a rich component library on top. The data tables, dialogs and forms all work, but every screen means an XHTML file, a managed bean and a set of update attributes that decide which part of the page refreshes. Adding a screen feels heavier than it should, and nobody on the team wants to change the view layer more than necessary.

If you are searching for a PrimeFaces alternative that keeps the rich component idea and drops the XHTML, webforJ, the full-stack Java framework, is our answer. You build every screen as plain Java classes with a ready set of components (Table, Dialog, Drawer, form fields with data binding), route to them with an annotation, and plug the result into Spring Boot when you have it.

Java web app security best practices start with one choice: keep the interface logic on the server. webforJ does exactly that. Your views run in Java, the browser only renders them, and whole classes of attack never get a foothold. What remains is a short list of habits: gate every route, treat input as untrusted, cap uploads and requests, keep secrets out of the repo, and run over HTTPS. This post covers each one for a webforJ app.

If your team writes Java all day, an Angular front end can feel like a second job: another language, another build, and a REST layer that exists only to feed your own screens.

That is why many teams look for Angular alternatives that stay in Java. With webforJ you write the whole app in Java, plug it into your Spring Boot services, and the browser renders it, with no TypeScript project to maintain.

In my time working with documentation and coding for customers I have built quite the number of demo apps myself, so by now I know what the shortcuts look like. The dataset is always small, with authentication and advanced features "coming soon" or hardcoded in instead of properly implemented. Filtering works fast, because coincidentally there are only five rows to filter. All of that isn't to say those demos are bad, after all they serve their purpose, but I wanted to see how efficiently I could build a demo that doesn't cut corners while still being small and easy to understand.

The webforJ Bookstore is my attempt at that. It's a book inventory manager built on webforJ and Spring Boot with live table filtering, colored genre chips, a data-bound edit drawer, and Spring Security handling who can do what. This post covers the pieces I found most worth writing about.

When building web applications that consume REST APIs, one of the most important decisions you'll make is how to load and manage your data. Load everything at once for snappy client-side operations, or fetch data on-demand to keep memory usage low? The answer, as with most things in software development, is: it depends.

In this post, we'll explore two distinct approaches to loading data from REST APIs in webforJ applications, examining the trade-offs of each and showing you exactly how to implement them using Spring Boot and webforJ's repository patterns.

Remember learning about Model-View-Controller (MVC) in university? For most, at least from what I hear when speaking to others, they had to actually create an app following this design paradigm, which greatly helps any future use of this pattern in the "real world."

For me, that class was right in the middle of COVID. Our instructor was a nice enough guy, but between the Zoom fatigue and lack of experience (I'm fairly sure it was his first or second term teaching), not only did we not end up actually building anything, but we spent time doing theoretical explorations of the various design patterns out there, with MVC only receiving a few days of review.

All this to say that when I started working with webforJ, I saw it as the perfect opportunity to finally get hands-on with MVC—not just to understand the pattern properly this time, but also to learn how webforJ fits into this paradigm. Building a stereotypical todo app seemed like the ideal way to explore both.