I've got a bunch of components of different types, that are created on the fly. When it's time, I would like to parse some state properties of each component and send them to server in JSON format.
for example, each box component has state properties: x, y, width and height. JSON for all the boxes would look like this:
{
projectName:"SOMENAME",
projectDate:"SOMEDATE",
boxes:[
{x:1,y:12,width:123, height:321},
{x:19,y:12,width:773, height:21},
{x:876,y:122,width:3, height:31}
]
}
The order matters. After the box component is created, it is also manipulated, and changes need to be updated in the JSON model.
The way I would do this is to give each component a unique identifier and create a separate data class called Data. This class would have a field projectName, projectDate and array boxes that also stores unique identifier. I would than call JSON.stringify() on the whole object of type Data and send that to server.
Is this the way to go? Does angular have some preferred of solving this issue I described? What method do you recommend?
HTML
<app-box-component *ngFor="let box of boxes"> </app-box-component>
BoxComponent.ts
export class BoxComponent implements onInit{
//state properties that need to be send to server. Collected from every box component.
x:number;
y:number;
width:number;
height:number;
}
The recommended way of dealing with state in Angular app is ngrx store.
In your case when user interacts with a box it can send a message like BoxUpdated and inside ngrx effects you would propagate this change to the server. Your ngrx store could contain all initial box data.
Related
I have one doubt regarding the components communication using services.
Now I have one parent component, where I am rendering the list array of objects in parent component using NgFor. Whenever I click any particular item, a function gets triggered and specific object is passed in that function.
Then I am using subject and Observables to load that particular data in a child component. Everything looks fine, but here am trying to access that particular item before the triggering of the function, so in console.log am getting the errors like Cannot read property 'movie_id' of undefined)
add an *ngIf to child component regarding the particular data.. that way Angular doesn't try to access the 'movie_id' container object before it exists..
for example, if you have myObj = { ..., movie_id: 'tarzan' } add a *ngIf="myObj"
I have 2 different types components. They both only use and contain an HTML5-canvas element, but need to show different types of data on a chart:
Component A (Only ever 1 of these)
Component B (0 to 4 of these)
Both components need the dateTime of the first data-entry from the two data-sets, but the dateTime of the last entry comes from their own respective data-sets.
Component A needs its first entry date from Component B.
Currently I do it like this:
Component B has the method that finds the date-limits from its own dataset. Using an Observer-pattern & Subjects, I broadcasts the returned dates through a service and into Component A.
The problem with this though, is that coupling suddenly becomes pretty tight. I can't initialize component A first, because it needs B to do its calculation first. Both components ideally should initialize and show/share their data simultaneously, and continue to do so. (E.g. If a user scrolls in one chart it should scroll all other components too, and so on.)
This is why I wanted an extra layer added on top of these components. A controller if you will.
I can't figure out what's best though:
A shared service that can take external data as input?
A container component? (Transclusion)
Another component, Component C, that A & B are children of?
As I'm still new to Angular 2, it's hard to tell which approach is best for future maintenance/development?
I'm being drawn towards creating another normal component as a parent, and have this component send and receive data to/from its children (A & B) as necessary.
I'm also uncertain as to what's "best practice" and if you can just use a component like an empty 'logic shell'. I've tried reading here and there, and I've found a lot, but I can't seem to get an exact answer to my question. It'll take time before I can comprehend all this knowledge and answer it myself, so I'm hoping someone could give me a helping nudge, thanks.
PS: I should add that my angular application will be a child-component in larger application, and will get its data from some other parent comp.
Why don't you put your logic into services?
You can also set up service hierarchies by injecting sub-services into a parent service.
If your logic is not UI / interaction related, you should put it into reusable services. If your logic is UI related, you could set up a parent component acting as a mediator between A and B (acting on their respective input/output parameters)
Whatever you do, it is a good idea to keep concerns separate.
Both A and B should not need to care about other components needing their output. Angular has Input/Output parameters for that.
Don't put some generic datetime calculation stuff into components. Make it reusable through services.
Keep coupling loose by introducing interfaces and injections.
Update:
Services should only use injectable constructor parameters, so you should pass your input using methods (or setters, but that is less expressive).
To pass arbitrary JSON objects, you could utilize any parameters. However if your json follows a certain structure, you could define an interface.
public doStuff(input: any): any { }
or
interface IMyDataContract {
dateField: string;
}
public doStuff(input: IMyDataContract): any { }
In Flex, I want to create some variable that would hold a dictionary of ui components used throughout my application. Ideally, there would be a function in Application component that would return component for id:
public function getComponent4Id(id:String):UIComponent {}
Then I would access component using the following line:
var myComponent:UIComponent = FlexGlobals.topLevelApplication.getComponent4Id("someId");
Now, the only problem is: I want the component returned to be read-only.
It is very convenient to read some properties of myComponent from every corner of application, but I don't want my developers to abuse it and change myComponent.
Is it possible to return a copy of myComponent? Or is it possible to make it read-only somehow?
In the situation you describe, it is not possible to retrieve read only components.
You can create read only variables by implementing get methods without set methods. Something like this:
public var get myValue():UIComponent{
return UIComponent;
}
This would allow you to retrieve the UIComponent instance, myValue, from the component; but you would not be able to set it.
However, this would not prevent people from changing properties on the returned UIComponent unless those properties were also implemented as read only.
I'll add that there is already a method, getChildByName() to retrieve a child component by name. If you have an instance to a parent, you can use this to access the children.
All that said, I'm not sure I completely understand what you hope to achieve; with this functionality.
I am looking for some help with designing some functionality in my application. I already have something similar designed but this problem is a little different.
Background:
In my application we have different Modules. Data in each module can be associated to other modules. Each Module is represented by an Object in our application.
Module 1 can be associated with Module 2 and Module 3. Currently I use a factory to provide the proper DAO for getting and saving this data.
It looks something like this:
class Module1Factory {
public static Module1BridgeDAO createModule1BridgeDAO(int moduleid) {
switch (moduleId)
{
case Module.Module2Id: return new Module1_Module2DAO();
case Module.Module3Id: return new Module1_Module3DAO();
default: return null;
}
}
}
Module1_Module2 and Module1_Module3 implement the same BridgeModule interface. In the database I have a Table for every module (Module1, Module2, Module3). I also have a bridge table for each module (they are many to many) Module1_Module2, Module1_Module3 etc.
The DAO basically handles all code needed to manage the association and retrieve its own instance data for the calling module. Now when we add new modules that associate with Module1 we simply implement the ModuleBridge interface and provide the common functionality.
New Development
We are adding a new module that will have the ability to be associated with other Modules as well as specific properties of that module. The module is basically providing the user the ability to add their custom forms to our other modules. That way they can collect additional information along with what we provide.
I want to start associating my Form module with other modules and their properties. Ie if Module1 has a property Category, I want to associate an instance From data with that property.
There are many Forms. If a users creates an instance of Module2, they may always want to also have certain form(s) attached to that Module2 instance. If they create an instance of Module2 and select Category 1, then I may want additional Form(s) created.
I prototyped something like this:
Form
FormLayout (contains the labels and gui controls)
FormModule (associates a form with all instances of a module)
Form Instance (create an instance of a form to be filled out)
As I thought about it I was thinking about making a new FormModule table/class/dao for each Module and Property that I add. So I might have:
FormModule1
FormModule1Property1
FormModule1Property2
FormModule1Property3
FormModule1Property4
FormModule2
FormModule3
FormModule3Property1
Then as I did previously, I would use a factory to get the proper DAO for dealing with all of these. I would hand it an array of ids representing different modules and properties and it would return all of the DAOs that I need to call getForms(). Which in turn would return all of the forms for that particular bridge.
Some points
This will be for a new module so I dont need to expand on the factory code I provided. I just wanted to show an example of what I have done in the past.
The new module can be associated with: Other Modules (ie globally for any instance of that module data), Other module properties (ie only if the Module instance has a certian value in one of its properties)
I want to make it easy for developers to add associations with other modules and properties easily
Can any one suggest any design patterns or strategy's for achieving this?
If anything is unclear please let me know.
Thank you,
Al
You can use springs Dependency Injection feature. This would help you achieve the flexibility of instantiating the objects using an xml configuration file.
So, my suggestion would be go with the Springs.
I have a tree control in my GUI (with naturally lots of GUI/platform specific functions to handle the nodes).
I have a data model with its own complex set of nodes, children, properties etc..
I want the tree to display a representation of the model, be able to send messages to the nodes inside the model and be told to redraw itself when the model changes.
But I don't want the GUI code to need to know the details of the model's data types and I don't want to pollute the model by linking it to the GUI classes.
I can't get my head around how the controller is supposed to do this and what functions it should provide?
(this is in C++ but that shouldn't matter)
GUI "controls" don't quite fit neatly into a model-view-controller pattern because they typically have their own internal model rather than accepting a reference to one. If the control is structured that way, you'll need an adapter class that "data-binds" the control's internal model to the underlying data model.
This can accomplish something similar to what model-view-controller would, except that the adapter class plays the role both of a view hookup component (updating the GUI from the data model) and a controller (interpreting GUI events into model actions).
Qt provides a group of classes for model-view programming. You can hook a tree view to a filesystem model, for example, and neither directly know anything about each other (except a pointer to the model in the view).
Your requirements are:
Tree displays representation of model
Nodes in tree can send messages to nodes inside model
Tree redraws itself based on model changes
I don't know exactly what kind of data you're working with here, but a hierarchical model is a fairly simple thing. I'll take it as a given you know how to iterate hierarchical data and populate a tree view.
Your controller should have member function(s) for sending messages to the model. The parameters should be a model element and the message you want to send. This way, the UI is completely unaware of how the message gets to the element, but can get the messages through.
The last requirement is more tricky, and depends on a few things (e.g., the lifetime of the controller, application architecture, etc.) I'm going to assume the controller lives as long as the tree view does. If that's the case, then your controller should provide a way to set a callback on model changes. Then, when the controller changes the model, it can callback to the UI without being aware of the UI.
i think your troubles start with an unfortunate choice of words. the 'control' thingies doesn't have anything to do with the 'controller' in MVC. that's why some GUI libraries use other names (widgets is a common one).
your 'tree control' is the view, not the controller. it should be tied to the GUI, both for display, and to get GUI events and turn them into 'tree events'.
the controller gets those 'tree events' and does the necessary modifications to the model. that's where you couple the 'action' with the 'response'.
First Solution: You can implement a "Subject observer" pattern between model and view, with model as the subject and view as the observer. Whenever there is a change in the state of model, it can fire a event to all the observers those are registered, they can update themselves.
Second Solution: Introduce a controller, which registers with model as observer. Upon receiving a event for update from Model, it can update the view. Even you can decouple view from controller using one more subject observer pattern between controller and view
Third Solution: Use MVP pattern. Model view Presenter. This pattern used whenever there is no much computation in controller i.e., job of the controller is just to update its corresponding view. Here controller becomes Presenter.
You need a controller that sits outside the display widget but has the state of the tree (in MFc there are CTreeView/CTreeCtrl classes - there is a similiar separation in Qt) the tree controller handles all the data storage and calls redraws on the tree widget.
Changes in the tree widget get sent to the tree controller - so this controller needs to know about the gui functions.
The model will need set/get functions for all the relevant parameters for the nodes. But these can return simple types so aren't dependent on the gui.
Updating the view form the model requires sending a message, if you don't want the model to know about your gui messaging the best you can do is register a callback function (a void pointer to a function) from the tree controller - and call this to do an update.
This update function can then query the model for the changes.