We have two child classes: Child1,Child2 that inherits from the same a class ParentClass, and only the class ParentClass.
We have a class A that contains a field parentList of type set field. This parentList is a list of ParentClass instances Ids
private Set parentList = new HashSet();
What we really want to achieve, is to select multiple values from either Child1 and Child2, and assign them to the parentList set field in class A, using Loupe.
When we try to execute the loupe command over the parentList field of class A, we get the following error:
Field 'parentList' could not implement Loupe Field.
What are the restrictions on the fields to use Loupe?
Is what we want to achieve, possible?
This UI component is designed to handle relations between JPA Entities of type many-to-one in the many side of relation (field must be annotated with #ManyToOne).
Currently gvNIX doesn't include any component which handle #*ToMany relations the way you required. The most similar is the use of master-detail datatables (see web mvc datatables details add command). An example of this could be: master Vets and details Visits (selecting a Vet related Visits will be shown in details list).
The component you need can be done but you must create it by hand.
Good luck!
Related
I am working and building my website with Django and I am facing this logical issue.
My project is made by several app.
I would like to declare in each one of these a "piece" of a bigger model that will be represented in one single table-
Example:
model Person
model DetailsPerson
As each single app specifies a specific part of the person, my idea was to decentralize the declaration of DetailsPerson model so that they figure in one single table but each app enlarge the fields the app needs to work.
Is this possible?
EDIT 25/11/2021: here is a graphical representation of how I would like my models be working like
I would like to declaire, "to detail" the table Person adding in various app the fields the app itself introduce. In this way I can have a single table with various fields, introduced time by time as I create new apps into my project.
Is this possible? My aim is to keep only one table.
I tried with Nechoj's first solution but declairing Person(models.Model) and then in another app PsysicalModel(Person) adding field_1 and field_2 and then makemigrations and migrate doesn't fill my table with field_1 and field_2 but leaves the table with only id_person, birthdate and city.
Class Inheritance
You can use class inheritance, like
class Person(models.Model):
(fields)
# in other file, import this class an inherit
class PersonWithDetails(Person):
(add. fields)
EDIT: According to the docs on multitable inheritance this will create an additional table for PersonWithDetails that holds the additional fields. However, to the user it appears as if all data is stored in a single table. For example, filterand update queries work as expected:
PersonWithDetails.objects.filter(<some criteria>)
will return instances that contain all fields (both from Person and PersonWithDetails) as if all fields where stored in a single table PersonWithDetails. Furthermore, it is possible to select all persons irrespective of their details:
Person.objects.all()
will return all Person instances, including those that have been created as PersonWithDetails. If you have a Person instance p at hand, then you can check whether a special attribute is present and then know, whether this instance is also a PersonWithDetails:
if p.personwithdetails is not None:
p.personwithdetails.field_1
This example show how to acces fields of the PersinWithDetails if the instance at hand is Person.
OneToOneField
Another option is to use one-to-one relations.
class Person(models.Model):
(fields)
# in other file, import this class and do
class DetailsPerson(models.Model):
person = models.OneToOneField(Person, on_delete=models.CASCADE)
(additional fields)
In case of adding details to a Person class, I would prefer the second option.
ForeignKey
And if you want to have several different Detail classes to one Person, use ForeignKey:
class DetailsPerson1(models.Model):
person = models.ForeignKey(Person, on_delete=models.CASCADE)
(additional fields)
class DetailsPerson2(models.Model):
person = models.ForeignKey(Person, on_delete=models.CASCADE)
(additional fields)
I am trying to create categories and sub-categories pro-grammatically in Shopware 6.
I looked at the entity class of Shopware\Core\Content\Category\CategoryEntity but i'm not sure that whether this class will work or not? I do not want to assign any products.
Does any one know how to create categories in the Shopware 6?
Creating categories is like creating any other entity through their repository. You can get the category repository from $this->container->get('category.repository') and then simply call the ->create method on the repository object.
You will have to pass the data array to it as the first argument and a context as the second argument. What data you need to pass in the array you can check out the CategoryEntity class (which you have correctly identified already).
In a JSF page I have to display the data from an entity.
This entity has some int fields which cannot be displayed directly but need to be translated into a descriptive string.
Between them some can have a limited number of values, others have lots of possible values (such as a wordlwide Country_ID) and deserve a table on the Db with the association (ID, description).
This latter case can easily be solved navigating via relationship from the original entity to the entity corresponding to the dictionary table (ID, description) but I don't want to introduce new entities just to solve translations form ID to description.
Besides another integer field has special needs: the hundred thousand number should be changed with a letter according to a rule such as 100015 -> A00015, 301023 -> C01023.
Initially I put the translation code inside the entity itself but I know the great limits and drawbacks of this solution.
Then I created a singletone (EntityTranslator) with all the methods to translate the different fields. For cases where the field values are a lot I put them inside a table which is loaded from the singletone and transformed in a TreeMap, otherwise the descriptions are in arrays inside the class.
In the ManagedBean I wrote a getter for EntityTranslator and inside the jsf I use quite long el statements like the following:
#{myManagedBean.entityTranslator.translateCountryID(myManagedBean.selectedEntity.countryID)}
I think the problem is quite general and I'm looking for a standard way to solve it but, as already stated, I don't want to create new 'stupid' entities only to associate an ID to a description, I think it is overkill.
Another possibility is the use of converters Object(Integer) <-> String but I'm more comfortable in having all the translation needs for an Entity inside the same class.
Your question boils down to the following simple line:
How can I display a field different from id of my entity in my view and how can I morph an integer field into something more meaningful.
The answer is that it depends on a situation.
If you solely want to input/output data, you don't need id at all apart from the possible view parameter like ?id=12345. In this case you can input/output anything you want in your view: the id is always there.
If you want to create a new entity most possibly you have a way of generating ids via JPA, or database, or elsehow besides the direct input from the user. In this situation you don't need to mess with ids as well.
If you want to use information on other entities like show user a dropdown box with e.g. a list of countries, you always have the option to separate label (let it be name) and value (let it be id), or even have a unique not null column containing the country name in your database table that will serve as a natural identifier. If you'd like to get data from the user using an input text field you always can create a converter that will do the job of transforming user input strings to actual entity objects.
Regarding the transformation of your integers, you've actually got several choices: the first one is to attach a converter for these fields that will roughly do 301023 -> C01023 and C01023 -> 301023 transformations, the second one is to write a custom EL function and the third one is to prepare the right model beforehand / do the transformations on-the-fly.
So I've got a Client entity that needs a relationship to a PhoneNumber entity to allow multiple phone numbers. And I've got an Employee entity that also needs a relationship to a PhoneNumber entity to allow multiple phone numbers. Should I create two separate PhoneNumber entities or can I somehow use the same entity for both?
I would create a parent entity called Person for your Client and Employee entities. The Person entity would have a relationship to the PhoneNumber entity.
Inherited entities have the same attributes and relationships as their parent entity. Of course you can add attributes and relationships to the "child"-entities as well. I omitted that in the screenshot.
Something like this:
you can configure the parent entity in the core data inspector in the right side pane.
I'd like to place some custom methods directly into each NSManagedObject. Think, "calculated fields": these methods provide read-only calculated values based upon persistent values on the Entity - which is identical to this question.
I'm using the Xcode New File... Wizard to create NSManagedObject subclasses for each of my Entities. I'm trying to benefit from the system auto-creating the accessors for me. For example:
Core Data Entity: "Site"
#interface Site : NSManagedObject
As I continue to add new Attributes to my Entities, I'm replacing their corresponding NSManagedObjects by using the Wizard. When each file is replaced, my custom methods are lost.
Should I create my custom methods elsewhere so that I can continue to leverage the Wizard? Or, should I keep the methods on the NSManagedObject and add Accessors for new Attributes manually? Is there another approach?
Create a category on your NSManagedObject subclass:
In the "New File ..." dialog, choose "Objective-C category".
Create a category "CustomMethods" on "Site".
Xcode will create files Site+CustomMethods.h, declaring the #interface Site (CustomMethods), and Site+CustomMethods.m for the corresponding implementation.
Add your custom methods to the category.
These files will not be overwritten when you recreate Site.m and Site.h in Xcode.
All category methods can be used as if they had been declared in the class itself. The only thing you can not do in a category is add new instance variables.
Once I have used the wizard to create the initial managed objects, I generally change them manually.
Another way of doing this is to create subclasses of the wizard generated class files and use these.
When they are regenerated, all of your custom code is in the subclass, as opposed to the overwritten class file.