I have used the plugin template to create a simple test plugin for cloudify 3.1. my plugin.yaml has the following description for a relationship:
relationships:
mytest.relationships.connected_to:
derived_from: cloudify.relationships.connected_to
source_interfaces:
cloudify.interfaces.relationship_lifecycle:
establish:
implementation: python_webserver.plugin.services.publish
inputs:
publish_input:
default: {}
properties:
publish_propety:
default: {}
I have two questions:
How can I read the relationship properties (“publish_propety” for
instance”) inside the publish function (which implement the
establish interface). I did not find any way to access them. The ctx has
references for source and target nodes and instances , but I did
not find anything related to relationship
What is the different between property and input for relationship? And when should we use each of them?
Thanks
You can't get the relationship properties with ctx you could try to get to it with a rest call but it would be messy.
You could however move "publish_propety []" to "publish_input []" and than you can get to it.
The way I see it, properties are what describe your instance, you will probably use them for instance image,zone... Inputs will be more dynamic, you could use them to define things on creation but dynamically or even at runtime.
You could switch between the two,it is a matter of how you define your software model.
Related
When using the MakerBundle in Symfony (4) to create new entity (make:entity EntityName), an id is generated by default with annotation (if annotations enabled) #GeneratedValue.
#GeneratedValue means #GeneratedValue(strategy="AUTO").
According to the Doctrine documentation, the AUTO strategy is supposed to use SERIAL type for the id in PostgreSQL. But, I do not know why in my case, the AUTO strategy use SEQUENCE for the id.
Then, I can force it to use SERIAL by changing by hand into #GeneratedValue(strategy="IDENTITY") which means using SERIAL type in PostgreSQL.
Is there any way to change the default #GeneratedValue annotation created by the MakerBundle for the new entities to be created with the #GeneratedValue(strategy="IDENTITY") annotation ?
What you could possibly do is decorate \Symfony\Bundle\MakerBundle\Doctrine\EntityClassGenerator which is registered as a service named maker.entity_class_generator in vendor/symfony/maker-bundle/src/Resources/config/services.xml and override its generateEntityClass method to make a different call on the Generator's generateClass method, specifically the file path could be changed there.
Seems like the file path there could be relative or absolute, so with some trial and error you could get it to output the annotation you want. The template that the maker bundle uses now is at vendor/symfony/maker-bundle/src/Resources/skeleton/doctrine/Entity.tpl.php, and it's pretty straightforward to modify.
#WebInitParam is an annotation that goes at class level.
It defines initialization parameters for the servlet.
I would like to know, what is the difference between doing this and using static variables, and why do it the #WebInitParam way rather than using statics?
What does defining k/v pairs as #WebInitParams allow you to do that you couldn't do if you declared static variables instead?
I have looked and all I can find is a million people saying how to define #WebInitParams. Well yes that's the easy bit. It's what I can do with that that is really what is of interest.
Thanks very much.
From a "raison d'etre" perspective, the annotation exists as a better design and architecture alternative to just peppering a class with static fields. #WebInitParam is a self-documenting approach to the initialization parameters a servlet or filter class needs, available via web.xml as well. It serves this purpose for the end developers as well as the JavaEE platform as a whole.
Think about it this way: in a vanilla project, you have the option of hardcoding a bunch of parameters in the class as static fields, or defining the same parameters in a property file. Which would you pick? Under what circumstances?
From a purely functional angle, apart from the function of using the annotation to override defaults set in web.xml, one other major reason is that you will sometimes need to get a hold of those initialization parameters from another component in your application. Using the annotation essentially increases the visibility of the parameter. In JSF for example, the API allows you to retrieve FacesServlet initialization parameters with:
//get all the parameters
FacesContext.getCurrentInstance().getExternalContext().getInitParameterMap()
//get a specific parameter
FacesContext.getCurrentInstance().getExternalContext().getInitParameter("aParameter");
In JSF-2.3 , it gets even more convenient with the following CDI-enabled injection:
#InitParameterMap Map<String,String> servletParameterMap;
Bear in mind that because it's CDI, it means this facility is available throughout the JavaEE platform, not just in web applications/JSF.
It's going to be a hassle to retrieve init parameters if the only mechanism available is a static field in the servlet class - you'll need to obtain an instance of the filter or servlet to get the static fields in it.
Separately, one could make the argument that maybe one should favour context-params over servlet-params because then, you get even more flexibility that isn't tied to any given servlet. That's a separate matter entirely :)
I've started a Symfony2 project from scratch where I then installed FOSUserBundle.
Then, I have written (actually, generated with ORM Designer) some entities that need to have relations between them, and with the User entity.
I have Items belonging to Users, Collections belonging to Users that group Items, and so on.
Since I used FOSUserBundle I only have a basic User class (https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/doc/index.md , step 3a) defined using annotations, no config/doctrine folder and no User.yml file in it.
I then created the MyBundle/Resources/config/doctrine folder and added the yml files mentioned above.
When I try to generate the entities with the command-line tool everything works fine: it will create the Entities from my yml files.
However, at this point, trying to load up in browsers the url where the login previously worked (when I only had the FOSUserBundle installed) will throw this error:
MappingException: No mapping file found named
'/var/www/concert/src/X/MyBundle/Resources/config/doctrine/User.orm.yml'
for class 'X\MyBundle\Entity\User'.
Following actions, such as generating the CRUD logic, will not work as long as I have an *.orm.yml file in the config/doctrine folder. If I remove those, CRUD generation will work, but generation of actual mysql tables won't.
Juggling with these gets me to a point where I can also get the tables, but then the actual app doesn't work if I try to use any of the url's where the newly generated CRUD is involved because since the entities are based on yml (which I remove to get things "working") it won't have any mapping knowledge.
Is this inherently wrong? To have yml-based entities in relationship with an User entity based on the FOSUserBundle and still be able to get the nice command-line generation tools?
The problem you describe stems from mixing configuration formats (yaml and I assume annotations). You can easily fix this by ditching the annotations in your models and replacing them with yaml-files like you would do in your own models.
Unfortunately the FOSUserBundle-docs only show you how to use annotations, so here is a quick transformation into yaml format when your X\MyBundle\Entity\User extends FOSUSerBundle's UserEntity:
X\MyBundle\Entity\User:
type: entity
table: fos_user
id:
id:
type: integer
strategy: { generator: "AUTO" }
The remaining stuff is taken care of by FOSUserBundle, as the BaseModel is a mapped-superclass and already describes the stuff in the User.orm.xml, but you could just as well replace the existing values or add additional values just like you would do with your own models.
If you don't use annotations throughout your app, you might also want to disable them in your app/config/config.yml to prevent side effects.
How can I tell Doctrine2 Entity Manager to use an inherited class by default, instead of the generated one?
In my new sf2 app, I generated all entities from the existing database to /src/Package/Bundle/DataBundle/Entity - of course I'd like to have generated forms as well, so I need for my foreign-key relations __toString() methods, which I don't want to put into those generated files because they get overwritten (yes they also get backuped in an extra file, so my changes aren't lost, but manually merging files is not what I want).
So I added new classes to /src/Package/Bundle/DataBundle/Model inheriting all from the entities, but with a __toString() method and surely some other tweaks in the future as well. But now, when I call $entity = $em->getRepository('PackageDataBundle:Customer')->find($id); - I get an instance of /src/Package/Bundle/DataBundle/Entity/Customer instead of /src/Package/Bundle/DataBundle/Model/Customer ..
I'd like to have the behaviour from sf1, where all custom work is done in the inherited classes and the generated ones are the "base" Classes, which can be updated any time on a schema update and aren't touched otherwise..
I hope there is some configuration for this..
Maybe as a bonus, I'd like to have my naming convention turned around: to have Model as the "abstract" generated one and Entity as the actual used one
Thanks.
I'd like to have the behaviour from sf1, where all custom work is done in the inherited classes and the generated ones are the "base" Classes, which can be updated any time on a schema update and aren't touched otherwise..
For purposes you described you should use Propel ORM - it was so in Symfony-1.4, and became even more flexible for Symfony-2.0 with Propel 1.6. It is well documented, easily installed and naturally used within Symfony-2.0
Perhaps I misunderstood your problem, but going from Propel to Doctrine i was also disappointed that there is no way to keep that "dirty" auto-generated code out of my logic.
I do not know how much it is now important to you, but I currently writing a simple bundle that implements such generation style.
$ app/console doctrine:generate:entities СompanySomeBundle --propel-style=true
Generating entities for bundle "СompanySomeBundle"
> backing up User.php to User.php~
> generating Сompany\SomeBundle\Entity\Base\User
> generating Сompany\SomeBundle\Entity\User
https://github.com/madesst/MadesstDoctrineGenerationBundle
PS: Sorry for my english =/
I need to access data from pre-existing tables. I've started working my way through creating a module to display the data etc. However, Orchard is prefixing the table commands with the 'Table_Prefix' and 'Module Name'.
Is there any way I can specify what table to bind the model, so that I can use the existing IRepository
I'm trying to steer clear of modifying the core code, or implement my own IRepository ( which I've got a feeling is what I'm going to have to do.)
Thanks in advance.
You can create custom table naming convention (so that it would fit your current naming) by altering the core code, in three ways:
Record name mapping is created in BuildRecord method of
CompositionStrategy class
(Orchard.Framework/Environment/ShellBuilders/CompositionStrategy), so you can simply modify the code here.
By altering the Apply method of Orchard.Data.Conventions.RecordTableNameConvention class. This is where the record table name mappings (built in point 1.) get pushed to NHibernate.
Create your own implementation of FluentNHibernate.Conventions.IClassConvention (similar to RecordTableNameConvention mentioned above and replace the default one used by AutoMap in Orchard.Data.Providers.AbstractDataServicesProvider's CreatePersistenceModel(...) method with it.
You could also create your own IDataServicesProvider implementation, but that would surely be an overkill if you only need to change the table naming convention.
I was modifying CompositionStrategy and discovered that you have to modify the following
1. SetupService.cs (Modules\Orchard.Setup\Services):
Tables hardcoded in the Setup method are
"Orchard_Framework_DataMigrationRecord" and
"Settings_ShellDescriptorRecord"
2. InfosetController.cs (Modules\Upgrade\Controllers):
Multiple tables were hardcoded in this class which need to be updated.
3. DataMigrationManager.cs (Data\Migration):
Replace the SchemaBuilder parameters to the contructor.