DEV Community: Antonio Ortiz Pola

Hello word/Work experience part 3

Antonio Ortiz Pola — Tue, 10 Mar 2020 08:03:37 +0000

Here are some of the projects I have been working through my life, feel free to ask questions, share experiences or anything you want to talk about, technologies, system design, tabs versus spaces…

2012 — Zeitek

Vehicle control system

After some time with PHP I decided to try new opportunities, so I got one real big opportunity with a private company who works for the Mexican government, specialized in controlled documents like drivers license, circulation card for vehicles, birth certificates and other secured forms.

My first task there was to create the architecture for a vehicle control system, with payments, fines, and most importantly, valued forms handling (like Circulation card and vehicle plates).

This was the most challenging project that I had, since I had total control over the Technologies, design and technical decisions. The only strict requirement was the use of Java for the web system and Oracle as the database.

The project managers suggested Struts, but after some research, Spring seemed better, with more community and improvements in each release, but since I loved the standards and Java EE 6 was just out of the oven, I created a quick proof of concept and fell in love with the dependency injection and JPA as ORM. I had tried in the past with JE2E, but the extra XML config turned me down, but now there was annotations, allowing me to configure the class in the same file as the code, and this was great, a game changer for me.

So, the stack ended up being:

Java and Java EE 6
- JPA Implementation with Hibernate
- JSF 2.0 for the user interface
- RichFaces and latter PrimeFaces for the components interface
- Implementation of dependency injection, transaction management for JPA and partial updates for the interface
Glassfish server
Jasperteports for report generation
Oracle database
Maven for dependency management
Subversion and latter git for source management

Some tools used:

Atlassian products (All introduced, installed and managed by me):
Jira for task management
Confluence as documentation hub
Bitbucket for source code control
Jaspersoft Studio for report design
Netbeans as IDE
JRebel for Java hot update for development (avoid web server restart when the code changes)

I had two project managers, but they were from other state, and their support faded away in early stages of development, latter they helped us from time to time, so I felt happy to take control over the project, but saying that I was responsible of the system success would be far from truth, I had the opportunity to rewrite the selection test for new developers.

(I have share permission, it is not in use anymore), and selected a really great team, which grew up for 2 years from only me, to 5 developers and one tester.

The previous system was old, had no docs, validations, it needed constant restarts and had no reliable information, the migration process included data cleaning, formatting, merging, completing and validation once a citizen made a visit to any of the state offices.

Other of the big difficulties that we found was the fragmentation of the information in the organization itself, some groups thought a process in a certain way, while others was sure it was different, there was no single source of truth, so the taking requirements include being mediator between parts, make standards, formal definitions and create all the validations to have meaningful information in the new system. The system took almost one year in development, from the very start to the first day in production, after that, it entered a cycle of weekly updates including bug fixes, new reports and features.

This was a very personal success for all the team involved since we all where from the same State, so it was great to help at that scale, we could never got official numbers from the previous system, but the improvements in time required to make a government procedure were cut in half or more, and the overall opinion about the system was good, office workers and citizens making procedures said positive things about the new system.

The system was complex, with more than 200 different views with constant changes, and network and hardware restrictions in some offices (some offices had thin clients with less than 250mb of RAM, or connected to old phone modems), but It was also very stable, It could work with no problems in the payments season, when lots of people go to the offices to make procedures, handling between 1 and 1.5 millions of procedures yearly, implemented in around 130 offices around the state. The system was in use from 2014 to 2018, when changes in government forced the implementation of a new integral system with other institutions.

Ended up learning a lot of things from this experience, but to mention some:

You need to take account of the learning curve of your tools, for a newcomer the full Java EE stack is overwhelming
The Developer Experience matters (the experience that the developers have when they contribute code to a system), not only the User Experience
It is better start slow, with solid foundations, and then growing can be faster, starting faster to have “something to show” almost always will slow you down in the future
It is hard to work for organizations with no organization, before design anything, everybody must be in the same channel, have formally defined roles and tasks
Your value as programmer it is not only the technical expertise, but the capacity to understand and model the business process of the organization
Same with the code, its value does not come from the technical complexity, but from the real usefulness and the knowledge that holds for the organization
Caches are a great tool for information that does not change constantly
You need to improve both your technical skills, and your people skills, developing system is a group effort, it needs communication, leadership and participation from all parts involved
And many more things, this was a great experience

The other systems

After the success of the project, I had the opportunity to rework the code to implement Java EE 7 and improve its modularity, making possible to use the same code base in several other projects. It was great to reuse full modules as user, profiles and security control, among a ton of other classes and functionalities.

This allowed us to work in two projects in parallel, sharing improvements and some code parts. The new version included restful endpoints for Android applications. This system base was forked several times for other projects for various States in México.

The system hold a really great flexibility, allowing us to adapt it to our clients requirements, like the use of other databases (It was implemented in Oracle, latter in SQL Server and PostgreSql), the addition of new modules or the personalization of the current ones.

Thanks to keep our accidental complexity low, we could be focused of the business itself, we had to learn legislation and deal with knowledge fragmentation inside the institutions and the lack of systematic procedures, but once the requirements were defined and approved, our response times were praised in several occasions.

I got to travel to some states in México, and worked with some really great people!, after some time I really wanted some new challenges more technical than business oriented, so I moved from my natal state to Monterrey, México.

2010 — TECODA

The same people from our residencies called my friend and me for our good performance to be developers in a small startup working for a seafood store with 7 branch stores. The system started as a simple Point of Sale, with a Java Swing Client in each branch and a central server with a web admin system for the accountants and administrators.

This was our first real big application, the code was a mess, so we started refactoring and improving the performance of several slow pages. The system started to grow with modules like personnel and accounting control, loan handling to employees, credits, product traceability (very important for Federal rules about Seafood distribution), pay sheets and many other things.

Here our stack was:

Again, PHP with CodeIgniter
Apache server
PostgreSql database
JQuery and heavy ajax usage
Subversion for source control

In this project we did everything, from doing the interviews with the customers, get the requirements, plan the development, make the changes, test and present to the clients, it was a lot fun! Eventually we had three developers at our charge, teaching guiding and administrating the tasks for them.

Some months later we changed the application to handle a big shoe factory and optimized the code to handle a catalog of more than 75,000 different products with around 250,000 product movements per day.

Sadly, those systems were internal, so I cannot show you some captures, but I can share you what more I learned:

You need formality for and from the clients, you need to document the requirements, agreements and decision making to keep the stakeholders in the same channel as your team
The value of your work as architect does not only come from technical knowledge, but also from the business knowledge
SVN is hard when there is a lot of people
Writing bad code almost always comes to bite you in the future, some code is only understandable for the developer who wrote it, and after some time not even for himself
The technical debt is real, expensive and grows exponentially if you do not take care of
Handle backups, no matter how confident you are in your software and hardware

2009 — COECyT Michoacán

This was during my professional residencies, COECyT means “Consejo Estatal de la Ciencia y Tecnología” (State Council of Science and Technology), here we made some web pages.

I worked with a friend in the sites, again, the pages are no longer available, and others are internal, but some sites looked like this (With the header fixed, I did not find the final version).

2007 — Point of sale for spare parts for mobile phones

This is where my “real” experience started, I played with a lot of things, but this was my first project used in production in a real store.
The project was simple, purchases from providers, sales to clients, some simple reports. It was made with a friend, he oversaw databases and some store procedures, I was in charge of the user interface and the user manual.

The main stack used:

Java 1.6
Java Swing for the user interface
MySQL for the database

The main, or unique idea, was the compatibility list, which allowed to capture the accessory with the models of the cellphones they were compatible, simplifying the training for new employees, this software was in production around four years, and was just spaghetti code glued everywhere, but it worked!

Latter version one was updated by version two, with the same functionality but a reduction in code, here heavy inheritance was implemented in the components, lazy loading for the long lists and a lots of code customization for the interface.

Sadly I do not have the code anymore, but I do have the manual!

What more did I learn:

Programming is fun with friends
It is never too early to refactor code
You need good initial and detailed requirements (If you do not know where you want to go, then you will end in a place where you do not want to be)
A system in use is a system with change pressure, it is not just that “it works” it needs to be maintainable
Try to avoid duplicate code

Hello word/Work experience part 2

Antonio Ortiz Pola — Tue, 10 Mar 2020 08:03:29 +0000

This was one of the best experiences, while it was not part of my professional job, it was an interesting project.

2013 — Multitouch table

While I was working in Zeitek, and since I love to learn new technologies, I got together with two friends to play with some techniques to create a multi-user multi-touch table. Everything here was made on our free time with budget for our pockets.

Software

The idea was to learn while playing with the software, but the best way was to create a demo or a demo system, so, we started with the idea of a coffee shop with interactive tables, you could check the menu, ask for food or drinks, even play with friends, invite someone a drink, or ask and vote for songs!

