It's easier to generate tables and default classes with liferay's service builder.
But it is bit difficult for me to understand the hierarchy of classes generated by it.
Also the exact use of each class other than modifying LocalServiceImpl class as per our need by adding our own functionality.
I have gone through Service Builder doc. So I got some basic knowledge but would like to get more on this.
Even the link "Liferay Service Builder" was useful but outdated with current Liferay version. So Does anyone have update on above link or nice info explaining hierarchy with example/diagram?.
Any help is appreciated.
Thanks.
To implement the foreign key concept in liferay, you have to apply your own coding logic since the implementation of FK are not available in service builder. So I guess you need to put some code.
Read some forums related to service builder on liferay website. It will give you better exposure.
Read Liferay In Action. It is a good book
Here is What I obeserved In Liferay 6.1.
com.liferay.portlet.p_name.model:
This has interfaces and classes related to (table entity related to) this portlet.
For example com.liferay.portlet.announcements.model will have
Interfaces:
AnnouncementsEntry
AnnouncementsEntryModel
AnnouncementsDelivery
AnnouncementsDeliveryModel
AnnouncementsFlag
AnnouncementsFlagModel
Classes:
And In classes section, You will find wrapper classes and soap classes for each entity like:
AnnouncementEntryWrapper
AnnouncementEntrySoap
AnnouncementFlagWrapper
AnnouncementFlagSoap
AnnouncementDeliveryWrapper
AnnouncementDeliverySoap
Also for few Entity, you will find Classes for Constant entries like
AnnouncementsEntryConstants, AnnouncementsFlagConstants etc.
com.liferay.portlet.p_name.service:
This has classes and interfaces related to (table entity related to) this portlet.
For example com.liferay.portlet.announcements.service will have
Interfaces:
AnnouncementsEntryService
AnnouncementsEntryLocalService
AnnouncementsDeliveryService
AnnouncementsDeliveryLocalService
AnnouncementsFlagService
AnnouncementsFlagLocalService
Classes:
And In classes section you will have Util and Wrapper classes.
AnnouncementsEntryServiceUtil
AnnouncementsEntryServiceWrapper
AnnouncementsEntryLocalServiceUtil
AnnouncementsEntryLocalServiceWrapper
and so on.....
So In short following is the structure I observed in Liferay
[In Model, I:+Model,(ModelName), C:Soap, Wrapper and Constants]
[In Service, I:Service,LocalService ; C:ServiceUtil,ServiceWrapper,LocalServiceUtil and LocalServiceWrapper]
[In Persistence, I:Finder(BlogsEntryFinder),Persistence(BlogsEntryPersistence); C:Util(BlogsEntryUtil, BlogsEntryFinderUtil)]
Note:
I --> Interface
C --> Class
Related
I've just started using Jhipster for a simple project with a very simple datamodel (so far).
I have a question regarding the generated code for the one-to-many relationship:
Is it possible to generate with List instead of a Set, so I can have my child-items ordered?
If no, what is the best solution to solve my problem? I see 2 ways:
Change the generated code manually to use a List and then use liquibase (mvn liquibase:diff) to update my database ?
Have an attribute on the child-item to handle the order ?
What is the best way to handle the "problem" ?
Best regards
Martin Elkkjær
You can use the Spring #OrderBy annotation to sort your sets by the child entity. See http://www.objectdb.com/api/java/jpa/OrderBy
#Entity
public class Person {
...
#OrderBy("zipcode.zip, zipcode.plusFour")
public Set<Address> getResidences() {...};
...
}
I'd also recommend the following blog that explains how Sets/Lists differ for Hibernate and JPA: https://vladmihalcea.com/hibernate-facts-favoring-sets-vs-bags/ (where I found the answer originally)
I am creating a blog like application using jHipster and want to support i18n in 2 languages (English and Chinese). The jHipster page on this (https://jhipster.github.io/installing-new-languages/) explains i18n on UI elements only.
But how to provide i18n support for values of entities? In this case I want Articles entity of blog to be in two languages.
One of the workaround would be to get the values in both languages from the user into separate entity fields and display accordingly. Is it a right approach?
JHipster does not provide any helper for content localization. This must be done at JPA/Hibernate level.
You can have a field per language or an entity per language where Article would have a one-to-many relationship with LocalizedArticle that would contain all localized fields using a Map<String, LocalizedArticle> using locale as map key.
There are other options which are presented in this good article.
I am coding an MVC internet application, and I have a question in regards to using the ViewBag.
In many of my controllers, I have SelectList objects, where the user can select an object. The object that is selected is a foreign key value for my model.
My question is this: Should I use ViewBag for this? How secure is the ViewBag? Should I use values in my ViewModel instead of the ViewBag?
Thanks in advance.
Use your view model.
When the ViewBag was implemented (MVC 3) dynamic typing was new (.NET 4.0) and it was put in just as a side-option to ViewData or to quickly generate a view without the need for additional classes.
Any serious MVC project will take advantage of a model/viewmodel with a strongly typed view.
There are no security concerns with either because both essentially only exist through the controllers lifespan.
There are no security concerns with ViewBag since it is disposed once rendered in the View.
I think the answer really should be "it depends". For example, if you have 6 collections required to populate dropdown lists aand you want to get the data posted back, you should definitely use a ViewModel for this. Since 6 collections will be hard to manage if they are stuffed in ViewBag with no strong typing in the view, especially if another developer comes along later needing to do maintenance to the view.
Generically everything should be done inside a view model. That's what a view model is. A class that you specifically define to meet the requirements of your view. Here is an image depecting when to Use TempData, ViewBag or ViewData
Nutshell: The Entity Framework Provider for WCF Data Services pulls the schema namespace and EntityContainer name directly from the namespace and class name of the DbContext, respectively. This is also true for DbContexts that are developed using the code-first method.
Is there a way to modify this provider behavior a posteriori--that is, without modifying the class name or the EDM(X)?
Background/caveats/opinion: This is a handy behavior for prototyping, but in a production scenario, the class name is itself an implementation detail that should be hidden from service consumers.
Further, in my case the name cannot be changed, since I am using a framework that provides a very generic DbContext that I am then composing/extending.
Note that I am not discussing a way to create more "space" between the CLR and EDM representations of the data model. Rather, I'm looking for a way to modify the behavior of the DataService<T> extension itself, so that the internal CLR namespace and DbContext extension class name (preserved in the EDM, which is totally okay) aren't exposed externally.
The specific customization points in the service metadata (custom-ns and custom-container below):
<edmx:Edmx Version="1.0" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx">
<edmx:DataServices m:DataServiceVersion="1.0" m:MaxDataServiceVersion="3.0" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<Schema Namespace="<custom-ns>" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
<EntityType Name="EgEntity">
.
.
.
</EntityType>
.
.
.
<EntityContainer Name="<custom-container>" m:IsDefaultEntityContainer="true">
<EntitySet Name="EgEntity" EntityType="<custom-ns>.EgEntity" />
.
.
.
</EntityContainer>
</Schema>
</edmx:DataServices>
</edmx:Edmx>
In code-first, you can specify the schema for tables in the SSDL with the Table annotation (look at the Schema property). Unfortunately, I don't think you can overwrite the schema namespaces used in the CSDL with either attributes or the model builder (please note that I haven't extensively researched this).
You may attempt to play with namespace aliases, although I'm not sure this would work as you intend.
In model-first and database-first, see this question which seems to answer yours. Let me know if it doesn't.
I realize this answer is not too helpful, but I would like to suggest that you specify proper namespaces for your codebase, even (especially) for production. This is because I can't immediately see why a namespace should be "hidden" in any normal scenario, but please do expand on your use-case if you disagree.
That being said, I agree that one should be able to map proper CLR namespaces to different EDM schemas for other reasons, I guess everybody is OK with using the same names as long as they make sense. By the way, don't forget vendor prefixes, especially since you're exposing these names to the network.
Note that the third-party framework namespace shouldn't be relevant as long as the context class is not sealed. Usually, entities are defined as POCOs so that's normally not a problem either. Thus, the standard solution would be to extend this generic context class in a namespace of your own, along with the entities.
I have a Project that use EF 5.0, is data base first. I would like to pregenerate the views, so I try to use this temaplate:
Template
However, how I have one library that has the edmx and the reposutory and I have another assembly with my POCO entities, so the library that implements my repository has a reference to the assembly that has the POCO entities. But this is a problema, and I read a solution by Scott Stafford:
solution
In this solution he says:
"To work around this, I made up a new entity and put it in the context's assembly, and listed it as the first DbSet. Now it picks it up, and works well (except that this is ridiculous)."
However, I don't know where to create a new entity. This new entity must by in my library the has the edmx or in the assembly that has the POCO entities? Is it not needed to modify the template .tt?
Thanks.