Question
Is it possible to change nodes highness and width in Cloudify Composer ?
Context
I am currently trying to describe a (future) application, in TOSCA, using Cloudify.
This model is used in a designing process, therefore I have different environments (dev, qual, prod …) which have nested into them physical clusters of machines, which hosts different software components and so on.
The problem is the display in the Cloudify – Composer, as of now I am not able to change the nodes layout and therefore nested components are side to side. Due to hugh amount of components is it not easily readable.
I have tried to tweak the info.yaml in the Resources tab, but it does not seem to bring change.
Hence my need to custom those boxes and the components layout (Windows Visio’s style).
Ad-hoc
If there is no solution currently implemented, how is it possible to check if such feature is going to develop (or not) ?
Many thanks,
L.
It seems that Composer does have an info.yaml file, that you can edit in the "Resources" tab, and change the width and height parameters there.
However, actually doing that, did nothing when I tried it :/
The Composer is a closed-source component, and hasn't seen a ton of development in the recent months, so it's possible that this feature won't be added. However, I'll let the UI team know of this, thanks!
Related
I have an use case in which I need to have multiple modules loaded in the view at the same time. Thing is, each of those modules might be as simple as a component, or a complex Angular module with a router and everything. I guess you could call it a plugable framework.
The number of modules I have to show or who they are is dynamic (I'm getting them from a server).
My first idea is that it would be good for this case if the feature module's router wouldn't be a singleton with the main one and also if they wouldn't update the url completly.
Each of the feature module should be able to be launched as a stand-alone app if bootstrapped (therefore, I do need it to be able incorporate all Angular 4 features including the router).
I managed to get something working by playing with the router and with named router outlets (secondary routes) but not sure how good that is in the long run.
How should I approach this?
I am in the early stages of attacking a somewhat similar scenario. In my app, the UI is organized in panels that are designed to stand alone on smaller displays, or side by side on larger. I find this approach works well for my routes, as my app is designed to edit a complex, highly hiegraphical document with many inter-related sections. e.g. User follows link on list to open detail, new detail panel appears to right... follows link on detail to related node... etc.
The solution I'm noodling with now is attempting to use an ngrx store that interacts with the router (and router-store) to dynamically create panels based upon router data. Well, technically it does not create the panels, it only serves the data that tells a component what to create and render.
I know my situ is not exactly the same as yours, but perhaps there's something in my approach that may help you find usefull or at least thought provoking.
Alfresco offers both dynamic and static deployment of custom content model [1]. However, it is still not very clear to me why would one renounce to the dynamic deploy advantages.
When should one go with bootstrap deployment? What are functional differences between the two?
[1] http://docs.alfresco.com/5.0/concepts/content-model-deploy.html
Both approaches have it's pros and cons.
In case of dynamic deployment your model is stranded away from all
other customization related code. So, whenever you deploy all your
customization on particular instance you will not be able to include
them in your amp file.
In case of bootstrap deployment if you have any syntactical error in
model you will get to know during bootstrap with information on
possible cause of issue. So, it's easier to rectify.
Dynamic deployment seems to be better suited for your development environment if you want to quickly implement your model and check changes.
As stated in the Alfresco documentation:
There are restrictions on what changes you can make to a content model XML file and when you can delete a content model XML file. Only incremental additions are allowed; i.e., changes that do not require modifications to existing data in the content repository, or do not modify existing definitions and their properties. You can delete the content model only if it is not used by any data in the content repository.
I do not think that dynamic deployment is a good option during development because you will likely need to modify your content model often with changes that are not incremental (such as removing a property). There are steps that you can follow to remove a property from a model dynamically loaded, but they will be much slower and error prone than a restart.
Dynamic deployment is good only in some particular use cases (for example if you need to add a new content type on the fly).
To test that a content model is well formed, you do not need to deploy it. Instead, use the "TestModel" class as described in
https://forums.alfresco.com/forum/developer-discussions/development-environment/orgalfrescorepodictionarytestmodel-11172011-2133
and in many other forum posts
I'm having an issue with the "browse for items" overlay for the default widget for z3c.relationfield, which I believe is using plone.formwidget.contenttree. I've created a custom field using this but get the same problem using the IRelatedItems behavior - the overlay has no browsable content. I am still able to use the autocomplete component of this widget, and can set relations programmatically with no problem, so I don't believe there is a problem with the intids utility. I've also tested on my local machine and on a dev server and everything works perfectly, just not in production (of course).
I apologize for the vague nature of this question, but I'm stumped. Are there any common pitfalls I could look for here? Any configuration step I might be overlooking?
Take a look at the Dexterity documentation and note the following:
Relation support no longer included by default
Content tree and Autocomplete widgets no longer included by default
So maybe you need to install the widget packages manually.
I currently have 6 different flex applications (widgets) that run on a main page.
They all depend on one common library project.
I am currently cleaning up the codebase quite dramatically and it is hard to keep overview this way especially since I inherited the codebase.
Does anyone know a tool that can automatically inform me of any dead code?
Cheers
There are a few tools out there. I'd start with this one from Adobe; which I believe is written as an eclipse plugin.
FlexPMD is another tool; also from Adobe.
FlexCover is another.
Keep in mind that the Flex Compiler will automatically remove unused classes from your final SWF; so removing these classes from your project will probably not affect the final SWF size. I can see it helping with long-term maintenance, though..
Has anyone had any luck testing a Flex app without static Automation IDs attached to components? All of the elements in the apps are generated .....
We've investigated FlexMonkey but it appears to be incompatible with any app that utilizes the ExternalInterface. RIATest's scripting language leaves much to be desired...
Thanks-
Jonathan
Unfortunately I don't know much about this kind of stuff, but I went to a talk that presented these tools for TDD:
- Hudson
- Flex Unit 4
I guess there are tutorials online, don't know if it helps with ExternalInterface testing.
Is there anything that prevents you from generating appropriate automationNames for your generated components? This way you should be able to refer to them properly in automation tools.
Are there any other non-changing properties that your generated components have, like maybe 'id'? If so you can use these properties to address the components. This is definitely possible in RIATest.
FunFX is a Flex automation tool that allows you to access components via ID, "automation name", "automation value" or index. While using something like the component index might be less than ideal for robust tests, if that's all that's stable, it might be worth a try. And it's written in Ruby, so that should satisfy any "real programming language" related requirements. :)
We added an "automationPrefix" property to many of our custom controls (particularly those that are reused many times on a single screen), and wrote code to append the beginning of the automationName property on any child controls. Setting the automationName was the most important parting of enabling automation testing on our Flex apps. There are several ways you could modify the automationName to be unique without making it completely static at the level that most test automation packages need it. We are currently using QTP as the test automation tool of choice.