We started with ideas and a whiteboard, little by little, we refined the idea and then made some mockups, after the idea was clear, we designed the database and started working in different modules in the application.

Hardware

From the hardware perspective, we create several prototypes, but 2 mayor updates:

First model (OpenCv with PS3 camera)

Our first model used 6 PS3 cameras and two 19" dismantled monitors with an enlighten acrylic, with a frame with infrared leds flooding the acrylic with light, so when a touch is presented the light is reflected and captured with the PS3 cameras which was previous modified by changing to a wider lens and removing the infra-red block filter, adding an only infrared filter (you can get a better and more detailed explanation in this Johannes Luderschmidt post).

The video was processed by an open software based on OpenCv that tracked the blobs from frame to frame and transforms into touch inputs for the operative system.

We designed the table with help of google Sketchup (now just Sketchup) and made it with wood.

Second model (OpenCv with PS3 camera, but better)

For the second model, we made a steel base and a more precise container for the cameras, we tried a design a little more modern, we worked a lot with wood, improving our handcraft and improving the detection of blobs.

Third model (Multi-Touch frame)

After some time, the frames with multi-touch capabilities were cheaper, so we tried a slim version of our table, this time with just one screen. Also, the woodwork improved a lot, we put a lot of love into this, and it was our last work together, since a little after our build was finished, I had a new job offer far away from home, so, this was our last version.

Later I moved to Monterrey, a lot of things that I learned here helped me to get a good job as a developer, this is why this project will always have a place in my heart.

Hello word/Work experience part 1

Antonio Ortiz Pola — Tue, 10 Mar 2020 08:03:21 +0000

Here are some of the things that I have achieved professionally. When I think of each project, it is hard to summarize which project has contributed more to my professional growth as each technology has made a great impact on me.

2015 - Lagersoft

I got a new offer in Monterrey (828.9 km from where I lived), so I decided to try my skills and luck. After working with Java for so long, I started working with C#.

The main project was using

C# 5
.Net Framework 4.5
SQL Server
IIS
AWS EC2 Instances
Github as code repository

I started working in integration with external services at a site with moderate traffic, with recurrent tasks running more than 250,00 transactions per day in the background. Since I like to test the latest features, I also updated .Net Framework to 4.6 and later to 4.7, I also updated the language version to C# 6 (I really wanted string interpolation).

The system was already big, but it was entering to a new expanding phase, with lots of technical debt, so I started promoting a refactoring culture and some talks and advises about architecting software.

Latter, I made several other integrations for deployments around the world, and improved several processes, like a task queue processor from 700,000 to more than 1,200,000 transactions per day with less resources.
I think this was one of my biggest leaps in knowledge as I learned a lot in the first months, including:

Basic AWS and EC2 administration
Parallel deploy of systems around the world
How technical debt can really slow you down in a short term
You need to consider time to create software, but also to maintain it
C# has great tools and libraries, like Entity Framework, Linq and the language itself

I was, and still am, surrounded by brilliant people. I participated in the design of several other projects, one of our heaviest servers started processing around 3 million requests per day and grew to around 8 million.

We are still learning new things every day, pushing our boundaries and learning from each other, it has been a great place to work and grow. The organization gave us a lot of freedom by having us always trying new things and technologies.

Playing with other stuff

Thanks to the organization's open policy for suggestions and developments, I had the opportunity to install XWiki to centralize our documentation, which was spread through mails, chats and technical knowledge of our engineers. We also shifted from Github to Gitlab hosting in one of our instances and started generating our own Nugets to reuse code in several projects.

Thanks to a project that I did with my friends (Carwash, details below), I learned Scala, and latter had the opportunity to build a simple system in Scala. I implemented CI thanks to Gitlab runners and docker. It used Playframework and akka for some simple recurrent tasks (update some log stats in more than 100 different database connections).

Microsoft Net Core era

After this project, a new bigger project started with me as one of the main architects and technology leads. I then worked on the base of a more complex system, with a really high throughput of traffic. This was were our team refined our talent in cloud architecture, creating a complex system with AWS services with Redis, RDS with Aurora, Dynamo, CloudFront, CloudWatch and many others.

The main system is scalable, allowing us to save resources when the traffic is low, and prepare when the traffic is growing. There is still a lot of challenges in this project, but it is working and growing at a really fast pace. It has been the biggest project in which I have been involved in and I am grateful for the opportunity. I continue to search for new ways to improve our codebase and infrastructure.

We discarded IIS and went full Linux deploy, with docker and docker-compose, which was great. We then started designing as micro-services, while the systems started handling more traffic than ever, with a cycle of very frequent changing requirements and process. It has been a truly enriching experience.

2017 — Carwash

This project also deserves a separate post, and has a very special place in my heart, so I will try to keep it short.

I had the opportunity to help my father with a dream business of his, a Carwash called “Pepe y Toño”. It is a small business, the construction is happening step by step with the help of my father, his brother and any help that I can provide.

We searched for software for the business, but almost everything we look at was outdated or over our budget. Besides, a custom program would allow us to apply our development skills.

I contacted my friends from the university and we got together one more time to work on this project.

We started with the mockups using balsamiq (here are some of them)

Then we decided the basics of our architecture, 2 members were in charge of the front end, were they used React, meanwhile me and another friend started working on the back end, for which we used Scala and Play Framework. The reason why we chose Scala was that it was a personal project and we always love to try new things.

Since it was getting fashionable again, we decided to learn functional programming. So, with nothing to lose we started this project.

For the project, I installed a server in my home, were I mounted Gitlab to keep our code repository, it also worked as test server.

The learning curve again was a little hard, I had some problems getting used to this new way of thinking. My last change was from Java to C#, but they were very similar, in Scala the paradigm shift was hard, or I thought so, but latter, watching some videos of Venkat Subramanian, it made things clear to me.

Venkat Subramaniam

@venkat_s

By nature we're wired to mistake familiar as simple and the unfamiliar as complex.

15:41 PM - 01 Oct 2014

27 17

After some time working with futures and functions, it became natural, it was less code, and I loved it! The front end team was also learning React, so our advance was a little slow but very fun. Later, I used what I learned here to create another system in my work with Scala, Playframework and akka.

While I loved Scala and functional programming, I feel more comfortable in other frameworks. Play Framework was great, but I liked spring and AspNet core more.
We decided against going forward with Scala due to the fact Hibernate and Entity Framework had more established communities. Therefore we decided to move the back end to Java and Spring with the help of JHipster, but more on that latter.

2018 Auto parts store

We started working on another project for a friend of a friend, which was a point of sale product for an auto parts store. It was basic (Sales, purchases, clients, providers), but with some customized quirks for the business.

For this project we were very constrained for time, since the four of us knew PHP, Yii was chosen as the framework. I personally wanted to use JHipster with Java and Spring, but only two of us knew Spring, so, we decided to go with PHP. Now, PHP is not my favorite language to say the least, I strongly prefer some other languages like Java or C#, maybe Go, or any static type language, but this is a story for another time.

The stack ended up being

Mysql for the database
PHP and Yii for the web app
Html layout with Inspinia from Wrap bootstrap
Boostrap, jquery and react in some components
A sidecar running Spring with Hibernate search for full text search
Running in an instance in Google Cloud
Code repository was in our Gitlab in house server (now moved to Gitlab.com)

One of the reasons to choose us, was an automated process to update the parts catalog with a list of providers, allowing the business to focus on what matters and not keeping up their catalog updated, this also permits to create sales of products not in stock, to be latter purchased on request (all this process with the help of the software).

Other thing that we put a lot of effort was the product searching, It can be as detailed as you want, specifying brand, year and other things, or you can use our full text search (something that we did not see in other stores) powered by Hibernate Search and Lucene, allowing to make more vague requests from the customers.

This system is in production and we are in the maintain cycle, adding some features on request from our client. It has around 200,000 products and growing each day.

Here I learned more things, like how hard can be to get a full text search working as you want, and to try harder to convince my teammates next time to not use PHP.

2018 Net Core Architecture course mentor

I got the opportunity to be one of the mentors of a course for C# and Net Core, the course last several weeks, each one with one subject (Architecture, Testing, CI/CD, Handling big data and others) each week had 3 days of course, 12 hours a week (3 hours on Tuesday, 3 on Thursday and 6 on Saturday).

I got two weeks, architecture and big data processing, so, I created my presentation about architecture.

Since I wanted to be as pragmatic as possible, I presented a simple problem and ask them how they would design the system, then I give my talk with the power point presentation talking about architecture, definitions, advices and other details. Later we started working on architecture of the problem with this knowledge in a Github repo.

