I couldn't find any reference with this functionality. Shall I just implement a helper method in the builder to read fields in StateTransition object and populate the chain configureTransition() call by myself??
Just to confirm not to reinvent the wheels.
UPDATE:
I'm trying to use StateMachineBuilder to configure with some pre-defined states and transitions in a properties file. In Builder, they use this chained call to generate configuration:
builder.configureTransitions().withExternal().source(s1)....
What I have in mind is, everything read from the file is stored in an object, the spring sm library has this StateTransition object. But as far as I know from the API, there is no way to use it directly to configure a state machine. Instead, I can read individual fields in the object and use the chained call above.
Thanks!
If you want to do it like that, what you mentioned is pretty much only option. Hopefully we get a real support for external state machine definition, i.e. tracked in https://github.com/spring-projects/spring-statemachine/issues/78.
My client have asked me to delete a custom entity and its dependencies (which prevents deletion of this entity) programmatically.
I have retrieved the dependencies of the custom entity using RetrieveDependenciesForDeleteRequest. This request is giving me the collection of dependencies, which must be deleted before the deletion of that custom entity.
RetrieveDependenciesForDeleteResponse resp =
(RetrieveDependenciesForDeleteResponse) service.Execute(req);
//A more complete report requires more code
foreach (Entity dependencyEntity in resp.EntityCollection.Entities)
{
service.Delete(d.LogicalName, dependencyEntity.Id);
}
Now the issue I am facing here is that dependencyEntity.Id is always empty GUID, instead of valid GUID.
Can some one help me how to achieve this functionality?
The Entity items in the response merely act as data transport objects. They are not real entities. What you are looking for is the attribute named "dependentcomponentobjectid" (this is a Guid type, not an EntityReference). Attribute "dependentcomponenttype" (OptionSetValue) gives you a clue about the type of the component you are dealing with.
Note that a dependentcomponent can in turn be a required component other components are depending on. (E.g. a workflow depends on a workflow activity, which in turn depends on a plugin assembly.) So, a robust removal tool would need to follow a recursive strategy.
There is one requirement to create a default attribute say 'Test' on creation of an entity like we have Owner field common in every entity in CRM 2011. Can you please help me in this?
The easiest codeless solution is to have a workflow fire on create of your record. The value won't appear straight away but it will always be set.
There is no supported way to allow automatic creation of a new metadata attribute on an entity, that is triggered by the creation of the entity itself (it is not possible to register a plugin against the creation of an entity). My recommendation is that given the (surely) rare incidence of entity creation, remember to add the custom attribute yourself. This will undoubtedly take you less time than trying to hack an automated workaround.
Edit:
I still stand by disuading you to do this in an automated way, however as a trigger point you might consider harnessing the publish or publishall message as a way to fire a custom plug-in (as per my note below).
I have multiple versions of xcdatamodel files:
app1.0.xcdatamodel
app1.1.xcdatamodel
app1.2.xcdatamodel (current)
Does this mean I need multiple combinations of xcmappingmodel files to cover all upgrade scenarios?
app1.0_to_app1.1.xcmappingmodel (had this already)
app1.1_to_app1.2.xcmappingmodel (is it iterative?)
app1.0_to_app1.2.xcmappingmodel (too much?)
Thanks!
Core Data requires that you create a mapping model to go from the current version of the data store to the latest version of the data store. This means that you will need to make one that goes from v1 -> v2 and v2 -> v3 and v1 -> v3.
From Core Data Versioning and Migration Guide
Tries to find a mapping model that maps from the managed object model
for the existing store to that in use by the persistent store
coordinator. Core Data searches through your application’s resources
for available mapping models and tests each in turn. If it cannot find
a suitable mapping, Core Data returns NO and a suitable error.
Note that you must have created a suitable mapping model in order for
this phase to succeed.
As discussed in this Apple Document
Core Data Mapping
You could implement progressive data migration. Look for progressivelyMigrateURL in here http://media.pragprog.com/titles/mzcd/code/ProgressiveMigration/AppDelegate.m
The progressivelyMigrateURL is a great sample, but I don't think you actually need it as versions of your document appear as long as you develop the application so every time you need as many mapping models as the count of supported versions of the data model minus one and not more (for example you don't need the app1.0_to_app1.1.xcmappingmodel as 1.1 version is not the latest version any more). Every time when you create a new version you need just to correct a target model in every mapping model you have and add one more if needed, maybe you will need to generate new ones and remove old ones though. The fact is that migration in one stage (which doesn't force you to create more mapping models compared to the progressive one) is much much faster in runtime as you may notice.
You also don't need to create mapping models for trivial cases and either use a Lightweight Migration (use The Default Migration Process instead if concrete situation needs a mapping model which cannot be generated in runtime (of course you need to have it in your app bundle)) or migrate with a help of the mapping model created in runtime with the help of the inferredMappingModelForSourceModel:destinationModel:error: method of the NSMappingModel class and then customized in code if needed (you will need to trigger migration manually in this case by calling the migrateStoreFromURL:type:options:withMappingModel:toDestinationURL:destinationType:destinationOptions:error: method of NSMigrationManager instance as far as I understand).
Good luck!
I have two classes that each need an instance of each other to function. Ordinarily if an object needs another object to run, I like to pass it in the constructor. But I can't do that in this case, because one object has to be instantiated before the other, and so therefore the second object does not exist to be passed to the first object's constructor.
I can resolve this by passing the first object to the second object's constructor, then calling a setter on the first object to pass the second object to it, but that seems a little clunky, and I'm wondering if there's a better way:
backend = new Backend();
panel = new Panel(backend);
backend.setPanel();
I've never put any study into MVC; I suppose I'm dealing with a model here (the Backend), and a view or a controller (the Panel). Any insights here I can gain from MVC?
It's time to take a look at MVC. :-) When you have a model-view-controller situation, the consensus is that the model shouldn't be aware of the view-controller (MVC often plays out as M-VC), but the view is invariably aware of the model.
If the model needs to tell the view something, it does so by notifying its listeners, of which it may have multiples. Your view should be one of them.
In a circular construction scenario I'd use a factory class/factory method. I would normally make the construction logic private to the factory (using friend construct, package level protection or similar), to en sure that no-one could construct instances without using the factory.
The use of setter/constructor is really a part of the contract between the two classes and the factory, so I'd just use whichever's convenient.
As has been pointed out, you really should try to find a non-circular solution.
First of all, contrary to what others has said here, there's no inherent problem with circular references. For example, an Order object would be expected to have a reference to the Customer object of the person who placed the Order. Similarly, it would be natural for the Customer object to have a list of Orders he has placed.
In a refernce-based language (like Java or C#) there's no problem, at all. In a value-based language (like C++), you have to take care in designing them.
That said, you design of:
backend = new Backend();
panel = new Panel(backend);
backend.setPanel(panel);
It pretty much the only way to do it.
It's better to avoid circular references. I would personally try to rethink my objects.
panel = new Panel(backend);
You do this in this routine something like
Public Sub Panel(ByVal BackEnd as BackEnd)
Me.MyBackEnd = BackEnd
BackEnd.MyPanel = Me
End Sub
You don't need BackEnd.SetPanel
It is better to use Proxies. A proxy links one object to another through raising a Event. The parent hands the child a proxy. When the child needs the parent it calls a GetRef method on the proxy. The proxy then raises a event which the parent uses to return itself to the proxy which then hands it to the child.
The use of the Event/Delegate mechanism avoids any circular reference problems.
So you have (assuming that the backend is the 'parent' here)
Public Sub Panel(ByVal BackEnd as BackEnd)
Me.MyBackEnd = BackEnd.Proxy
BackEnd.MyPanel = Me
End Sub
Public Property MyBackEnd() as BackEnd
Set (ByVal Value as BackEnd)
priBackEndProxy = BackEnd.Proxy
End Set
Get
Return priBackEndProxy.GetRef
End Get
End Property
Here is a fuller discussion on the problem of circular references. Although it is focused on fixing it in Visual Basic 6.0.
Dynamic Memory Allocation
Also another solution is aggregating Panel and BackEnd into another object. This is common if both elements are UI Controls and need to behave in a coordinated manner.
Finally as far as MVC goes I recommend using a a Model View Presenter approach instead.
Basically you have your Form Implement a IPanelForm interface. It registers itself with a class called Panel which does all the UI logic. BackEnd should have events that Panel can hook into for when the model changes. Panel handles the event and updates the form through the IPanelForm interface.
User clicks a button
The form passes to Panel that the user clicked a button
Panel handles the button and retrieves the data from the backend
Panel formats the data.
Panel uses IPanelForm Interface to show the data on the Form.
I've been delaying implementing the lessons learned here, giving me plenty of time to think about the exact right way to do it. As other people said, having a clear separation where the backend objects have listeners for when their properties change is definitely the way to go. Not only will it resolve the specific issue I was asking about in this question, it is going to make a lot of other bad design smells in this code look better. There are actually a lot of different Backend classes (going by the generic class names I used in my example), each with their own corresponding Panel class. And there's even a couple of places where some things can be moved around to separate other pairs of classes into Backend/Panel pairs following the same pattern and reducing a lot of passing junk around as parameters.
The rest of this answer is going to get language specific, as I am using Java.
I've not worried a whole lot about "JavaBeans," but I have found that following basic JavaBean conventions has been very helpful for me in the past: basically, using standard getters and setters for properties. Turns out there's a JavaBean convention I was unaware of which is really going to help here: bound properties. Bound properties are properties available through standard getters and setters which fire PropertyChangeEvents when they change. [I don't know for sure, but the JavaBeans standard may specify that all properties are supposed to be "bound properties." Not relevant to me, at this point. Be aware also that "standard" getters and setters can be very non-standard through the use of BeanInfo classes to define a JavaBean's exact interface, but I never use that, either.] (The main other JavaBean convention that I choose to follow or not as appropriate in each situation is a no-argument constructor; I'm already following it in this project because each of these Backend objects has to be serializable.)
I've found this blog entry, which was very helpful in cluing me into the bound properties/PropertyChangeEvents issue and helping me construct a plan for how I'm going to rework this code.
Right now all of my backend objects inherit from a common class called Model, which provides a couple of things every backend in this system needs including serialization support. I'm going to create an additional class JavaBean as a superclass of Model which will provide the PropertyChangeEvent support that I need, inherited by every Model. I'll update the setters in each Model to fire a PropertyChangeEvent when called. I may also have JavaBean inherited by a couple of classes which aren't technically Models in the same sense as these but which could also benefit from having other classes registered as listeners for them. The JavaBean class may not fully implement the JavaBean spec; as I've said, there are several details I don't care about. But it's good enough for this project. It sounds like I could get all this by inheriting from java.awt.Component, but these aren't components in any sense that I can justify, so I don't want to do that. (I also don't know what overhead it might entail.)
Once every Model is a JavaBean, complete with PropertyChangeEvent support, I'll do a lot of code cleanup: Models that are currently keeping references to Panels will be updated and the Panels will register themselves as listeners. So much cleaner! The Model won't have to know (and shouldn't have known in the first place) what methods the Panel should call on itself when the property updates.