I am learning jHipster. My entity relationship model has projects and files. A project can have zero to many files, and a file always belongs to exactly one project.
project <(1:1)-----(0:*)> file
Users interact with the application similar to using an IDE. First, after opening the initial website they always have to select which project they want to work in. (Of course they can also create new projects, or perhaps delete an old one.) Only then they get access to all resources added to a particular project such as files.
As a consequence, my REST API should logically look like this (to get a single file):
GET /projects/{:projectId}/files/{:fileId}
In the backend, depending on whether fileId is a UUID or not, I might even have a method:
findFileByIdAndProjectId(String fileId, String projectId)
The problem is that jHipster creates all entities in a "flat way". Each entity seems to have its own REST API without nesting, and there is simply a reference to an other entity rather than proper composition. Adapting the generated code is quite a bit of work as it requires lots of changes both on the frontend and the backend, but more importantly, it probably breaks the ability to re-create my code when an entity has changed.
I am curious: What different options do I have, and which one would you guys recommend?
Custom code is the way to go though there are few tricks that can help you:
Using DTOs so you can aggregate entities in service layer
Extending generated classes both in backend and frontend so that you don't change generated code, see excellent talk, slides and code samples from Antonio Goncalves
Related
What is the appropriate place to provide RestAPI details while using cucumber? i.e. In Feature file or Step Definition file?
The RestAPI is not really part of the business problem you are solving. Rest is not your core functionality. It is just one, technical, way of using the real functionality you are building.
I would therefore not describe a RestAPI in the feature files using Gherkin. I would hide these implementation details in the glue code connecting the examples written in Gherkin with the system under test.
Cucumber is a tool all about communication between groups of people throughout the business you are working with.
If you're working on a project alone, there is less of the need to describe features in business language (although, it is useful for drafting up ideas using a BDD mindset).
My advice, keep the feature files without code, CSS or any other things that could throw off a layperson. Move these to the step definition file instead, and describe what you're doing in terms that a layperson can understand.
You should store it in the step_definitions file. Keep all the coding tagged to the gherkin steps in the feature file to the step_definitons folder inside which you create a file.
Its always better to keep feature files without the code, they are mainly for better understanding of the testing process and business scenarios and best practise when you view it from BDD perspective.
In case your API values are frequently changing, you can also, mention the values in the cucumber gherkin steps, and pass it as an argument to the step_definitions file. So that any change in the values can be handled in the feature file itself, within the "double quotes" instead of going to the code every-time
On a side note, what gem are you using to test on the REST API? Airborne?
I am new to hapi and for the last few days I've been trying out different project structures in order to keep the concerns separated and the codebase somewhat maintainable while not deviating too much from the "hapi" way of doing things. You can take a look at the folder structure here.
My project consists of a simple RESTful API, so I don't need to worry about views, rendering and so on. What I've ended up doing, and I'm not sure (yet) if this is idiotic or not, is to have the whole API logic (route handling, authorization, db access, etc) registered as a plugin. What this allows me to do is:
easily prefix all the routes with "/api/vX/" for a particular API version
easily swap API versions by registering all the dependencies (basically other plugins) for a particular API version in the plugin itself; this is what I meant in the title by "nested plugins"
I was hoping I could get some insight from other people using hapi and maybe see what what they are using, what's working for them and what's not.
Also, is nesting plugins "hapi"? I've taken a peak at the repos for a few of the popular hapi plugins that are out there and I haven't seen people doing it. Thanks!
Is it be possible to customize/extend JHipster for an organization ?
By that, I mean having a local version that creates some projects with features that are specific to an organization ? For example, using a custom authentication scheme (that still relies on Spring security), using custom styles (colors, fonts), adding certain Maven dependencies and so on.
If this is possible, can it be done while retaining the possibility to update JHipster in such a way that an update of JHipster would not overwrite these extensions ?
Thanks.
Here's the approach in general:
First, we created a blank project with all standard JHipster
stack. DBMS used is Postgres. We outlined the basic data structure
with jhipster entity generation tool, creating the most important
relations etc. We also defined the basic user roles and permissions
within standard JHipster options. At this phase we didn't pay very
much attention to the details such as complex unique constraints,
business restrictions, user management, JPA errors handling and
presentation etc. Just created a sort of backbone to start with.
CRUD pages are all standart.
We introduced some domain-specific business logic. Basic frontend customization was performed: branding,
styles, some custom views (still used bootstrap classes extensively) etc. Jhipster-generated frame was kept in place but extended. We changed authorization logic a little bit on both backend
and frontend, it's token-based with certain token validation
rules. User-friendly error handling was introduced, allowing user to
understand what business restrictions show up in various conditions. We started to write more complex unit tests to meet the business logic implemented recently. Entities are mostly (~80%) crafted manually at this stage, because we got used to the data structure offered by JHipster, and we had too much customization in CRUD REST controllers, pages and tests covering all that. Liquibase changelogs were generated with liquibase:diff and edited manually. We don't add such entities to .jhipster folder.
Because of demands for interface design growing high and strict, it was decided to introduce separate frontend layer for end-user interaction. It partially shares REST interfaces with jhipster-generated frontend, but is absolutely independent in terms of project structure. We decided to use Angular for new frontend layer as well. In fact, it is a subfolder with separate index.html, bower.json, Gruntfile.js etc. At the same time we continued to improve business logic, refine db structure, increase code coverage, introduce new user roles etc.
...
So we have slightly customized "old" JHipster frontend for administration and data mangement purposes. And an independent "new" frontend with custom design to deal with end users. Please note: it IS possible to keep an original interface, customize it to some limit and preserve the possibility to generate entities, and it worked well in our project as far as it was justified.
Some notes:
Component versions in pom.xml were constantly updated by hand;
Maven dependencies were manually added to pom.xml;
JS dependencies were manually added to index.html/bower.json/app.js;
If you have complex frontend scripting, dealing with JS uglification for production profile may be tricky;
Another difficult thing is to keep liquibase scripts working for both DBMS used by spring-boot and H2 which is used for tests;
You'll probably face some problems with configuration tuning depending on domain logic specific for your project.
I hope it helps.
Another approach that has been introduced in release 2.26.0 (mid december 2015) is to build your own modules, see documentation.
Later on in release 5.0.0 (mid 2018), JHipster has introduced a more powerful tool: blueprints, although it requires more effort than creating a module. With a blueprint, you can even replace the language/framework of the generated project, it has been successfully used for Kotlin, NodeJS and VueJS.
VS2013 update 5, MVC5 using Areas
I have a stand-alone function programmed for a website. The functionality is a specific user interface to collect survey responses in a particular way. It has several controllers, a model and a group of views. The functionality is completely contained in an Area of the project, except for the Shared _Layout file that provides the main menu for consistency.
'Is it possible for me to' / 'how do I' compile this Area into a single or set of .dll file(s) that I could then add conveniently to other websites? I'm assuming creating something for transfer/download is very standard functionality. For example, I used Elmah.MVC for this site. What I want to do is pretty much create a package that can be downloaded in a similar way to how we integrate Elmah.MVC into a site. (Be certain I'm not talking about creating error logging software, I'm only using Elmah.MVC as an example of software that is easily integrated into other website applications.)
I've never compiled any website functionality into a .dll(s) for use elsewhere and would appreciate either some specific guidance, or perhaps what would be easier is to provide a link with a good step by step tutorial or explanation for how to do this. Most of what I've found on the web describes bits and pieces of doing this, but it's not enough for me to feel confident with it.
It seems to me there are a lot of 'moving parts' to taking a particular piece of an MVC application and turning it into something that is easily added to other projects.
A particular issue I don't quite grasp is the difference in downloaded packages between getting code and getting just the .dll(s). For instance, when I download an MVC5 site, I get controllers, models and views, but when I download Elmah I get a .dll and no code files. Also, I do understand the concept of transforms, but I'm just struggling right now with even getting from my programmed application into a 'package' regardless of the transforms that make it easy to integrate into another website.
These are just some of my questions I have about how to perform this particular process in developing deliverable and/or shareable software.
What you are looking to do is create a portable MVC Area project. A Portable Area is a set of reusable multi page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application. An MVC Portable Area is really just a dll that contains the views, controllers, scripts, etc… needed to use in a website that is either a Web Forms website or an MVC website. A developer can use them for a reusable widget or a complete engine. I have actually used them for both. Here is a link with some basic info to get started. http://elegantcode.com/2012/04/06/mvc-portable-areas/
I'm digging into orchard CMS, but I'm a little bit skeptical that I might not have the ability to do something like create new content items quickly without posting back to the server.
For example. Let's say I define a content type for a product. One property a product might have is a collection of variations or similar products that can maybe be sorted by relevance. (Think a comic book with variant covers)
Could you build an interface for this where you enter a new product, and search for and include multiple variant products all from the same client interface without ever having to post back or do a hard page refresh?
I guess maybe, what I'm really asking is if it would be easy to expose the content through Web API or something like that, and from there you can really just build anything.
I'm a little worried about starting down the road of using a nice framework like this, only to find half-way through that I'm limited by the framework itself.
Think about OrchardCMS as a super set of ASP.NET MVC. You can build a custom controller to handle your own types or even content types (see OrchardServices)
In your case, just make a custom controller which will handle via actions the ajaxs requests to create, update, get related items and so on.
You should read the Sipke post series, in particularly this one: (http://skywalkersoftwaredevelopment.net/blog/writing-an-orchard-webshop-module-from-scratch-part-6) Another useful resource is the course of pluralsight.