It was heavy to prepare the course, since I love the subject, I wanted to make it the best possible, and while I think a lot about architecture, I do not consider myself a superhero expert. But everything worked fine, and it was fun to work as mentor, I received good feedback at the end of the course!

The end for now

So, these are some of my highlights as programmer, I would really love to hear more histories from more people! I feel so lucky for start programming things so simple, and now, to have an impact in so much people daily life.

I still love programming, and I still love to share knowledge, it is what brought me here today, so I hope I can share with more people, and maybe help some soul like so many forums, blogs, stack overflow answers did and continuing doing for me.

The other parts are older experiences that I like to share, thanks for read till the end, any comment, question, suggestion, I all open! and I wish you a Happy codding!

Hello world/Who am i?

Antonio Ortiz Pola — Sat, 07 Mar 2020 08:44:16 +0000

You can find me mainly here in dev.to and stackoverflow or LinkedIn.

I have also just started a video series about systems architecture!!! (only in Spanish for now).

My main language is Spanish, but i want to practice my English, so I apologize if I make some mistakes writing this, if you find any, you can tell me in the comments so I can amend it.

Some more history

My name is Antonio Ortiz Pola, a computer enthusiast since the 00’s, graduated from “Tecnológico de Morelia” as computational systems engineer. Since then I have been able to participate in several projects as developer and architect.

My motivation for this blog is to return some of the knowledge I have been able to acquire through the years. My origins are humble, but thanks to something as simple as a computer and an Internet connection, my life has changed forever, not only as a window to other worlds and people, but to the way it has contributed to my knowledge base and skills development.

I have always loved sharing knowledge, even as a OSUM Leader (Open Source University Meetup), a Sun initiative to spread open source usage and community. Sadly, Sun was experiencing bad times as it was preparing to be bought by oracle, so the initiative was killed.

Thanks to all the people who take the time to write posts, answer questions, writing books, and almost everything for free, just for sharing. I know I am lucky to live in a world where the open source exists, I love the culture of sharing building blocks of “things”, like Legos, many libraries have been working as building blocks for the software I make.

Customizing JHipster + Vuejs CRUD with the Appworks Layout

Antonio Ortiz Pola — Tue, 01 Oct 2019 02:39:59 +0000

Until now, we just change the JHipster layout, but we have not change a single component. So our next step will be to create a new component based on an existing one, latter we are going to create a totally new one.

Defining what we want to make

If you don't know where you are going, every road will get you nowhere

Henry Kissinger

Or as i read somewhere else:

If you do not know where you want to go, probably you will end up where you do not want to be

We need to define what we want to achieve, for this particular example I am going to use a real life example of a system I am making as a hobby.

Project carwash

I need to make a simple system to control some sales for a car wash business, there are not many requirements, but to help focus I will use just one flow.

Client selection workflow

After gathering some more information and make some interviews we define some use cases, one of them is the client selection, this part is before creating an order of service, some of the requirements are:

This is a basic point of sale for a small car wash.
It should be friendly with touch screens, so it can be used with tablets.
To create an order, a client must be selected or created, with a linked vehicle.
The client can have many vehicles, but a vehicle can have only one owner at time (But it can change his owner).

After some talks and drawings, with some friends we defined some user interface mockups with balsamiq, sorry because the mockup is in Spanish, but our client speaks that language, but it is only to give an idea of our goal.

Starting the JHipster project

With this we can start working in our JHipster JDL:

application {
  config {
    baseName carwash
    buildTool gradle
    devDatabaseType postgresql
    prodDatabaseType postgresql
    clientFramework vuejs
    jhiPrefix bjt
    languages [en, es]
    searchEngine elasticsearch
    packageName com.bejoto.carwash

  }
  entities *
}

DEFAULT_MIN_LENGTH = 1
DEFAULT_MAX_LENGTH = 500


// -----------------------------------
// ********** Vehicles **********

entity VehicleType {
  name String required minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
  enabled Boolean required
}

entity VehicleColor {
  name String required minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
  hexColor String required minlength(6) maxlength(6)
  enabled Boolean required
}

entity VehicleBrand {
  name String required minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
  enabled Boolean required
}

entity Vehicle {
  plate String required minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
  created Instant required
  lastUpdate Instant required
}

relationship ManyToOne {
  Vehicle{vehicleType(name)} to VehicleType
  Vehicle{vehicleColor(name)} to VehicleColor
  Vehicle{vehicleBrand(name)} to VehicleBrand
}


// ********** Clients **********

entity Client {
  name String required minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
  email String minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
  mobile String minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
  enabled Boolean required
  created Instant required
  lastUpdate Instant required
}

relationship OneToMany {
  Client{vehicle} to Vehicle{client}
}


// -----------------------------------
// ********** Configuration **********

dto * with mapstruct
service * with serviceClass
paginate * with pagination
search Client, Vehicle with elasticsearch

This give us some simple relationships

I created my project with this and some more entities with the command

jhipster --blueprints vuejs import-jdl jhipster-carwash.jdl

Vehicle color

To begin with something simple, we are going to start with the crud of the vehicle color catalog.

JHipster already created a simple crud, but we want to add a color selector, so this is a really good practice.

Vehicle color list page

We start with our custom user interface integrating the JHipster components as they are:

To simplify thins, to start I will copy the JHipster component in my folder

As you can notice, the menu is in Catalogs/VehicleCatalogs/VehicleColor, however JHipster generates everything in /entity/entityName, so, we need one more change to our base project, so we can switch the JHipster routes for our custom ones.

Since, I not want the JHipster routes, I will not even try to inherit something, simply copy/paste of the JHipster routes router/index.ts to bjt/router/index.ts, and then removing all routes after the admin part, and then adding my own ones.

As you can see, just one more folder jump was needed for the admin pages, then I can add my component from '../catalogs/vehicle/vehicle-color/bjt-...'.

One more thing, also notice how the component that I will be modifying has the prefix bjt, this is to avoid issues when using inheritance and to quickly identify which components are mine and which from JHipster.

Now we can enter to '/catalogs/vehicle/vehicle-color' and the component BjtVehicleColor will be loading, this component for now can keep the same .vue, but for the bjt-vehicle-color.component.ts file, we can simply use inheritance from the original JHipster component:

@Component
export default class BjtVehicleColor extends VehicleColor {
  public propOrder = 'name';
  public reverse = true;

  public updatePerPage(): void {
    this.page = 1;
    this.retrieveAllVehicleColors();
  }
}

I only override two properties.

propOrder: The property used for the order by, by default is the Id, but for my case the name makes more sense.
reverse: This is to set the order as ascending.

With this in place, I search for a page in Appworks similar in elements, and I found the products list page.

Before continue, I need to make some changes:

I do not want the "view" page, since this is a very simple component I do not think it is worth it.
I also prefer to disable the catalog from the edit page, so I do not need that.
Since I just want an edit page, I can set the link in the element name and make the actions column unnecessary.

From here on, there is simply the task of replace the dummy elements from the Appworks demo page with the code from the JHipster base.

The process was really simple, and I just found some minor inconveniences:

I needed to add a function to handle the items per page select

<b-select size="sm" v-model="itemsPerPage" :options="[5, 10, 20, 30, 40, 50]" class="d-inline-block w-auto" v-on:change="updatePerPage"/>

public updatePerPage(): void {
  this.page = 1;
  this.retrieveAllVehicleColors();
}

The JHipster component jhi-item-count has a little bug and does not change the language, but there is a simple fix and I have already reported it.
I also added some distinction for the sort columns, because there was no indicator of which column and order, simply using more icons, I also created an issue to include this in the default generator.

<th v-on:click="changeOrder('enabled')">
    <span v-text="$t('carwashApp.vehicleColor.enabled')">Enabled</span>
    <i class="fas" v-bind:class="propOrder === 'enabled' ? (reverse ? 'fa-sort-down' : 'fa-sort-up') : 'fa-sort'"></i>
</th>

After some work I have my first custom page!

Add vehicle color page

The next step is to change the creation page, to practice something more complex I will split the creation and update.

A simple justification to change the folder organization from the default

The basic approach will be almost the same as before (inheritance when it make sense, copy/paste and modify if not), but with one exception, I will use a folder for the full "creation vehicle color module", this is because I like to organize my code by feature, not by class type.

This is different from what JHipster generates by default, with all models in one folder, services in other and so on.

I think this is fine for the base, generated project, because it has no business logic, just a generalization of the entities. But when you start customizing the code for your organization, I think this "folder by feature" approach it helps better with the Conway's law.

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

If it is not clear how this could apply here, think in an example: Imagine that you are asked to add some parameter in the edition of the color, but not for the creation, if you keep the JHipster order, you would need to modify in the back-end the packages:

web.rest
service
service.dto
service.mapper
repository
domain

Or you could create all the files in the package

