JHipster provides some great tools for generating JPA entities and related objects and classes. The site showcases and describes comparisons between a few of these options:
Using a simple questionnaire entity-subgenerator (via jhipster entity) for generating very basic entities
Creating a UML with the JHipster-UML tool, or a similar UML tool
Using a DSL tool called JHipster-JDL with some nice IDE plugins or JDL-Studio
The Entity Sub-Generator (for beginners)
I've found that the entity-subgenerator is lacking for advanced users and is very limited on what it can do. However, it's great for new JHipster or Java/Spring users to understand what an entity is or how JHipster works regarding code generation.
JHipster-UML or JHipster-JDL (for advanced users)
That being the case, I'd only be interested in using JHipster-UML or JHipster-JDL for entity generation. My questions pertain just to those two techniques and when I would use JHipster-UML vs. JHipster-JDL:
What features does one have that the other does not have?
JHipster-JDL seems to have been created specifically for JHipster while JHipster-UML seems to use existing UML DSLs. Should I only use a UML tool only if I have some tool or language-familiarity preference?
These items are not clear on the docs on the website, so I'd love some clarification. Would be happy to update the OS docs to clarify this question for others not coming in with a preference for the two and trying to decide what direction to go with them.
JDL is more powerful than JHipster-UML because it has more features that go beyond class modeling like generating all your microservices applications at once from one file and JHipster 6 will add more features to JDL.
I usually recommend newcomers to start with entity sub generator because you don't have to learn a new language, you create few entities and then you use jhipster export-jdl to export these entities as JDL. From there you can easily switch to JDL only.
Related
I am wondering if anyone knows of any tooling, commercial or open source, that provides facilities to document all the DDD artifacts like domain models, contexts, language and other metadata. Metadata are like owners, teams contact, etc2
My search on Google has not revealed much.
The contextmapper, which can be installed with Visual Code or Eclipse extensions. I use its plantuml generator with plantuml extension.
It is an open source project providing a Domain-specific Language and Tools for Strategic Domain-driven Design (DDD), Context Mapping, Bounded Context Modeling, and Service Decomposition.
I've inherited an aem project which has core, ui.apps, it.tests, and ui.frontend modules. The frontend is nodejs. The core module has java codes, but I don't understand what's using it. Search results for "what core module is used for" returns "Core module contains java codes".
Typically the core module will contain Java-based services - primarily OSGi components with implementation/business logic required by the project. This could be just about anything, from custom servlets intended to directly handle user requests, to scheduled tasks, model POJOs, extensions/plugins for OOTB or third-party frameworks, and many others.
Is this module required? That's hard to answer, since it depends on the project, but generally speaking most non-trivial AEM projects will have some amount of Java implementation.
Most projects nowadays will be using a framework known as HTL (a.k.a. Sightly) which is an HTML-esque template language that can invoke Java/server-side code via special HTML attributes. If you see any Java classes that extend WCMUsePojo, these will be providing domain logic for some front-end component(s).
If you see classes annotated with #Component/#Service (there are other annotations but these two are the most common) then those will be providing some kind of back-end functionality. You'd need to look at them case-by-case as they could be doing just about anything.
It really is a broad topic, and you'd be wise to read up on AEM development in general if you've inherited a project. Hopefully you also inherited a copy of AEM you can spin-up locally to familiarise yourself with the platform and your project.
I'd like to get some business apps up and running quickly with the use of JHipster, which seems like a solid approach; assuming it is allowed. Is the commercial use of a generated JHipster application allowed and if so, what are the proper steps to take in in order to not infringe upon any terms and conditions of open source?
I apologize if this has been asked previously.
I really just need to know how I can go about using an instance of a generated application for something other than an open-source project.
Sincerely,
Art
There are many closed source applications originally generated by JHipster. The generated project is fully yours.
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.
Long time lurker, first time questioner here :)
I have been looking into our company's next software system architecture. We have been using CSLA.net, to some extent, as our business object framework and are thinking of building our new architecture around it. CSLA.net has support for the platforms mentioned in the title and we are looking for mvvm framework that would work well with it.
At the moment we only support windows environments but are also looking to support at least Android and iOS (also mono in general is under consideration). We are looking to share as much of the code as possible between the platforms and MvvmCross seems like really nice piece of mvvm (+) framework, especially in that context. I have watched few n+1 videos and what I have seen so far has been very impressive. I also like the Stuart's style of introducing the framework and concepts around it.
Has anyone tried to build a cross platform application that uses both of these frameworks (CSLA.net and MvvmCross)? If yes, what have been your experiences like? Also if Stuart could comment on the issue of how to merg the viewmodels of the two frameworks. I remember Rocky (Rockford Lhotka) recommending, as a general tip when working with mvvm frameworks, to inherit CSLA.net viewmodelbase(not viewmodel) and implement also mvvm framework's requirements into that class. You can find source of the viewmodelbase from https://github.com/MarimerLLC/csla/blob/master/Source/Csla.Xaml/ViewModelBase.cs.
Any input would be much appreciated.
Regards,
Harri
ps. I think, that this would make a great n+ video. Wouldn't it ;)
I've personally never used CSLA, but I have talked with it's original author, Rocky, both by email and in person.
CSLA presents itself as a business model object layer and that it can very successfully interoperate with independent Mvvm frameworks - see Rocky's post on CSLA+Mvvm
MvvmCross provides the more application and UI level support - and leaves application authors free to choose how they write their business services and models.
Because of this, yes I think it should be possible and even straight-forward to use both of the frameworks together if you want to. To get started, it might be useful to write some prototypes - and perhaps to look at the way other integration has been done - e.g. CSLA+Caliburn integration
ps. I think, that this would make a great n+ video.
I'd much rather see this type of article from someone who understands and uses CSLA. I would encourage all members of the MvvmCross community to contribute their own blog posts, articles, videos and github samples.
One caveat to this advice: I don't know if CSLA support Portable Class Libraries - if it doesn't then you'll probably need to use file-linking rather than PCLs in your app
Yes, you can use a multitude of MVVM frameworks; I've used CaliburnMicro and our own custom MVVM with success. If you haven't checked out Rocky's eBook series, you should definitely do so. One of the big gotchas is the limitations on reflection in Silverlight, hence also in WP8 and WinRT, so some reading up on that is well-advised.
Regarding Portable Class Libraries, you can't those for CSLA business objects (they require more stuff than is available in PCLs), so you do have to do the project linking. Typically, write the complete class in the .NET libary w/ pre-compiler directives, such as
#if !SILVERLIGHT
around code that can't be complied for Silverlight/WP8. I do use PCLs for some basic stuff, like enums and constants, but not for the business classes.
Xamarin have just released some updates that mean the latest framework 4.5 with async features can shortly be implemented...