I hope there is a way for either SAPUI5 or OpenUI5 as this would ease the development efforts to implement data loss protection. If there isn't, I would be interested to know the best alternative to implement similar behavior. I was thinking of maybe extending the sap.f.routing.Router and checking an application-level dirty flag before handling the navigation.
Before exiting the application, methods:
https://sapui5.hana.ondemand.com/1.71.38/#/api/sap.ui.core.Component/methods/onWindowBeforeUnload and https://sapui5.hana.ondemand.com/1.71.38/#/api/sap.ui.core.Component/methods/onWindowUnload
are worked out in the Сomponent of the application. In this method, you can call the hasPendingChanges method on the OData model to check for unsaved changes and show a dialog for user interaction.
You can also look in the direction of drafts, implemented on the BOPF or RAP frameworks. Then the state will be stored on the backend. But this is a global change of concept, which will affect the revision of the implementation of logic in the backend.
Related
Instead of using flux/redux architecture, how react components should communicate with services?
For example:
There is a container having few representational (react) components:
ChatBox - enables to read/write messages
AvatarBox with password changer - which enables to change user's password
News stream - lists news and apply filter to them
Thinking of them as resources representation, I want each of them to access Microservice API by itself (getting or updating data). Is this correct?
It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content
This question also reffers to: How to execute efficient communication for multiple (micro)services?
When you opt for not using Flux/Redux, here is what you do:
Create an outer component that should wrap all the other components. This component is also known as a higher order component or a controller view. This component should use an HTTP library to communicate with your microservices (I personally like Axios). I would recommend that you create a client API object that wraps Axios. Your higher order component can reference this client API so it is agnostic of the HTTP library and whatnots. I would also put a reference of this client API on the window object in dev mode so you can do window.clientApi.fetchSomething() in the Chrome console and make debugging easier.
Make all the other components (ChatBox, AvatarBox and NewsStream) controlled. If you are not familiar with this concept, it means they receive everything they need through props and they avoid keeping state. These components should not call the microservices themselves. This is responsability of the higher order component. In order to be interactive, these components should receive event handlers as functions as props.
Is this correct? It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content
You can avoid performance issues by not allowing each component to directly contact the microservices. If your higher order component compiles all the information needed and make as little as possible HTTP calls, you should be perfectly fine with this approach.
It's generally recommended to use Flux/Redux, but if you opt out, this is how to go about it.
According to: https://facebook.github.io/flux/docs/overview.html#content
Occasionally we may need to add additional controller-views deeper in the
hierarchy to keep components simple. This might help us to better encapsulate a
section of the hierarchy related to a specific data domain.
And this is what I am thinking about responsibility of particulary component's domain (three of them was described). So could it be reliable to make three controller views (or stores) that can access dependent API to manage resource's data?
i would like to go for a step-by-step migration of my existing "serverside rendered" webapplications to a more "cientside rendered" approach.
my preferred starting-point would be to change the existing data-handling layer towards an ajax style approach using a rest http-api to handle put/post/get/delete requests.
so my question is...
is there an appropriate way to use the collection/model concept of backbone.js to my existing webapplication, without having to use routing/controller/views/templates?
i can add here, that i already have a working rest-httpapi using slimframework. and i would like to use backbone.js model/collections to fetch/save data. but html-rendering and event-binding should be out of backbone.js' responsibility for the moment.
thanks
i finally ended up with the "whole-stack" approach. after many hours of elab, there is no doubt to me, that an isolated usage of models without backbone-views and controllers is more painfull, than it helps.
thanks for all input.
I am developing a GWT app using GWTP (Model-View-Presenter) that is deployed to GAE. Persistence will be done using Google Cloud SQL.
I am not sure what to use to send data to the database (persistence) and request data: GWT RequestFactory or GWTP Actions. Are they equivalent? What are benefits of each one for this scenario?
Thanks
I wouldn't use Request factory as it stands right now. Even for CRUD it's much more complicated to us than GWTP Actions.
RF is a great and powerful tool, but it's a little bit over engineered and working with complex data can be really difficult with all the "frozen" states problems that you will end up having. The real problems comes while using the editors with nested structures. You'll have problems saving the second level of proxies and even more the third level. Using editors with nested structures is a lot more easier with the SimpleBeanEditorDriver since you don't have to deal with the nasty frozen state for each level of nested objects.
For a simple object graph with simple CRUD support, RF is perfect, but as soon as you go to more complicated structures, brace yourself, it won't be easy to handle. Once you become a RF expert, it become a really powerful tool, but it still require more work than GWTP Actions to accomplish the same thing.
For server side security using RF, I've used AoP. On the other side, you could use action handlers, but even by using action handlers, there's some case where AoP on a service call is more appropriate.
For client side batching and caching... that's something that is really hard to achieve with RF. The documentation is unclear and dealing with frozen state within the cache is a nightmare. With GWTP-Action, there's already a simple cache implementation that you can use.
For a data-oriented app (CRUD), you should definitely use RF because it has been designed for that purpose. Now if your app is more action-oriented and these actions does not involve much data, it’s better to use the Command pattern. But nothing prevents you from using both in your app.
RequestFactory only.
Everything you need is there. If you just want to send a basic message you just call a method with whatever parameters you want.
Problem with Actions is that they're a lot more verbose than RF semantics...
Only thing you don't get with RF is the ability to use ClientHandlers...
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.
I'm in the middle of converting an existing app built on top of zend framework to work as a plugin within wordpress as opposed to the standalone application it currently is.
I've never really used zend so I've had to learn about it in order to know where to begin. I must say that at first I didn't think much of zend, but it's funny because the more I understand how it works the more I keep questioning why I'd want to remove dependency when it's a clearly well thought out framework. Then I'm reminded that it's because of wordpress.
Now I already know there are WP plugins to make zend play nice with WP. In fact I'm aleady using a zend framework plugin just to get the app functional within the WP admin area which is allowing me to review code, modify code, refresh the browser, review changes, debug code, again and again.
Anyway, I really don't have a specific question but instead I'm looking for advice from any zend masters out there to offer advice on how to best go about a task like this one.... so any comments, advice, examples or suggestions would be super.
One area I'm a little stuck on is converting parts of zend->db calls to work as wpdb calls instead... specifically the zend->db->select.... not sure what to do with that one.
Also on how to handle all the URL routing with automatic calls to "whatverAction" within thier respective controllers files.
Any help would be great! Thanks
You're probably facing an uphill battle trying to get some of the more major components of ZF to work in harmony with Wordpress. It sounds like you've got a full MVC app that you're trying to integrate into a second app that has very different architecture.
You probably want to think about which components handle which responsibilities. Wordpress has it's own routing and controller system that revolves around posts, pages and 'The Loop'. This is entirely different from Zend's Action Controllers and routing system.
It's possible you could write a WP hook to evaluate every incoming request and decide if it should be handled by WP or a ZF controller. However, it is doubtful you would be able to replace WP's routing system outright with ZF's or vice versa.
Same idea, where Zend_Db is concerned. There's nothing stopping you from using Zend_Db to access Wordpress's database, but trying to somehow convert or adapt Zend_db calls into wpdb calls sounds painful. If you have a large model layer, you probably want to hang on to it, and find a way to translate data from those models into the posts/pages conventions that Wordpress uses.
Personally, I would use ZF to build a robust business layer that can be queried through an object model via a Wordpress plugin, and then rely on Wordpress to do the routing and handle the views.
Zend_DB_Select is simple SQL query (but created using objects) that can be used like any other query. Just turn it into string. Ex.:
mysql_query((string)$zendDbSelectObject);