bjt/catalog/vehicle/color/commands/edition

And then modify just one place.

This also takes importance for example, for queries, systems tend to have a giant "query" service with tons of methods that are used individually just in one particular report. It is also easier to move the code, for example if some part of system grows and needs to be their own microservice, or if you need to modify or delete a particular feature.

Of course this is far from perfect and it has also some drawbacks, like code isolation that can lead to code duplication, if there are many simple process it can be hard to navigate through so many folders and classes, it also requires a very good knowledge of the organization, or you can end up consuming your time moving folders around.

In fact, in this particular case, because this is a very simple catalog with straight forward crud operations, maybe this is overkill and just as is is fine, but since this is a practice exorcise, thinking in some bigger user histories and use cases I like to explore my possibilities.

So, from here maybe you see that order in my folders, with some files with dtos, models, services and more in the same place. This does not mean you should do this way, always consider your context (team size, project limits, organizational knowledge, time for the development...).

If you want to read some more about this and other very good architectural ideas, I recommend to check Jimmy Bogard and his "Vertical Slice Architecture" talks or posts, also any talk of Kevlin Henney and architecture, in fact, any talk of him is great!

Back to the show!

So I just created my folder for my creation operation, based on the classes that JHipster generated.

To source code is

bjt-vehicle-color-create.component.ts

...

const vueColor = require('vue-color');

@Component({
  validations,
  components: {
    'chrome-picker': vueColor.Chrome
  }
})
export default class BjtVehicleColorCreate extends VehicleColorUpdate {
  @Inject('bjtVehicleColorCreationService') protected bjtVehicleColorCreationService: () => BjtVehicleColorCreationService;
  public colors = '#000000';
  public vehicleColor: IVehicleColorToAdd = new VehicleColorToAdd('', '000000');

  public updateColor(value) {
    this.vehicleColor.hexColor = value.hex.substring(1);
  }

  public save(): void {
    this.isSaving = true;
    this.bjtVehicleColorCreationService()
      .create(this.vehicleColor)
      .then(param => {
        this.isSaving = false;
        this.$router.push('/catalogs/vehicle/vehicle-color');
        const message = this.$t('carwashApp.vehicleColor.created', { param: param });
        this.alertService().showAlert(message, 'success');
      });
  }

  public cancel(): void {
    this.$router.push('/catalogs/vehicle/vehicle-color');
  }
}

As you can see, it is just inherit from the original component, but adding some new features, like the usage of the plugin vue-color, some methods to help update the color, a cancel method to send direct to the color list (JHipster uses the back action, but in my test this not always works), also the save method was overridden so we can use our own service and final route.

bjt-vehicle-color-create.vue

<template>
    <div>
        <h4 class="d-flex justify-content-between align-items-center w-100 font-weight-bold py-3 mb-4">
            <div>
                <span class="text-muted font-weight-light small">
                    <span v-text="$t('bjtSidebar.catalogs')"></span> /
                    <span v-text="$t('bjtSidebar.vehicles')"></span> /
                    <router-link :to="{name: 'VehicleColor'}" v-text="$t('bjtVehicleColor.create.colors')"></router-link> /
                </span>
                <span v-text="$t('bjtGlobal.create')"></span>
            </div>
        </h4>

        <b-card :header="$t('bjtVehicleColor.create.createColor')" header-tag="h6" class="mb-4">
            <b-form name="editForm" role="form"  novalidate v-on:submit.prevent="save()">
                <b-form-group :label="$t('bjtVehicleColor.create.colorName')" class="position-relative">
                    <b-input type="text" name="name" :placeholder="$t('bjtVehicleColor.create.colorName')" id="vehicle-color-name"
                             :state="!$v.vehicleColor.name.$invalid" v-model="$v.vehicleColor.name.$model" required/>
                    <div class="invalid-tooltip" v-if="$v.vehicleColor.name.$anyDirty && $v.vehicleColor.name.$invalid">
                        <span v-if="!$v.vehicleColor.name.required" v-text="$t('entity.validation.required')"></span>
                        <span v-if="!$v.vehicleColor.name.minLength" v-text="$t('entity.validation.minlength', { min: 1 })"></span>
                        <span v-if="!$v.vehicleColor.name.maxLength" v-text="$t('entity.validation.maxlength', { max: 500 })"></span>
                    </div>
                </b-form-group>


                <b-form-group :label="$t('bjtVehicleColor.create.color')">
                    <chrome-picker :value="colors" @input="updateColor" />
                </b-form-group>
                <b-btn variant="primary" type="submit" id="save-entity" :disabled="$v.vehicleColor.$invalid || isSaving">
                    <font-awesome-icon icon="save"></font-awesome-icon>&nbsp;<span v-text="$t('entity.action.save')">Save</span>
                </b-btn>
                <b-btn id="cancel-save" variant="outline-secondary" v-on:click="cancel()">
                    <font-awesome-icon icon="ban"></font-awesome-icon>&nbsp;<span v-text="$t('entity.action.cancel')">Cancel</span>
                </b-btn>
            </b-form>
        </b-card>

    </div>
</template>

<style src="@/vendor/libs/vue-color/vue-color.scss" lang="scss"></style>

<script lang="ts" src="./bjt-vehicle-color-create.component.ts">
</script>

This view is also based on the forms from appworks, but replacing the dummy components with the one form JHipster.

bjt-vehicle-color-creation.service.ts

const baseApiUrl = 'api/bjt/vehicle-colors';

export default class BjtVehicleColorCreationService {
  public create(entity: IVehicleColorToAdd): Promise<number> {
    return new Promise<number>(resolve => {
      axios.post(`${baseApiUrl}`, entity).then(function(res) {
        resolve(res.data);
      });
    });
  }

Simple custom service class, here is not helpful to extend from the original class, if you need some functionality from the original service, you can simply inject the original JHipster service.

vehicle-color-to-add.model.ts

export interface IVehicleColorToAdd {
  name: string;
  hexColor: string;
}

export class VehicleColorToAdd implements IVehicleColorToAdd {
  constructor(public name: string, public hexColor: string) {
  }
}

Here I could handle all my complex models, bur for now, it is a simpler model of vehicle color, since the Id it is just needed in the edition, and also considering that a color that is added to the system by default is enabled, I just need to send the name and hex representation of the color to add the entity.

Modifying the backend

Since I am using my own service, I need to make some modifications in the backend. Taking the same side by side approach, I create a bjt package from where all my code will reside.

The backend is almost identical to the JHipster code and I hope auto explanatory for now:

BjtVehicleColorCreatorService

...
public Long save(VehicleColorForAddDTO vehicleColorForAddDTO) {
    log.debug("Request to save VehicleColor : {}", vehicleColorForAddDTO);

    VehicleColor vehicleColor = new VehicleColor();
    vehicleColor.setName(vehicleColorForAddDTO.getName());
    vehicleColor.setHexColor(vehicleColorForAddDTO.getHexColor());
    vehicleColor.setEnabled(true);
    vehicleColor = vehicleColorRepository.save(vehicleColor);
    return vehicleColor.getId();
}

BjtVehicleColorResource

...
@RestController
@RequestMapping("/api/bjt")
public class BjtVehicleColorResource {
    ...
    @PostMapping("/vehicle-colors")
    public ResponseEntity<Long> createVehicleColor(@Valid @RequestBody VehicleColorForAddDTO vehicleColorForAddDTO) throws URISyntaxException {
        log.debug("REST request to save VehicleColor : {}", vehicleColorForAddDTO);

        Long savedId = bjtVehicleColorCreatorService.save(vehicleColorForAddDTO);
        return ResponseEntity.created(new URI("/api/vehicle-colors/" + savedId))
            .headers(HeaderUtil.createEntityCreationAlert(applicationName, true, ENTITY_NAME, savedId.toString()))
            .body(savedId);
    }
}

VehicleColorForAddDTO

...
public class VehicleColorForAddDTO implements Serializable {

    @NotNull
    @Size(min = 1, max = 500)
    private String name;

    @NotNull
    @Size(min = 6, max = 6)
    private String hexColor;
    ...
}

Some happiness!!!

And finally, again, a light at the end of the tunnel, we went from

Edit vehicle color page

Now, I can simply copy the creation folder, but modifying the names.

From here, the pages are very much the same as the creation ones, so I make some modifications so its worth it, like:

bjt-vehicle-color-edit.component.ts

...
export default class BjtVehicleColorEdit extends VehicleColorUpdate {
  @Inject('bjtVehicleColorEditionService') protected bjtVehicleColorEditionService: () => BjtVehicleColorEditionService;
  public colors: String = '#000000';
  public vehicleColor: IVehicleColorToEdit;
  public isEnabled: boolean = false;

