By default, when dragging existing components into different PowerDesigner models (e.g. deployment), the component instance is named as ComponentInstance_X where X is an incremental counter. How can I change this naming style to something different such as ComponentType::X?
I use version 15.1 of PowerDesigner.
It's not a complete answer (and I've just verified part of it with 15.2 but...)
You could create/attach an extension to your model, with an event handler "Initialize" on the ComponentInstance metaclass.
This event handler would allow you to modify the name/code of the instance as it is created...
Related
Learning Angular 2 and trying to understand when I should use a component input/output and when I should better update a service property (possibly attached with an EventEmitter if updates are needed).
I have a list of, say, tasks, and each list items shows various info and options for this list item. This list works in the way that only one list item is active, and the active one is on the top of the list. One of those options for each list item is to activate it (if it is not already active), but other components could also possibly change which is the active item.
I have a parent task component, list component and a list-item component (and some other related components), and in addition I have a task-service.
The main taskcomponent could use listcomponent (and something-realted component, many of the components used needs to know and possibly change the activeItemId), like this:
<list [(active-item-id)]=“activeItemId”></list>
<something-related [(active-item-id)]=“activeItemId”></something-related>
The listcomponent could use list-item this way (active is a pipe and also a property on item):
<list-item *ngFor=“#item of items | active”
(item)=“item”
[(active-item-id)]=“activeItemId”>
</list-item>
But since I have a task-service that contains various task related, I could on the service use the already existing activeItemId-property (that has an eventemitter), and all the various task-components could just get info (and be updated) via this property, instead of “sending” the property back and forth via various components via inputs/outputs.
When would it be appropriate to just use a service for something like this and when would it be appropriate to use input/outputs for components instead?
Got a great answer via Angular Google Groups:
Without reading your full explanation, I'd say use binding if
possible, otherwise use a shared service.
Binding is not possible when
- the two components aren't direct parent/children
- the component is added by the router
- the component is added by DynamicComponentLoader
If you share the data between several components at once it might be
easier to not use binding even when one or some of them are direct
children.
Thank you, Günter!
Does anybody knows why BlockData class doesn't directly implement IContent?
I know that during BlockData is being retrieve from database, proxy created by Castle implements IContent.
If StackOverflow isn't suitable place for this kind of a question, please move it.
Johan Björnfot at EPiServer explains some of the details in this post.
Excerpt:
"In previous versions of CMS was pages (PageData) the only content type that the content repository (traditionally DataFactory) handled. In CMS7 this has changed so now content repository (IContentRepository) handles IContent instances. This means that the requirement for a .NET type to be possible to save/load from content repository is that it implements the interface EPiServer.Core.IContent.
There are some implementations of IContent built into CMS like PageData and ContentFolder (used to group shared block instances) and it is also possible to register custom IContent implementations.If you look at BlockData though you will notice that it doesn’t implement IContent, how is then shared block instances handled?
The answer is that during runtime when a shared block instance is created (e.g. through a call to IContentRepository.GetDefault where T is a type inheriting from BlockData) the CMS will create a new .NET type inheriting T using a technic called mixin where the new generated subclass will implement some extra interfaces (including IContent)."
BlockData does implement IContent as it is intended to work both when added to another content item such as a PageData instance (a.k.a. Local Block), and as a standalone instance (a.k.a.Shared Block). In latter case the interface is added by using a mix-in though Castle Windsor so that it can be referenced.
The decision for this construct was based on wanting to be able to use the same rendering templates regardless if a block is local or shared. Therefor the choice stood between having a large number of empty properties on local blocks or the current solution using mixins. Both options were tested and mixins was selected as the preferred solution even though it's not a perfect one.
BlockData "does implement IContent", just do:
var myContent = (IContent)myBlock;
But, if you're by any chance handling a Block which itself is a property (not a ContentReference), that cast will throw an exception.
This will be true for 100% of all cases (... using Math.Round).
We are porting a D6 application to XE3.
In D6 I inherited a complex code which used shared datasets and datasources everywhere.
This worked well in D6.
After we could run the XE3 version, we experienced that lookup combo boxes changed.
On dropdown they reset the other dropdown's keyvalues (everywhere in the program)!
If two dropdowns use on dataset, and if I click on the first to down it, and select, on down the second keyvalue changed to NULL; and reverse - if I click on the second, the first's keyvalue change to NULL...
This is global in this program, so I need to find fast solution.
May somebody have any information about this "bug" (or "feature"? :-) ), or have a solution in his/her hand?
Thanks for any answer!
This is intentional. Take a look at the implemention of TCustomDBLookupComboBox.ListLinkDataChanged; in Vcl.DBCtrls. You will find the comment:
{ Fix for Defect# 204311, Non-bound control should clear when list datasource changes }
Solution: put your datasets on a data module. Instantiate that for every form, so every form works with a separate instance of the dataset. Make sure you set the name of the data module to an empty string after instantiation, or the Delphi streaming system will still use the first correctly named instance when hooking up the form's datasources with the datasets.
When the data module(s) are in the form's uses clause (interface or implementation doesn't matter) the IDE will still offer you their components through the Object Inspector.
You will want to put the database connection on a different data module that you only instantiate once (possibly automatically).
not sure that that is a good title ...
I can get code behind a button to:
TabBar.activeTab.setTitle("New Tab");
but I need to do something like:
TabBar.activeTab.items = { title: "New Tab"
};
so I can eventually automate several tab properties in a loop:
TabBar.activeTab.items = { [key]: [value]
};
Am I correct in thinking config and items can only be used on construct()? Is there a way of doing the above? tia.
It depends on the implementation of the component and config property in question whether it can simply be set or requires a method call to be applied.
You are correct that in ExtJs many config properties are interpreted at construction time. Some are interpreted at render time. Once an Ext.Component is rendered almost all properties require an explicit method call to be applied correctly.
In general, I recommend to always use a method call to change a property after construction time if available in order to not break the inner workings of the component. If you look at the implementation of Ext.panel.Panel#setTitle you can see that there is a lot of stuff going on under the hood, e.g. event firing, etc.
ExtJs 4 configuration
Ext 4 introduced an explicit 'config' mechanism that might serve your purpose. However, my understanding is that most ExtJs components are not (yet?) using it.
Check out '2. Configuration' in the ExtJs Class System Guide
Create objects from xtype/config literals
If you want to add new components to a container (e.g. tabs to a tab panel) it would be rather easy to accomplish.
Use Ext.ComponentManager#create (see [docs][2]) to create an actual component object/instance from your config literal.
Ext.container.Container#add actually calls this method internally, so you can simply pass config objects to the add method.
If you want to remove or add tabs to a panel, there is now way around calling the proper methods.
applyConfig()
Of course you could always implement your own applyConfig method that supports changing certain component configuration properties at runtime by 'translating' the config into the proper method calls.
In my example I have a parent model (ModelParent) with two collections (A and B), which hold ModelA's and ModelB's respectively. There are associated views for each model (ViewParent, ViewA, and ViewB)
I would like a function in ViewA to add a new item to CollectionB.
What's the best way to do this? (couple of possibilities below):
Should ViewA be passed a reference to ViewParent, when it is created? How best to do this? (as far as I know there is now in build parent reference)
Should ViewParent be stored in the window scope, so that ViewA can refrence it like window.ViewA? (This seems wrong to me)
Another alternative than listening directly to events from your collection, is the use of an eventBus. Derick Bailey from Los techies wrote a nice article where he introduces the idea of communication between different components (in his case views) via an eventBus.
If you are firm with coffeescript - and possibly even if you're not - you should also check this nice extension from Adam Thurlow.
Side note: If your situation simply requires communication between the two elements an eventBus is most likely overkill, although the idea is imho ultra simple. Apart from that, I am of the believe, that a central component for communication is worth the effort as it simplifies messaging, supports decoupling and gives your architecture a reliable consistency.
I would consider thinking about it a different way. I believe it would be cleaner if you didn't have to pass references all around your views. Instead, use backbone's built in event model and keep the "add new item to CollectionB" logic inside ViewParent. When ViewParent instantiates ViewA, you could immediately bind to an event on it:
this.viewA = new ViewA({});
this.viewA.bind("some_event_that_requires_adding_to_collection", this.onViewAEvent);
Inside ViewA, whenever you want to add to CollectionB, just trigger the event:
this.trigger("some_event_that_requires_adding_to_collection", itemIWantToAdd);
Add additional arguments to the trigger call to pass them to any callback bound to the event.