First, thanks for any advice. I am new to all of this and apologize for any obvious blunders.
Second, the question:
In an interface for entering clients that often possess a number of roles, it seemed efficient to create a set of inputs which possessed both visual characteristics and associated data binding based simply on the inputs name.
For example, inquirerfirstname would be any caller or emailer who contacted our company.
The name would dictate a label, placeholder, and the location in firebase where the data would be stored.
The single name could be used--I thought--with a relational table (state machine or series of nested ifs) to define the properties of the input and change its outward appearance and inner bindings through property manipulation.
I created a set of nested iffs, and console logged the property changes in the inputs, but their representation in the host element (a collection of inputs that generated messages to clients as well as messages to sales staff) remained unaffected.
I attempted using the ready callback. I forced the state change with a button.
I was unable to use the var name = new MyInput( name). I believe using this method would be most effective but am unsure how to "stamp" the JavaScript into a heavyweight stamped parent element.
An example of a more complicated and dynamic use of a constructor and a factory implementation that can read database (J-son) objects and respond to generate HTML elements would be awesome.
In vanilla a for each would seem to do the trick but definitions and structure as well as binding would not be organic--read it might be easier just to HTML stamp the inputs in polymer by hand.
I would be really greatful for any help. I have looked for a week and failed to find one example that took data binding, physical appearance, attribute swapping, property binding and object reading into account.
I guess it's a lot, but each piece independently (save the use of the constructor) I think I get.
Thanks again.
Jason
Ps: I am aware that the stamping of the element seems to preclude dynamic property attribute and binding assignments. I was hoping a compute attribute mixed with a factoryimpl would be an option (With a nice example).
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
I have been given this task and would appreciate it if someone helped really. I built a Graphical Model through GMF, which is as follows;
As you see one of the nodes in the model has been selected. The task here is to create an eclipse view with a table, which will be automatically updated upon the selection of a so-called "City Node". As you may guess from the model, the table should contain path costs to all of the cities. I will later expand my solution to include a modified Dijkstra Algorithm but right now i am stuck in the creation of a table view.
I tried to build it using a TableViewer but it seems fairly complex since we need to set the input of the table on ContentProvider, but the twist here is that since we need a SelectionListener to obtain the City Coordinates (as it was ordered to calculate path-costs through the distance between two connected cities divided by the max speed, which was indicated on the connecting streets in the graph) and also the currently selected city, the path-costs need to be automatically calculated and displayed in the table upon the receipt of a click-event. This means that we somehow need to update the input which is gonna be handed to ContentProvider on every selection change.
For further information, I get the current selection through selectionChanged method of ISelectionListener interface and inside this method I put the city information in an arraylist. However although i declared this arraylist outside of the method as public, I cannot seem to access it from the outside of the method and thus can not pass it contentProvider. Eventually the input of the table can not be updated. I tried to write this text as simple as possible and I hope you guys can help me. As I can not foresee now what should be done, I would really appreciate it.
You're on the right track!
In your selection listener's ISelectionListener.selectionChanged method you just have to set the new input for the viewer with TableViewer.setInput. Then, the IStructuredContentProvider.inputChanged method gets invoked on the content provider for the viewer. It's here where you can do your stuff with the new input and refresh the viewer with TableViewer.refresh.
You can also use the JFace databinding framework, but I think you should be fine with what I've mentioned above.
I'm moving from pure DDD paradigm to CQRS. My current concern is with Event Sourcing and, more specifically, organizing Event Store. I've read tons of blogs posts but still can't understand some things. So correct me if I'm wrong.
Each event basically consists of:
- Event date/time
- type of Event (we can figure out type of AggregateRoot from this as well)
- AggregateRoot id (Guid)
- AggregateRoot version (to maintain the order of updates)
- Event data (some serialized class with data necessary to make update)
Now, if my Event data consists of simple value types (ints, strings, enums, etc.) then it's easy. But what if I have to pass another AggregateRoot? I can't serialize the whole AR as a part of Event data (think of all the data and lazy loading), basically I only need to store Id of that AR. But then, when I need to apply that event, I'd need to get that AR from database first. And it doesn't feel right to do so from my Domain Model (calling Repositories and working with AR Ids).
What's the best approach for this?
p.s. For a concrete example, let's assume there's a Model which consists of Task and User entities (both ARs). Task hold a reference to User responsible. But the responsible User can be changed.
Update: I think I've found the source of my confusion. I believe event sourcing should be used only for building read model. And in this case passing Ids and raw data is ok. But the same events used on aggregates themselves. And this I cannot understand.
In DDD an aggregate is a consistency/invariant boundary, so one may never depend on another to maintain its invariants. When we start using this design restriction we find very few situations where is necessary to store a full reference to the other, usually we store its id and (if necessary) version and a copy of the relevant attributes.
For example, using the usual Order/LineItem and Product problem we would copy the Product's id and price in the LineItem, instead of a full reference. This way prevents changes in the Product's price affect the Order/LineItem aggregate's invariants. If is necessary to update the LineItem price after Product price changes we need to keep track of the PriceChanged event from used Products and send a compensating command to the Order/LineItem. Usually this coordination/synchronization is handled by a saga.
In Event Sourcing, the state of the aggregate is defined by Events, and nothing more. All domain model stuff (ala DDD) is there just to decide what domain events should be raised. Event should know nothing about your Domain, it should be simple DTO. In fact, it is perfectly OK to have Event Sourcing without DDD.
As i understand Event Sourcing, it is supposed to help people get rid of relational data models and ORM like NHibernate or Entity Framework, since each of them is a science on its own. Programmers could then simply focus on business logic. I saw here some relational schemas used for event stores, and they were simply ID, Version, Timestamp plus an NClob or NVarchar(max) column to store the event payload schema-less.
My scenario is the following:
I have a workflow (lets call it customActivity1) that do the basic actions for my system. I also have another workflow (customActivity2) that uses customActivity1 and do higher level actions. When I call customActivity1, I must pass on a few parameters, like Boolean or String values. I want to show some of these parameters as a checkbox or combobox (so the developer of customActivity2 can pass on only valid values) and found out that I can do that by setting the argument as PROPERTY (instead of In).
By doing a research, I also found out that you can’t directly use this argument in expressions, so I keep getting errors on my customActivity1.
That said and knowing that I need to narrow what the designer can pass on, how could I do that without using an activity designer or where could I find an answer?
I also attached two pictures, one of what I need and the other of the error I’m getting.
Thanks in advance.
The reason an InArgument only shows you a text field instead of a checkbox is because they are expressions not literal values. There is still type checking though, if you enter the value 1 you get the error message that an integer cannot be converted into a boolean.
You cannot do this. You can only bind to InArguments.
If you bind an InArgument and look at the xaml, you'll see something like this:
<p1:MyActivity MyInArgument="[BoundValue]" ...
The Workflow Runtime knows how to handle these. It doesn't know how to handle binding POCO properties.
If you want to model data flow but want to have a different user experience in the property grid I recommed using arguments (as they convey data flow semantics) and customizing the property grid for those arguments. There is a sample that demonstrates how to do this in the WF4 samples (sample readme available at http://msdn.microsoft.com/en-us/library/ee834515.aspx)
I am trying to build an object to represent a ridiculously large form for a project I am working on. http://www.flickr.com/photos/namtax/5351091239/
I didnt want to build all the fields into one large object as I didnt think this was a good way to do things, so I have structured the model as so -
One contact object.
One work object - linked to the contact one to one.
One travel object - linked to the contact one to one.
One address object - linked to the contact one to many.
One emergency contact object - linked to the contact one to many.
Here is the sample code for one of these relationships - written in CF9 ORM
property name="work"
fieldtype="one-to-one"
cfc="work"
mappedby="contact";
The issue here is that it causes the saveContact function in my controller to be large and code smelly due to all the possible options you can choose in the form. Here is a rough translation of the code
VARIABLES.contact = contactService.getContact(form.iContactId);
contactService.set(contact:contact,argumentCollection:form);
contact = contactService.save(contact);
if(_emergencyContactService.userIsSubmittingAnEmergencyContact(form)){
VARIABLES.emergencyContact = _emergencyContactService.getEmergencyContact(contact);
emergencyContactService.setEmergencyContact(emergencyContact,form);
if(! contact.hasEmergencyContact()){
contact.setEmergencyContact(emergencyContact);
emergencyContact.addarrContacts(contact);
}
_emergencyContactService.save(emergencyContact);
}
// Repeat this logic to check if work object, travel object or address object have been selected in the form also, get and set accordingly.
I then repeat the if statement shown above for emergency contact, to check whether the work object, travel object or address object have been selected in the form also. If so, get and set the object, then link the contact object where necessary.
This doesnt seem efficient to me, especially as I need to repeat all this logic on another controller method as well. Is there a better way to structure my objects, or a better way to handle my controller code?
Thanks.
My initial thoughts are to move any repeating logic from your controller to a service object that you can call from many places.
Bringing that along: you could break up the form into sub-forms - each represented by a 'sub-form' object. Each of these objects should be able to deal with information related to it's part of the form, and it should know what to save to the database. You could compose these form objects into a service object that you call from your controller.
One other thing I noticed is the way you actually pass your entire FORM scope into some functions. I tend to avoid this as you really are not describing what the function needs to do the job, and of course this scope can change when you don't expect it. I would suggest you specify the arguments required by each sub-form object and pass them to the service.
Example psuedocode:
// Controller code
travelSubFrm = new TravelForm(name, dob, address ...); // etc
workSubFrm = new WorkForm(position, dept ...); // etc
// Create service and save details - the service knows the logic
contactFormService.setTravelSubFrm(travelSubFrm);
contactFormService.setWorkSubFrm(workSubFrm);
contactFormService.process();
Just some quick thoughts.
Hope that helps!
EDIT: If you want to start looking into how to architect object-orientated code then I suggest you check out Head First Design Patterns. It's a great introduction to the topic and will help you organise code problem like the one you posted.