  beforeRouteEnter(to, from, next) {
    next(vm => {
      if (to.params.vehicleColorId) {
        vm.retrieveVehicleColor(to.params.vehicleColorId);
      }
    });
  }

  public updateColor(value) {
    this.vehicleColor.hexColor = value.hex.substring(1);
    console.log('update color');
  }

  public save(): void {
    this.isSaving = true;
    this.bjtVehicleColorEditionService()
      .update(this.vehicleColor)
      .then(param => {
        this.isSaving = false;
        this.$router.push('/catalogs/vehicle/vehicle-color');
        const message = this.$t('bjtVehicleColor.edit.colorUpdated', { name: this.vehicleColor.name });
        this.alertService().showAlert(message, 'success');
      });
  }

  public cancel(): void {
    this.$router.push('/catalogs/vehicle/vehicle-color');
  }

  public retrieveVehicleColor(vehicleColorId): void {
    this.vehicleColorService()
      .find(vehicleColorId)
      .then(res => {
        this.colors = '#' + res.hexColor;
        this.isEnabled = res.enabled;
        this.vehicleColor = new VehicleColorToEdit(
          res.id, res.name, res.hexColor
        );
      });
  }

  public disableVehicleColor(): void {
    this.bjtVehicleColorEditionService()
      .disable(this.vehicleColor.id)
      .then(() => {
        const message = this.$t('bjtVehicleColor.edit.colorDisabled', { name: this.vehicleColor.name });
        this.alertService().showAlert(message, 'danger');
        this.$router.push('/catalogs/vehicle/vehicle-color');
      });
  }

  public enableVehicleColor(): void {
    this.bjtVehicleColorEditionService()
      .enable(this.vehicleColor.id)
      .then(() => {
        const message = this.$t('bjtVehicleColor.edit.colorEnabled', { name: this.vehicleColor.name });
        this.alertService().showAlert(message, 'success');
        this.isEnabled = true;
        this.closeEnableDialog();
      });
  }

  public closeDisableDialog(): void {
    (<any>this.$refs.removeEntity).hide();
  }

  public closeEnableDialog(): void {
    (<any>this.$refs.enableEntity).hide();
  }
}

Now the edition page has the disable/enable action instead of the listing, so I handle two dialogs and service calls for each action, the other modifications are the loading of the color data.

bjt-vehicle-color-edit.vue

<template>
    <div>
        ...

        <b-card :header="$t('bjtVehicleColor.edit.editColor', { name: vehicleColor.name })" header-tag="h6" class="mb-4" v-if="isEnabled">
            <b-form name="editForm" role="form"  novalidate v-on:submit.prevent="save()">
                <input type="hidden" id="id" name="id"
                       v-model="vehicleColor.id" />
                ...
            </b-form>
        </b-card>

        <b-card :header="$t('bjtGlobal.otherActions')" header-tag="h6" class="mb-4">

            <div class="container">
                <div class="row" v-if="isEnabled">
                    <div class="col-sm col-sm-3 ">
                        <b-button variant="danger" v-b-modal.removeEntity>
                            <span v-text="$t('bjtVehicleColor.edit.disableColor')"></span>
                        </b-button>
                    </div>
                    <div class="col-sm alert alert-danger" role="alert" v-text="$t('bjtVehicleColor.edit.disableMessage')">
                    </div>
                </div>
                <div class="row" v-if="!isEnabled">
                    <div class="col-sm col-sm-3 ">
                        <b-button variant="success" v-b-modal.enableEntity>
                            <span v-text="$t('bjtVehicleColor.edit.enableColor')"></span>
                        </b-button>
                    </div>
                    <div class="col-sm" v-text="$t('bjtVehicleColor.edit.enableMessage')"></div>
                </div>
            </div>
        </b-card>

        <b-modal ref="removeEntity" id="removeEntity" v-if="isEnabled">
            <span slot="modal-title"><span id="carwashApp.vehicleColor.delete.question" v-text="$t('bjtGlobal.disableOperationTitle')"></span></span>
            <div class="modal-body">
                <p id="bjt-delete-vehicleColor-heading" v-text="$t('bjtVehicleColor.edit.disableQuestion', { name: vehicleColor.name })"></p>
            </div>
            <div slot="modal-footer">
                <b-btn variant="danger" v-on:click="disableVehicleColor()">
                    <font-awesome-icon icon="trash"></font-awesome-icon>&nbsp;<span v-text="$t('bjtGlobal.disable')"></span>
                </b-btn>
                <b-btn variant="outline-secondary" v-on:click="closeDisableDialog()">
                    <font-awesome-icon icon="ban"></font-awesome-icon>&nbsp;<span v-text="$t('entity.action.cancel')">Cancel</span>
                </b-btn>
            </div>
        </b-modal>


        <b-modal ref="enableEntity" id="enableEntity" v-if="!isEnabled">
            <span slot="modal-title"><span v-text="$t('bjtGlobal.disableOperationTitle')"></span></span>
            <div class="modal-body">
                <p v-text="$t('bjtVehicleColor.edit.disableQuestion', { name: vehicleColor.name })"></p>
            </div>
            <div slot="modal-footer">
                <b-btn variant="success" v-on:click="enableVehicleColor()">
                    <i class="fas fa-check"></i>&nbsp;<span v-text="$t('bjtGlobal.enable')"></span>
                </b-btn>
                <b-btn variant="outline-secondary" v-on:click="closeEnableDialog()">
                    <font-awesome-icon icon="ban"></font-awesome-icon>&nbsp;<span v-text="$t('entity.action.cancel')">Cancel</span>
                </b-btn>
            </div>
        </b-modal>

    </div>
</template>

The component is almost the same, with some extra details (like using the name of the entity for the header), but most important, it integrates the two dialogs to allow disable or enable the color.

bjt-vehicle-color-edition.service.ts

public update(entity: IVehicleColorToEdit): Promise<number> {
  return new Promise<number>(resolve => {
    axios.put(`${baseApiUrl}`, entity).then(function(res) {
      resolve(res.data);
    });
  });
}

public disable(id: number): Promise<number> {
  return new Promise<number>(resolve => {
    axios.get(`${baseApiUrl}/${id}/disable`).then(function(res) {
      resolve(res.data);
    });
  });
}

public enable(id: number): Promise<number> {
  return new Promise<number>(resolve => {
    axios.get(`${baseApiUrl}/${id}/enable`).then(function(res) {
      resolve(res.data);
    });
  });
}

The services for my custom actions.

Then, putting everything togheter, I have my first custom crud component.

Replacing JHipster UI components (Part 2. Adding SideNavbar and customizing more components)

Antonio Ortiz Pola — Thu, 19 Sep 2019 05:42:52 +0000

In the last part, I changed the top navbar with the same functionality as the JHipster one, it is time to customize it a little to add our own flavor.

Customization for Navbar

First, I am going to use flag-icon-css to make the language bar more descriptive. As their docs says, I simply run

npm install flag-icon-css

After installation, I need to copy the svg files to my content folder, so the styles can be load correctly.

node_modules/flag-icon-css/sass/flag-icon.scss

app/bjt/sass/flag-icon.scss

But I need to override the variables file, so I can update the path where the svg files are, to keep things simple I will customize my new flag-icon.scss

// Override paths for svgs
$flag-icon-css-path: '/content/bjt/vendor/flags' !default;
$flag-icon-rect-path: '/4x3' !default;
$flag-icon-square-path: '/1x1' !default;

@import '~flag-icon-css/sass/flag-icon-base';
@import '~flag-icon-css/sass/flag-icon-list';

And then in my bjt/bjt-style.scss

@import 'sass/flag-icon.scss';

Now, just to run a test, I can add somewhere the styles

<span class="flag-icon flag-icon-gr"></span>
<span class="flag-icon flag-icon-gr flag-icon-squared"></span>

And now we have some flags!

But not everything could be that good, soon I hit a wall, a very difficult one.

Vue.js and TypeScript `super` are not much of a friends

This next part is based in some search and my little knowledge of Vue, if there is something wrong or if there is a better way please let me know!

While in angular I could take advantage of inheritance and calling super to execute code already placed in the JHipster parent classes, in Vue.js it is not the case, as Ashraful Islam says:

So far (VueJS v2) we don't have class based component like react. *.vue has it's own syntax rather than traditional javascript.

Investigating a little more, I realized that this is not only true, it is like this by design and I do not think this will change soon, as many will know this is an old discussion in vue.js, with highlights like:

My opinion is that ES6 classes offer no practical advantages over plain object definitions except for syntax preferences.

I don't think I'll ever change Vue's default API to use classes.

And most important:

People who "just want classes" probably never actually tried to envision what the equivalent of Vue's current API would look like using classes ...

... Well, I have tried, and my conclusion is using only specced features from ES2017, there's simply no way to provide something that is elegant enough. You end up with tedious constructor calls (and don't forget super, binding instance methods to this), awkward workarounds like static get option () { return { ... }} or attaching static properties after the class declaration block, etc. etc.

