I was looking at this example https://github.com/DarthFubuMVC/fubumvc/blob/master/src/FubuMVC.AspNetTesting/Http/can_read_response.cs and wondering how I can integration test fubu mvc.
What I want to do is give it my request or input model, and then all the behaviours and handlers executed, so I am given back just the view model or redirect i.e. I don't need it to render the view.
Suggestions please?
Look at the tests in the integration testing project in FubuMVC instead. If you can get away with it, it's much easier to use the Self Host capability instead. I suppose this could be my weekly blog post for the week.
Related
I know the question is about solving the problem probably by different approach but let me specify in details what I want to ask and how much I understand about it.
We have two mvc approach used in ATG(or many other framework) pull based and push based.
As I understand it formhandlers and droplet both are playing the part of controller in different need, repositories are our model and jsps are providing views..
And if i am right till this point then what purpose the servlet chain is solving?How it fits into this picture of MVC?
Please If possible explain with the help of flow diagram from request to response (end to end).
Thanks a lot in advance to experts.
Please help.I could not find this kind of explanation anywhere.
The first thing to remember with ATG is that it is an old platform. So when trying to understand the different mechanisms through an MVC lens, remember that nothing was designed with MVC in mind-the platform predates widespread knowledge and acceptance of the MVC pattern in web development.
Droplets are a generalized mechanism for invoking Java code from a JSP (and previously, JHTML) template. The closest analogue in J2EE-land would be tag libraries. So you can use them to accomplish many different tasks. You can also use them as a poor man's MVC controller. This is done by coding a custom droplet class dedicated to handling the business logic of your page, and setting relevant page state as request parameters. Then you invoke the droplet as the first step in your JSP page. This is not very different from J2EE model 2 with the odd quirk that first your compiled JSP begins executing, then invokes your "controller" code and then resumes with processing the "view."
Form handlers, as the name indicates, are designed for processing form submissions. These are executed by a link in the servlet pipeline (DAFDropletEventServlet), before the page which was posted to begins rendering. Typical usage with form handlers is that they will send a redirect after executing, and cancel rendering of the page, which will abort any further processing by the servlet pipeline. Form handlers are the closest thing to a "controller" ATG provides. But they are awful for handling GET requests and result in some very unfortunate URLs when used for this purpose.
Why did they create two different mechanisms? Why have they not subsequently introduced an updated MVC model as part of the platform? These questions I cannot answer.
ATG, at the page rendering level, is not MVC. Don't look at it as MVC. ATG, at its core, is an extension of the basic Servlets API.
Forms and form-processing, with the successUrl and errorUrl is kind-of MVC. Droplets certainly are not.
It is perfectly acceptable in an ATG application to be fetching data as the page is rendering (i.e. Droplets)
I hope you can help me. I've tried to look for a solution to this problem or for a similar question here in StackOverflow but couldn't find any, so here it is.
We must develop a feature in which we will have a multi-page form. After filling all the pages of the form, the user will submit it. The problem is that the final submit will send many parameters (around 500), and we're afraid we may encounter problems with request size in many cases.
An initial approach would be having an object in session, which would be partially filled when the user navigates through the pages. I.e. when the user fills the fields in page 1, the object in session is partially filled with that data, and so on. That way, we wouldn't have to pass all the request parameters in every step and the final submit wouldn't have to send so many data. But we don't want to use this approach because we don't want to use the session to store data that are specific to a single functionality or bunch of pages.
Another approach would be saving data to a database after the user fills each page of the form, and retrieving it after the final submit so we can deal with the whole thing. Maybe we could do this, but it would delay the development of the project since it's not a trivial task.
I wonder if there's a better approach to handle this. Maybe using #Cacheable in some intelligent way, maybe using Spring WebFlow (which I've never worked with), maybe other alternatives I can't think of. Is there any strategy or technology I could use for this? Currently we are working with Spring 3.2. We are using jQuery as well, just in case it's relevant.
Thank you.
Writing as answer as I would not fit into comment:
There is no limit to request body size for POST requests. Only GET requests are limited (i.e. when parameters are sent via query parameters). No need to worry here.
I don't understand why you don't want to use session (#SessionAttributes). Having multi-step forms is one of the use-case this was designed for I would say.
Storing incomplete model objects in database is also a good approach as it is very close to REST principles. We have used this multiple times in our company.
Spring WebFlow is also a good approach if you don't want to handle all the transitional logic yourself. However SWF is not that simple technology to learn and you should include that fact in your effort estimations.
There is another approach, which I would say is becoming more and more popular: doing all the logic dynamically on a single webpage (e.g. via AngularJS or some jQuery plugin) and submit the result as a JSON object.
There is no definitive answer to your question without being very specific about your use-case and your application. And even with exhaustive description it is question about personal preference.
The single dynamic page approach (e.g. AngularJS) would be good if your overall application architecture is going to be designed that way.
Spring WebFlow would be nice if you are familiar with that technology or if you are planning on having more multi-step forms throughout the application (i.e. I would not go for SWF if I need to solve just one use-case with it).
I would probably go for #SessionAttributes if I need to quickly solve a single multi-step form. There are some complexities connected to that (partial validation and partial binding namely)... so again this might not be the simplest approach in the end.
Spring Webflow would handle your use case nicely through its flowScope.
Anyway, I you don't want to go through the pain of integrating its infrastructure only for that, the session attribute you mentioned will work perfectly and it's a correct approach. Just make sure you remove it when it's not neccesary anymore to prevent memory leaks.
Alright, so a better title here may have been "Progressive Enhancement with REST in CakePHP", but at least now I'll know you didn't read the question if your answer just refers to the difference between the two ;)
I'm pretty familiar with REST and how to integrate it with CakePHP, but I'm not 100% on board with how to still maintain a conventionally functioning website. Using Router::mapResources sounds like a great idea, but this creates a problem with maintaining the "gracefully degradation" version of the site, because both POST requests to /resource/ AND GET requests for /resource/add will route to the same action (add). Clearly I'll want this action to return a JSON object if they're using the REST api, but if they're using the degraded version of the site (no JS perhaps), it should be a add form, right?
What's the best way to deal with this. Do you route your REST requests to other action names using Router::resourceMap()? Do you do that crazy hack I saw to have the /api/ prefix part of the resourceMap so you can use api_action functions? Do you have the actions handle both REST and conventional requests via checking isAjax()? If so, how do you ensure that you can rely on the browser to properly support the other two request types?
I've searched around quite a bit but haven't found anything about how to keep conventional requests available in Cake along side REST, so if anyone has any advice or experience, I'd love to hear it!
CakePHP uses extension routing as well, via Router::parseExtension() so;
/test/action will render views/test/action.ctp
/test/action.html also
/test/action.json will render views/test/json/action.ctp
/test/action.xml will render views/test/xml/action.ctp
If all views are designed to handle the same data as set by your controller, you'll be able to show a regular HTML form and handle the posted data the same way as you'd handle the AJAX request.
You'll probably might have to add checks if any data is posted/submitted inside the /add, /edit, /delete actions to prevent items being deleted without a form being posted (haven't tested that though, it might be that cake blocks these urls if mapresources is set for the controller)
REST in CakePHP:
http://book.cakephp.org/2.0/en/development/rest.html
(Extension) Routing
http://book.cakephp.org/2.0/en/development/routing.html#file-extensions
We have an app which is developed in wpf + DevExpress using MVVM pattern. We need to implement Specflow with MStest on viewmodel level.
Have anyone tried this? Any pointers? Is codedUI any good at viewmodel level?
I had two thoughts when I read that question.
First - think if you really need to automate everything through the UI. With an architecture like MVVM you have a great opportunity to hit the application beneath the UI and still get a lot out your test automation. For example write your step definitions against the ViewModels.
Testing against the UI easily run the risk of creating brittle tests. The UI is the part of most application that changes very frequently. Tests hitting the UI need to cope with this somehow (more on this later).
Secondly, for the things that you need to automate against the UI, consider using White which is a nice object oriented abstraction above the UI Automation Library. I've used it extensively and like it.
With any automation be sure to create an abstraction over the actual automation, with the driver pattern for example. A simple way to do this is to create a screen/page object that have properties and methods to interact with the screen/page in question. Your step definitions then uses these wrapper objects.
Keep your step definitions thin and your wrapper objects fat. A bit like a controller in the MVC-pattern. More on this here
I hope this was helpful
Well I haven't tried it but I can't see anything wrong with it. By using specflow you create methods to do one thing say "The user presses the about button" and your code would be something like this
[Given(#"The user presses the about button")]
public void TheUserPressesTheAboutButton()
{
this.UIMap.PressAboutButton();
}
You may have to fiddle around to create all the methods but it's not a big deal. There's a simple guide here. Something that could be a glitch is the naming and identification of the controls so that CUIT builder would be able to find them.
Yes. It works pretty good. The biggest challenge is really defining your sentence structure and Given/When/Then statements so they are consistent and re-usable. Otherwise you end up with Tags and 5-10 givens for a single method. Not really maintainable.
We used Specflow for unit testing MVVM as well as other business components. The Given statements would basically setup the mock data, then execute the test:
Given I have created a database context
And it contains the following Books
|ISBN | Author | Title |
...
I also used specflow for Functional Testing (end to end) for automated testing via TFS. A database and server are deployed (with real or test data), then the functional test suite is executed against that server/database (creating data, modifying data, etc).
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);