33 Beiträge markiert mit "Web Development"

Ask a general AI assistant for a search field that waits until the user stops typing, and you'll often get a raw thread and a sleep call. It compiles, but it isn't how a webforJ app should do it, and you end up rewriting it by hand.

Agent skills for Java fix that. Also called Claude Code skills for Java, they teach the assistant how the framework expects things to be done. webforJ ships eight skills in its AI plugin, and Claude Code loads the right one when your prompt matches the task, so the same request comes back with a Debouncer instead.

You have a Spring Boot app, a few server-rendered pages and a growing list of things that should react to the user without a full reload. Someone suggested htmx, and it is a fair suggestion. Then you count what each interaction needs, and the template files and fragment endpoints start to add up.

If you are weighing an htmx alternative for Spring Boot, the short answer is webforJ, the full-stack Java framework. You build each screen as a Java class made of components, handle their events in Java and inject your Spring services into the class. There are no templates and no fragment endpoints to write, so the interactive UI for Spring Boot comes without JavaScript.

You install an npm package in a webforJ app by declaring it on the view class. @BundlePackage names the package and its version range. @BundleEntry names the module you use. The build installs the package with Bun and compiles it into the app, so you don't set up a Node toolchain. This is the common way to bring a web component library into a Java web app. Your Java code then creates the component by its tag name and uses it like any other control.

A combo box in Java lets users pick an option from a list or type a value of their own. In webforJ, the ComboBox component handles both in one control, and you build it entirely in Java. This guide builds a country picker step by step. You will add preset items, set a placeholder, cap the dropdown height, turn custom input off for a field that needs a fixed answer, and read what the user chose.

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.

We all probably know this situation; browsing a website or webapp, make a simple misclick and instinctively try to go back or undo it. Only to then be somewhere completely else, worst case not even on the site anymore.

Seeing that user experience is one of the most important factors in modern web development, that scenario is one of the many reasons why a robust and well-maintained routing system is so important for your Single Page Application (SPA).

In this article, I will give a quick overview on how to achieve that with webforJ. First we will take a look at movement between views, preserving different states, and in general intuitive interaction with our app. In around 10 minutes, you should be able to set up routes, handle advanced navigation scenarios, and follow the best practices for future maintenance.

Several kinds of forms exist online: sign-up forms, order/checkout forms, and surveys. Regardless of the type of form you’ll need for your business, a bad UI can cost you returning customers. A staggering 88% of users won’t come back to a website if they had a negative user experience, so you’ll need to get it right on the first try.

While the majority of this content focuses on the single-line TextField component, you can apply these principles throughout your webforJ app to help prevent abandonment and make your forms stand out.

As I went through my computer science education at Oregon State, I realized pretty quickly that I enjoyed the UI side of things. Messing around with CSS (yes, even trying to center a div) and making pages that looked nice appealed to me way more than databases and business logic.

Somehow, I ended up working at a company that primarily used Java. Lucky for me, the project I ended up on was a Java web framework - back in my comfort zone!

I've been able to keep myself pretty much in UI land since then, in my comfort zone and happy to let my colleagues deal with all that back end stuff.

Recently our framework, webforJ, released Spring integration, and with that, my blissful isolation in UI land came to an end. As my first foray into full-stack development, I was asked to build a (very, very simple) CRUD application using Spring and webforJ both so I could learn more about the back end, and also showcase webforJ and Spring together in one project.

TLDR: It went well.