https://github.com/vuejs/vue/issues/2371#issuecomment-330068362

While I do not entirely agree with yyx990803 opinion, I totally understand his point of view

... the standard today is not good enough to provide a decent equivalent of Vue's current API

There has been a lot of debate about the best approach on how to program user interfaces (functional, OOP, mutability/immutability..), I preffer to be a little more verbose to be more clear, with "type safe" and static code checking. At the same time I found vue.js more easy to develop and less ceremonial than angular (declare components, use modules if they are going to be used in other components), so, I get the fact that it has not the same design in mind, and there are always trade offs.

So vue.js preffers this

export default {
  props: {
    propA: {
      type: Number
    },
    propB: {
      default: 'default value'
    },
    propC: {
      type: [String, Boolean]
    }
  }
}

to this

import { Vue, Component, Prop } from 'vue-property-decorator'

@Component
export default class YourComponent extends Vue {
  @Prop(Number) readonly propA: number | undefined
  @Prop({ default: 'default value' }) readonly propB!: string
  @Prop([String, Boolean]) readonly propC: string | boolean | undefined
}

The problem is that JHipster generates the components with classes for angular and react, so trying to fit the same approach with vue.js seems the more sane approach, there is even an official component so you can declare your components as classes, but this is only a partial solution, it takes some annotations and conventions and transforms it into VueJs components with their respective properties.

This causes that, even if you are thinking that you are using classes to program your components, they are not real classes, they are "parsed" to work with vue.js, and, since it does not have classes, it also does not have the notion of super.

I do not know what could be best for JHipster, to change the classes to VueJs components, or leave it as is, so far this is the only major issue I found. It seems to me that it could be a barrier to hold the full VueJs design philosophy, but on the other hand, I am very used to classes and in this particular case it helped me to understand and be productive more quickly, so I will leave the decision to the reader.

In my case, I have to remember my second rule

adapt the layout to JHipster, not the other way

So, I decided that for now, I will change the name of the methods that I need to override to add an underscore _ before, so I do not run into problems, sadly, each modified component means one change to the code to switch between my UI and JHipster's one, it will also mean one more possible conflict when I update my JHipster, but it stills seems an easy task for now.

Back to our show!

To finally include my flags for the language, I need a simple change to the JhiNavbar, make the language protected so I can access the property in my class, and add an underscore to the created method, so I can replace it.

Then, I just need to add some methods to my bjt/bjt-navbar

public flagLanguages = {
  es: 'mx',
  en: 'us'
};
public flag: string;

created() {
  this._created();
  this.flag = this.flagLanguages[this.currentLanguage];
}

And the language drop-down now can use this to be a little more visual

<b-nav-item-dropdown no-caret :right="!isRTL" v-if="languages && Object.keys(languages).length > 1">
    <template slot="button-content">
        <i class="navbar-icon align-middle flag-icon flag-icon-squared" :class="'flag-icon-' + flag"></i>
        <span class="d-lg-none align-middle" v-text="$t('global.menu.language')">&nbsp; Language</span>
    </template>

    <b-dd-item v-for="(value, key) in languages" :key="`lang-${key}`" v-on:click="bjtChangeLanguage(key)"
                     :class="{ active: isActiveLanguage(key)}">
        <i class="flag-icon flag-icon-squared mr-1" :class="'flag-icon-' + flagLanguages[key]"></i>
        {{value.name}}
    </b-dd-item>
</b-nav-item-dropdown>

And now our language bar looks better

And as a last touch, lets make the username accessible also

public get username(): string {
  return this.$store.getters.account ? this.$store.getters.account.firstName : '';
}

And this is starting to look better

Implementing a SideNavBar in JHipster

From now on, we should be able to move a little easier, since we have resolved most of the common issues.

Checking the Appwork demo, the nice page uses the layout2, so I modify the bjt/App.vue file accordingly

<template>
    <div class="layout-wrapper layout-2" id="app">
        <ribbon></ribbon>
        <div class="layout-inner">
            <bjt-sidebar />

            <div class="layout-container">
                <bjt-navbar />

                <div class="layout-content">
                    <div class="router-transitions container-fluid flex-grow-1 container-p-y">
                        <router-view />
                    </div>

                    <b-modal id="login-page" hide-footer lazy>
                        <span slot="modal-title" id="login-title" v-text="$t('login.title')">Sign in</span>
                        <login-form></login-form>
                    </b-modal>

                    <jhi-footer></jhi-footer>
                </div>
            </div>
        </div>
        <div class="layout-overlay" @click="closeSidenav"></div>
    </div>
</template>

Then I create my bjt-sidebar.component.ts file based on the LayoutSidenav.vue component from Appwork.

As you can notice, this is nothing more than a parse to a class of the component. I also created the bjt-sidebar.component.ts with all the view code. And now we are almost done for our base project!

Then I repeat the procedure with the footer component, creating new i18n files if necessary for translation. After replacing the menus with the entities menu, you can say we have a JHipster App base with Appwork layout working!

After admire our work for sometime, I want to compare how many parts did I touched to integrate my layout.

Checking the base files

We have just 5 distinct files from one JHipster untouched project

webpack/webpack.dev.js: Just modified one line to load our styles instead the ones from JHipster
webpack/webpack.prod.js: Same as before
package.json: We installed some new libraries and updated one, this file is expected to change a lot when the system grows
.yo-rc.json: This file is only changed because a random jwtSecretKey is generated each time you generate an application

Checking the source files we can see we did not touch many files

bjt Folder is where all my custom code resides
i18n has some new files with my translations
core/jhi-navbar.component required two changes, make the property currentLanguage protected instead of private, and an underscore to avoid conflicts when overriding a method in the child class
main.ts has 3 changes, the import swap between the JHipster App and mine, the initialization of my custom components and a JHipster style commented to avoid conflicts with my styles
index.html Just some minor changes in head based on the index from Appwork

So, if we want to check our JHipster app, we can make this changes:

1.- Change webpack/webpack.dev.js and webpack/webpack.prod.js so it loads the JHipster styles

  entry: {
    // Change import for JHipster or BJT UX
    global: './src/main/webapp/content/scss/global.scss',
    // global: './src/main/webapp/app/bjt/style.scss',
    main: './src/main/webapp/app/main'
  }

2.- Change imports for App class in main.ts

// Change imports for JHipster or BJT UX
import App from './app.vue';
// import App from './bjt/App.vue';

3.- Uncomment vendor styles in main.ts

// Comment to activate BJT UX
import '../content/scss/vendor.scss';

4.- Change jhi-navbar.component.ts so it uses the created method instead the modified one _created

  // change lines to change between JHipster and BJT UX
  created() {
  // _created(): void {
    this.translationService().refreshTranslation(this.currentLanguage);
  }

As you can see, I added comments so it is easy to find all the parts to change with a search

After this simple changes, we can see JHipster UI is back!

Revert these changes to return to our Appwork layout

Ok, so now we have an easy to update base, almost completely separated from JHipster, we can switch between implementations relatively easy.

In the last part I am going to customize my entities, so they can be more than a simple crud and we can see some examples of side by side in the server side.

Replacing JHipster UI components (Part 1. Navbar)

Antonio Ortiz Pola — Thu, 05 Sep 2019 07:06:56 +0000

In the first part I started working in a separation between JHipster and Appwork codes, in this point we have our App.vue completely separated from JHipster, trying to keep a Side by Side approach.

Replacing JHipster Layout

First I merge the app.vue code from Appwork to my new btj/App.vue, this is simple as adding the missing styles (I will leave the javascript for latter).



<!--*** JHipster part ***-->
<template>
    <div id="app">
        <ribbon></ribbon>
        <div id="app-header">
            <jhi-navbar></jhi-navbar>
        </div>
        <div class="container-fluid">
            <div class="card jh-card">
                <strong>
                Could it be is loading my layout and no JHipster?
                </strong>
                <router-view></router-view>
            </div>
            <b-modal id="login-page" hide-footer lazy>
                <span slot="modal-title" id="login-title" v-text="$t('login.title')">Sign in</span>
                <login-form></login-form>
            </b-modal>

            <jhi-footer></jhi-footer>
        </div>
    </div>
</template>

<!--*** Styles from appwork ***-->
<style src="@/vendor/styles/bootstrap.scss" lang="scss"></style>
<style src="@/vendor/styles/appwork.scss" lang="scss"></style>
<style src="@/vendor/styles/theme-corporate.scss" lang="scss"></style>
<style src="@/vendor/styles/colors.scss" lang="scss"></style>
<style src="@/vendor/styles/uikit.scss" lang="scss"></style>
<style src="./style.scss" lang="scss"></style>

