Problems on designing testing an application with 2.4 version.

Hello,

I recently took a look at the stable 2.4 Enyo version and I can see some obstacles on implementing an application with it.

1. HMAC Authentication / Request-validation: I am using message level authentication to talk with the server, which means prior to every request I must create some authentication token for each user in the client side and add it in the request's header. Currently, I have a centralized `api` component which exposes certain methods for generating getting/setting/deleting/editing requests on server resources, before sending a request there is a set of private middle-ware functions like request-validation / HMAC-token-generation. How could I adapt same logic here where models and collections come into play? I guess I could create new `enyo.Model` & `enyo.Collection` subkinds and overload all the methods I want to with the middleware functions but I am having repeated logic for Model and Collection methods. Is it the only way it can be done?

2. Testing application: Currently while testing application I am not dealing with any server requests, a mock component with exactly the same public methods as `api` component mentioned above, replaces it, emulates requests and returns random generated data. The rest of the application can't even realize something has changed. How can I achieve this since an enyo.Model/Collection gets a url pointing to the server resource and tries to make http requests? Need to create a corresponding mock Model for each one of them which is being used in my app? The collections too. Need to dive into the application controls' code and define for any view that uses these models/collections some logic when to use the real one and when the mock? Need to make my whole application aware that is being tested??????

3. Nodejs Documents: The server is running on Node.Js and the resources are a hybrid model of documents and relational architecture. Not to get into details, that means that some responses are documents meaning, nested objects. Reading at enyo documentation regarding building data driven apps on "Parsing and Converting fetched data" section suggests that nested objects should be flattened by overwriting the "parse" method of the model. Is there any other way to deal with nested objects? A flattened object needs to get composed back to its original shape again once a PUT request will occur which means more code to achieve nothing important.

I starred at the code for 15' to come up with these questions. Probably there will be some good solutions after one puts some thought. Still I would be glad if someone faced any of these problems and comes with some suggestions.
Sign In or Register to comment.