In the context of AS3 and specifically a framework such as PureMVC, I was wondering if someone could point me in the right direction for understanding what an API for a View Component means.
Thanks in advance.
Well, you have your mediators holding your view components, right? Let's say the view component is a form where the user enters data.
Since the view component cannot send notifications it needs some way to pass that information to the mediator that will then send the notification. You have 2 ways of passing the information:
You make your view component expose an API (a set of public methods / variables).
You make your view component send events when the information changes.
If you send events, there would be less coupling between mediator and component. If you do it via an API, it would be simpler-ish.
You can also mix and match both methods.
Hope this is it!
Juan
I think so more cleaner way is in your mediators onRegister method only add eventhandler for associated view. So it will make your view really reusable and totally decoupled with mediator. Your view doesn't know about mediator and it can be work with any framework.
Related
Is there an easy accessible function to get manifest data in javascript to check if the model is done translating?
something like viewerApp.getManifest().progress. Where viewerApp is a ViewingApplication.
Is there something like this, or should I retrieve the data via server code and pass it on to javascript.
No, there is not an client side API as you mentioned to get the progress of model translation.
I am interested in the reason why doing that way. Actually, the ViewingApplication is a client side API and is used to view the model when the model is already translated, it's not suggested to request the translation progress by this API.
If you want to get the status of the translation progress, Yes, using the GET :urn/Manifest to get the progress.
I have always worked with Web APIs, so I don't know how to handle this very basic problem in .NET Core MVC (I am only familiar with MVC conceptually). My problem:
I need a user to select an option from a dropdown on the front end and then show some data based on the option (after fetching it).
If I were writing an SPA consuming an API, I would simply make a call to the backend to get the data and then generate the html to display it on the front end.
How is this handled in MVC? Isn't the convention to return entirely new views? How are things like these handled?
I just need a pointer in the right direction conceptually - I can figure out the code.
Edit: Should I just pretend it's an SPA despite it being a view and create an API endpoint in the same app that provides the view and consume it from the cshtml?
It works exactly the same way. You make an AJAX call to fetch some data. You can either return the data directly, and utilize JS to render the HTML or return HTML directly. Either way, you use the AJAX callback to replace the appropriate content on the page.
Even in older ASP.NET MVC projects it worked this way, though you basically had to decide whether you were going to use an MVC controller or a Web Api controller to do the work. Either would work, but there were advantages/disadvantages to each approach. MVC/Web Api could always coexist in the same project.
In ASP.NET Core, the difference is purely semantic. There's really no such thing as MVC and Web Api anymore - just ASP.NET Core. A controller is a controller is a controller, so just add an endpoint and go to town.
From what I've read, one would generally use a global variable so that all controllers have access to some data.
Is there an "best-practice" way of accessing global data in the view templates? The use case would be for storing semi-static data like the website's brandname or location address. If in the future that data changes (ie, rebranding), it would be trivial to update the view to reflect those changes.
This thread suggests that using $rootScope is bad, and a better way would be to use a Service. However, in my case this gets messy because I have to mentally remember to include the service and create a scope var in each controller that has a template that will reference the static data.
I've seen suggestions of storing this data in a database, and then querying for it when needed. But that advice tends to be for server-side frameworks, and I would rather not do a GET query to the server just to grab static data in Angular.
I could leave it hardcoded as I have it now, and just run a grep to search and update whatever templates.
Is there a way to assign static data to variables once, and then have it be accessed in the templates without going through hoops? And all the while following Angular best practices? Or perhaps hardcoding the the easiest/cleanest approach?
Service Factory behave like singleton, when injected in different module you actually access the same data so it works perfectly for communication between controller.
Each component dependent on a service gets a reference to the single instance generated by the service factory.
If you want access those data in your template, just include the object in your scope, display. This will automatically implement two-way binding and is a good practice for MVC pattern.
To know the difference between Service and Factory : angular.service vs angular.factory
But try to avoid as much as possible to use global variable :D
BUT
This apply in a perfect world with perfect developer ... I love using a global variable like SETTINGS (uppercase to make it sounds constant) and which include some data required before angular initialization for exemple.
Would work well for such data like title and stuff like you have. However, you still need to add it manually in your scope (which for a title would be ... once ? Yeah seems ok)
how to make a web service call in fragment.
i am working on a project which require a service call and i am working with fragments.
how to make the JSON call and place the result in a fragment.
If i understand your problem properly, you are trying to make webservice call from the fragment. When a fragment creates it calls like below steps:
onCreate(): The system calls this when creating the fragment. Within your implementation, you should initialize essential components of the fragment that you want to retain when the fragment is paused or stopped, then resumed.
onCreateView(): The system calls this when it's time for the fragment to draw its user interface for the first time. To draw a UI for your fragment, you must return a View from this method that is the root of your fragment's layout. You can return null if the fragment does not provide a UI.
So better approach will be; in your onCreate() method, call the webservice by using AsyncTask or Volley. If you use AsyncTask, it will call onPostExecute method when its done. Now you create your object (if you follow mvc) and update ui.
We're using interfaces to represent entity classes in our domain model. We have concrete implementations of these by virtue of using LinqToSql. We have added a factory method to each LinqToSql class which our service layer uses to instantiate a new entity (note; as opposed to the controller's DataBind attribute doing it).
MonoRail's default DataBinder implementation will ignore properties that are defined as interfaces.
Ideally, we don't want to instantiate our data-layer classes in MonoRail - the whole point of the interfaces is to separate these concerns.
Also, we don't really want to create another set of non-LinqToSql concrete classes whose only job is to translate between layers.
It's the end of a really long day over here; please can someone have mercy and point us at the parts of IDataBinder that we should overload with our own implementations, or hint at other approaches we might attempt? ;-)
You should be looking at IParameterBinder. take a look at a post I've written on the subject
As Ken pointed, your idea could be implemented with a custom IParameterBinder.
A solution would be to use IOC:
resolve concrete instance of the form from it's interface
then use IDataBinder to bind the instance to the request params
Another one would be using IDictionaryAdapter:
generate a dto proxy for your interface
then use IDataBinder to bind the dto proxy instance to the request params
NB: second option won't work if interface:
is not public (hum)
has methods
or events
or readonly properties
or setonly properties
Last, I'm unsure of what is the problem exposing concrete class in controller's signature.
I myself use concrete form in controllers implementing interface defined in application layer services, it allows me to have concerns separated on both side:
controller side is Http mapping and first level data validation of the form/command
application layer services is business validation and processing of the form/command