<script lang="ts" src="./app.component.ts">
</script>

This creates a little problem, the layout is using the @ placeholder in the path, which is the base-path of the Appwork demo project, but in my project they are in src/main/webapp/app/bjt/vendor, I could change the paths with a replace, but a quick search shows at least 95 occurrences to replace and maintain :/.

So, searching for other solution I found the definition of @ in JHipster in the tsconfig.json file:

So, I came to the conclusion that it is fine to break my own rules and move the vendor folder from src/main/webapp/app/bjt/vendor to src/main/webapp/app/vendor, in exchange for leaving all the files as is, allowing me to update faster when new versions of Appwork are launched.

Other problem that I found, and that you will find sooner or latter is the mismatch of versions, in this case JHipster was using



"bootstrap-vue": "2.0.0-rc.11"

while appwork is in 2.0.0-rc.16, in this particular case I simply updated to the latest version and crossed my fingers that this will not break the JHipster layout, but hey, I am using Appwork, and I know the JHipster blueprint will update sooner or latter, so, always try to go with the latest stable versions.

Making that move I can start integrating the Appwork components, first adding the app-layout-navbar component to bjt/app.component.ts



...
import LayoutNavbar from '@/bjt/layout/LayoutNavbar.vue';

@Component({
  components: {
    ribbon: Ribbon,
    'jhi-navbar': JhiNavbar,
    'login-form': LoginForm,
    'jhi-footer': JhiFooter,
    'app-layout-navbar': LayoutNavbar // Appwork navbar
  }
})
export default class App extends Vue {
}

And now I can use it in my bjt/app.vue



<template>
    <div id="app">
        <ribbon></ribbon>
        <div id="app-header">
            <app-layout-navbar /> <!--Appwork component-->
            <jhi-navbar></jhi-navbar>
        </div>
        ...
    </div>
</template>
...

Then I can check the app page and feel a win:

But, hey!, something does not feel right...

The style looks different, not like the one from the demo. The answer is in two files, global.scss and vendor.scss, if I remove the code in both files, then the styles shows up fine, but, what are they and where they are coming from?

global.scss

Is where the main styles are located, here is where JHipster adds their custom styles for the default layout.

A quick search for the filename shows that the file is configured in two webpack configuration files.

vendor.scss

This file it is mentioned in the readme.md, from what I understand, it is suppose to contain custom imports and styles of third party plugins

So, again, after some thinking I resolved that I can change both webpack files (prod and dev) so I can replace global.scss with bjt/styles.scss, on the other hand, I do not need vendor.scss, since the styles for appwork layout are already included in the vendor folder.

Sadly this adds more steps to change between my app and the JHipster default app, now I have to:

Replace the import in main.ts for app.vue or bjt/App.vue
Comment/uncomment the vendor.scss import from main.ts // import '../content/scss/vendor.scss';
Replace the global entry from both webpack.dev.js and webpack.prod.js from my implementation or the one from JHipster



entry: {
  // global: './src/main/webapp/content/scss/global.scss', // JHipster
  global: './src/main/webapp/app/bjt/style.scss', // Mine
  main: './src/main/webapp/app/main'
}

While this adds a little more burden, I have to remember that JHipster is suppose to be the base of your application, sooner or later more things will be different, the idea is to keep to minimum the differences, but do not lost focus on developer experience and maintainability, at least replacing the file imports, and not the file itself, I can have less pain if I want to update JHipster or Appwork versions.

Now that bjt/style.scss is included from Webpack, I can proceed to remove it from bjt/App.vue, I also edited the file, so it can include the other styles itself, this way my bjt/App.vue is now clean of all global styles, and styles.scss ended up like this:



// Imports from App.vue
@import '@/vendor/styles/bootstrap.scss';
@import '@/vendor/styles/appwork.scss';
@import '@/vendor/styles/theme-corporate.scss';
@import '@/vendor/styles/colors.scss';
@import '@/vendor/styles/uikit.scss';

// Appwork original style.css file
@import '~bootstrap-vue/src/index.scss';

// Base
//
...

Now we can check our app page again and...

We have the appwork styles! Yehiii... but... again something does not feels good, the navbar is gray, not white, something is still missing in this puzzle.

After checking the navbar component, the differences are obvious, while JHipster uses TypeScript, Appwork is using plain Javascript files, also, the color is not being set because it uses a method called getLayoutNavbarBg().



<template>
  <b-navbar toggleable="lg" :variant="getLayoutNavbarBg()" class="layout-navbar align-items-lg-center container-p-x">

    <!-- Brand -->
    <b-navbar-brand to="/">Vue Starter</b-navbar-brand>

    <!-- Sidenav toggle -->
    <b-navbar-nav class="align-items-lg-center mr-auto mr-lg-4" v-if="sidenavToggle">
      <a class="nav-item nav-link px-0 ml-2 ml-lg-0" href="javascript:void(0)" @click="toggleSidenav">
        <i class="ion ion-md-menu text-large align-middle" />
      </a>
    </b-navbar-nav>

    <!-- Navbar toggle -->
    <b-navbar-toggle target="app-layout-navbar"></b-navbar-toggle>

    <b-collapse is-nav id="app-layout-navbar">
      <b-navbar-nav class="align-items-lg-center">
        <b-nav-item href="#">Link 1</b-nav-item>
        <b-nav-item href="#">Link 2</b-nav-item>
      </b-navbar-nav>
    </b-collapse>

  </b-navbar>
</template>

<script>
export default {
  name: 'app-layout-navbar',

  props: {
    sidenavToggle: {
      type: Boolean,
      default: true
    }
  },

  methods: {
    toggleSidenav () {
      this.layoutHelpers.toggleCollapsed()
    },

    getLayoutNavbarBg () {
      return this.layoutNavbarBg
    }
  }
}
</script>

So, time to practice my TypeScript skills, I create my new Frankenstein component, an hybrid between worlds, this will be my bjt-navbar component, the html part is not changed yet, but, following JHipster structure, I create a new class to contain the Javascript code, calling it bjt-navbar.component.ts.

This class also needs an extra change, since Appworks is using plain Javascript, it acces a property called this.layoutHelpers, this property is used in a lot of components.

Also, it is exporting a list of functions instead of a class, here my ignorance about Javascript comes to confuse me, I could not get an easy way to implement this as a class, on one hand I have the layout helper:



export default {
  get _layoutHelpers () {
    return window.layoutHelpers
  },

  _exec (fn) {
    return this._layoutHelpers && fn()
  },

  getLayoutSidenav () {
    return this._exec(() => this._layoutHelpers.getLayoutSidenav()) || null
  },

  getSidenav () {
    return this._exec(() => this._layoutHelpers.getSidenav()) || null
  },

  ...
}

I can see it is used in globals, which maintains the same structure:



import layoutHelpers from './layout/helpers.js'

export default function () {
  return {
    // Public url
    publicUrl: process.env.BASE_URL,

    // Layout helpers
    layoutHelpers,

    // Check for RTL layout
    get isRTL () {
      return document.documentElement.getAttribute('dir') === 'rtl' ||
             document.body.getAttribute('dir') === 'rtl'
    },

    ....
  }
}

But I could not find where the connection is made, how the component can simply access to the properties this this.layoutHelpers, so, the only way I found to use that classes was to implement a class field:



import { Component } from 'vue-property-decorator';
import JhiNavbar from "@/core/jhi-navbar/jhi-navbar.component";
import globals from "@/bjt/globals";

@Component
export default class BjtNavbar extends JhiNavbar {

  private globals = globals();
  private layoutHelpers = this.globals.layoutHelpers;

  public sidenavToggle = true;

  public toggleSidenav () {
    this.layoutHelpers.toggleCollapsed()
  }

  public getLayoutNavbarBg () {
    return this.globals.layoutNavbarBg
  }
}

It is also really important to notice one thing, my component is extending JhiNavbar, so I can access to all the properties, but this will come little latter, first, I need to check if the navbar style is fixed now, so, I simply replace the appwork component for my new one in bjt/app.component.ts



@Component({
  components: {
    ribbon: Ribbon,
    'jhi-navbar': JhiNavbar,
    'login-form': LoginForm,
    'jhi-footer': JhiFooter,
    'bjt-navbar': BjtNavbar // Look at me, I am the component now
  }
})
...

And finally, we have our custom navbar with the white background

Before proceed, I need to make a little change, I am working with the minimum Appwork starter layout, but to make the best of the layout, I need to be based on the more complete vue-demo example.

Appwork starter

Appwork demo

Luckily the appwork authors has been doing a great job organizing the code, there are not many differences between both projects in the base files (only more pages and a demo.css), so I just add the demo.css in my style.scss.

And then I just replace the content of my bjt/bjt-navbar.vue file with the content from the LayoutNavbar.vue from the appwork demo project.

As you can see, the styles are working fine, however the styles in the dropdown are weird, and the images are not loading.

The images are not much of a problem, I can just remove it for now, anyway, they are images that will not be in the final product, but the dropdown requires a more profound investigation.

The console shows that is not loading the vue component

[Vue warn]: Unknown custom element: - did you register the component correctly? For recursive components, make sure to provide the "name" option.

Here is where my knowledge again limits me a little, here is what I see, searching in Appwork demo project, I can see it is used multiple times:

But I can not find a place where the component is declared or initialized, I Know it is a component from vue-bootstrap, but no special config seems required.

On the other hand, in the JHipster project I found something interesting, JHipster is indeed, declaring each individual component from vue-bootstrap, in config-boostrap-vue.ts:



export function initBootstrapVue(vue) {
  vue.component('b-badge', bBadge);
  ..
  vue.directive('b-modal', bModalDirective);
}

I do not know why JHipster is doing this but not Appwork, but since I am using JHipster as base, I add a file in bjt/config/config-bootstrap-vue-bjt.ts with the components that JHipster is not adding:



import bDdDivider from 'bootstrap-vue/es/components/dropdown/dropdown-item';
import bDdItem from 'bootstrap-vue/es/components/dropdown/dropdown-item';
import bListGroup from 'bootstrap-vue/es/components/list-group/list-group';
import bListGroupItem from 'bootstrap-vue/es/components/list-group/list-group-item';

export function initBootstrapVueBjt(vue) {
  vue.component('b-dd-divider', bDdDivider);
  vue.component('b-dd-item', bDdItem);
  vue.component('b-list-group', bListGroup);
  vue.component('b-list-group-item', bListGroupItem);
}

And then I add my components initialization in main.ts



...
bootstrapVueConfig.initBootstrapVue(Vue);
bootstrapVueConfigBjt.initBootstrapVueBjt(Vue); // My components will be here
...

And finally, we have the navbar from Appwork in our project!!!

Now, thanks to extend the JhiNavbar in my bjt/bjt-navbar.component.ts, I can simply include the JHipster components in my layout with no problem.



export default class BjtNavbar extends JhiNavbar {

Then, it comes the most tedious part, merging the navbar from Appwork Demo to my JHipster project, but it is an easy task, and the results bring alive my new navbar menu.

I hope you can notice how the code did not change dramatically, it is just being replacing the text with the internacionalization utilities and the menus with the JHipster options.

You can also notice how there is no Entities menu, this is because entities will go in the left menu (not introduced yet), also the username is hard coded. Stay tuned for the third part where I will try to refine the top nabvar and insert the left menu from the Appwork demo.

Disclaimer

Sorry if I made some mistakes or do not follow the best practices in the post, again, I am mainly a back-end developer, and I am just learning Vue.js, so, if you find something that could be done in a better way, or if I did assumed something wrong about JHipster, please let me know!

Separating the JHipster layout from a custom UI implementation

Antonio Ortiz Pola — Mon, 02 Sep 2019 17:34:35 +0000

Some background

This is the first part in my series "My approach to side by side in Jhipster with Vue and custom UI Layouts", second part soon!

Why JHipster?

I love JHipster, I have been using it for some toy projects. It has been useful to learn some front end technologies, since I am a back-end developer and I wanted to update my knowledge of the trending Javascript libraries and frameworks for front end.

This article departs from a simple monolith application generated with JHipster 6.2, if you do not know how to install or generate a simple JHipster app, I really recommend to visit their docs for installation or how to generate a simple app.

Why vue?

The React attempt

I stared with React, integrating the Inspinia layout, and loved the easiness of the learning curve to create new components and make them interactive (I even made my first, really simple contribution), however there was some things that were a little harder to understand, like the reducers (I know, maybe some tutorials of the basics could help, but I really wanted to learn doing). Maybe it was my lack of practice with Javascript (I mainly program C# and Java since some time a go).

The Angular attempt

Then I watched Antonio Goncalves and his talk about JHipster side by side, and it was just what I need, I was hitting many of the same problems that he had, so I changed both layout and framework and tried with Angular and AppWorks.

I realized that I was really comfortable with Angular, dependency injection, classes, it was like Net Core or Spring, it was all beautiful (or the most that can be, I am not so good in front end and distribution, user experience and that stuff).

I really wanted to write a post about my experience, but I had so much work (and this was my hobby project), then I watched a video of David Steiman, talking more in detail about side by side and was happily surprised because many of the tips or way to do things seemed really similar to the way I was doing stuff, so if you are trying side by side with JHipster and Angular, I really recommend to watch both videos.

The Vue attempt

While I am really happy with angular, I had a problem, there was one major player missing for the front end, and the blueprint was ready, so, why do not give a try?

I was hesitating, but:

The front end developers in my work are working with Vue, so I can get some extra help with doubts and questions.
I keep seeing many good comments about Vue, comming from a lot of people that I follow.
I know you should not choose a framework based only on some milliseconds of advantage in some benchmarks, but hey, at least it can compete with Angular and React.
Being a programmer for so long, I am really worried about one thing: Developer experience, and, again, many people are saying that Vue is a little more productive and easy to develop, so, why not try and see if fits me?

Why to use other layout?

If you need a simple application, you can just leave the layout as is and add new features with side by side, however, like I said before, I am not so expert in user interfaces, and, while I can see something and think "Oh, this looks ugly", I do not have the esthetic abilities to make it nice and beautiful.

When you start to add UI plugins you need to make sure they look uniform, bootstrap can help, but there are always some details, so, since this is only a personal project with just me, and I love back-end, but I can have some problems designing, Why not pay to an specialist?

Other reason is to try to differentiate from the rest, while the JHipster layout is nice and clean, there is always that "boostrap" feeling (no that is something bad, I must accept this project could me take less time if I stop playing with the base layout).

I have to admit, now that it comes with integration for bootswatch, maybe this will be even less necessary, but, hey, I really wanted my left menu :P.

Starting the work

My first rule is to modify the minimum in the JHipster archives, this can lead to some duplicate code, but in my experience is a lot easier to maintain, specially when new versions with major changes comes out. This is even more true in my case, using an external layout basically means a review to all the front end (I think, still easier than make everything from scratch).

The second rule is to adapt the layout to JHipster, not the other way. The first time it was more a mixture between both and it failed, it was really hard to maintain. So now I try keeping the JHipster structure whenever I can, it is where generally most good practices are, the updates are more frequent and in general is always more elaborate than the demo dashboards of the commercial layouts.

So, the first step is to create a simple JHipster app using the Vue blueprint, I like to use postgresql for both development and production (same environment, same behavior), but you can create it however you like.

Then run the app so you can confirm everything is working fine.

To run this project I am using Intellij with 3 run configurations:

The default spring boot configuration to run the back end.
A NPM configuration to run the front end.
A docker config to start the postgresql server and other services, like elasticsearch.

On the other hand, we have the app work demo application:

My starting point is the index.html file

As you can see, the JHipster page is more complex and handles more cases than our demo page, the appwork demo page mainly loads some styles. Here the changes are simple, I just merge the styles from the layout.

As you can see, not much happened here, I just changed

<%= BASE_URL %>

Because in the layout the static resources are in base, but in JHipster the resources are in the content folder, so I just paste the folder in a new folder called bjt (my private package), so I can mark where my resources are, and where the JHipster resources stay.

The next important point where modifications are needed is in the App.vue file, it is the one where the app is loaded.

Here you can note more differences, the JHipster app has the layout declared, while the Appworks app only loads a simple component, so we need to investigate more.

Appworks contains several layouts to work with, to keep things simple we will just work with one layout, the default one, peeking in the router we can see is the one that the demo is displaying.

So, the real comparison needs to be between JHipster app.vue and the Appwork Layout1.vue files, luckily the structure is way more similar now:

Now we have a place where we can start replacing the JHipster components with ours!

Before continuing, I create a new folder in app called bjt, again, this is the point where my code begins, o at least most of it.

Then, I need to change the point where app.vue is loaded, so I can load mine, a quick search for the filename reveals our precious place in main.ts:

So, to start practicing, I modify my bjt/App.vue to be exactly as the one from JHipster, and I copy the app.component file to my folder (Appwork includes the Javascript in the same file as the view, but I like JHipster order more), then I make a little modification so I can see if the layout changes accordingly.

So, now the real test, I just run the project, the layout should come out normal.

But, if we modify the import in main.ts:

Then we can see our custom App.vue!

Now we can start to modify code more aggressively, not worrying about breaking the JHipster for when the app updates, you can even turn back to the JHipster layout by simply changing the imports in main.ts.

In the second part I will start to integrate the components from Appwork to my JHipster app, I Hope you like it!.