How struts 2 interceptors will receive sencha json format request. Please give some example of integration.
(Moved to answer for space purposes, this is more of an extended Q&A than answer.)
Why do you want to parse JSON in an interceptor?
Interceptors are for functionality across an entire application–if you have a specific JSON parameter you need in a lot of actions, consider using a base action class and putting your interceptor after the JSON interceptor and just querying the action for the parameter instead. Otherwise you're parsing JSON twice.
If it's not for functionality present across a large portion of the app, then you almost certainly shouldn't be doing the work in an interceptor, but rather an action. To implement this you can use either just the JSON interceptor, or the REST plugin, which handles a lot of other things as well.
There are examples of these in the Struts 2 distribution, but if you have a specific question, it might be easier to ask a real question here or on the Struts user mailing list. Asking for an example is redundant, because the distribution includes examples of most S2 functionality.
Related
I've read quite a few articles on good design for Rails APIs. However, I can't seem to find what I'm trying to do. And it's different enough that I'm not sure what to do.
So this Rails site has forms for generating various records for my various tables. It all works fine. No problem there. This is all admin-level stuff.
However, a few of these forms need to be also be available as an API. Right now my APIs work fine but it's poor design (I think). Currently the user will make an API request to do some action and pass some information in (i.e. add record to Foo).
My method inside the API, special_new_foo, more or less duplicates my create inside the foo controller that a form would route to. Is there a way I can reuse my standard create method? The API would then just check for good data, etc. and pass the information onto the controller...
I was thinking about just making an HTTP request to the local server on the machine (which is basically how the forms work, except they're two separate machines). Is this good practice?
Thanks!
One option is to allow you controller to respond with different formats, depending on the request. I think this is what rails generates on scaffolding. However i barely saw any real world app doing this. See also my answer to Is it necessary to build a separate API endpoint for mobile apps to access a Rails web app?
A better solution is to make an extra ServiceObject or FormObject dealing with business logic of your controllers and reuse this object in both endpoints
see http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
I am trying to use an XForms document that creates an instance from a different XML document depending on a request parameter or header. I can't find a way to do it without using Orbeon's xxforms:get-request-parameter().
Orbeon also suggest this:
<xforms:instance id="user-data" src="input:instance"/>
I might be able to use this (assuming BetterForms supports it) but I need multiple XML documents as inputs. I may be able to rig up a way to put all the XML documents into one post XML fragment, but that's not much fun either.
I originally tried generating the XForms as the return of an XQuery document with request:get-parameter() but I'm running into problems with it. Is there something I'm missing or are these methods the only good ways to send stuff to XForms?
At this point, it looks like your choices are as follows:
With Orbeon Forms, use the Orbeon's extension XPath functions to access the HTTP request.
With Better Forms or XSLTForms, contact the authors to see if they can implement the standard URI functions introduced in XForms 2.0.
Is there an approach that preserves the single-definition of validation, allows immediate client-side validation, and still provides the strength of server-side validation?
I'm familiar with the following two approaches:
ngval (https://github.com/alisabzevari/ngval)
http://www.danielroot.info/2013/09/hooking-angularjs-validation-to-aspnet.html
The first renders ng-validation syntax in Razor output, based on rules stated in the model. That seems like it couples me too tightly to building Razor views, when Razor views often won't intuitively pair with a well-organized Angular app. I could use this approach, but it seems it's more a result of someone wanting to replicate "Unobtrusive jQuery/MVC Validation", than building something well-suited to Angular.
The second approach just returns server-side validation back to Angular to render. It also doesn't do a thorough job of it. If needed I could run without client-side validation, since a single-page app still won't get screen flashes... but it's not ideal.
For example, maybe there is a toolset to more directly reflect the validation rules directly on WebAPIs and consume them in an Angular app. Or another approach that I haven't found?
At https://www.youtube.com/watch?v=lHbWRFpbma4#t=1336 , the presenter seems to imply this problem is already well-solved for Angular, and refers to specification (DDD Using Specification pattern for Validation). If you are aware of any tools that make this applicable to my problem, I'd love to hear it.
p.s. It seems like this is almost certainly an often-asked question. I'm sorry I was unable to find an answer here before posting
p.p.s. I'm currently planning to use Entity Framework, but I'd switch to address this. Heck, I'd consider switching to a whole different platform for this, my first Angular-focused project.
The approach I recommend is based on #Esteban Felix commented and I used similar strategy in Java/Bean Validation and JSON schema generator.
Annotate your Domain model using Validate Model Data Using DataAnnotations
Generate schema using JSON.net other useful links
Create a AutoValidate directive that goes on and decorate fields with AngularJS build in directives for form validation e.g. ngPattern and simple things like min/max. In my case I created a mapping from Java world to AngularJS directives and wherever I needed we created custom directives.
In my ASP.Net MVC 2 application I am using a Json object to submit form data. I would like to take expert advice whether it is a safe and good practice to do it or not and why? Please note, this question is not about how to do it but rather about best practice. Appreciate your valuable suggestions.
Yes it is safe to send and receive JSON from/to the server. You only need to make sure to properly format and encode it. Whether it is good is subjective and will depend on your scenario. As JSON is a common format for javascript it is used along with AJAX requests.
I think it's a safe way to go.
I don't think there is much difference (for security reasons) to send the data via a regular post or a Json object submit.
In both cases the data is wrapped into a http post request which is a readable thing.
So i think both solutions are equal from a security perspective.
As said above, JSON is fine to use going both ways, provided you are still applying the same validation as you would with any form input.
Personally, I love the ability to make AJAX calls and simply do:
Return Json(myDataObject)
Then it's really easy to process that with jQuery on the client side as it's automatically transformed into javascript variables for you.
I'm a little late to the party, but I'm trying to wrap my brain around how REST is supposed to work, both in general and in Ruby on Rails. I've read a bunch of articles online about this already, but still don't feel like I'm getting the big picture.
REST as I understand it, is a series of aspirational statements, with the net result at the bottom being that URLs should contain all the information necessary to handle a request, and gets should not be able to change the state on the server, and a bunch of other concrete guidelines.
As I understand it, REST in Rails is based around CRUD, which is to say, every model has a create, read, update and a delete action. Each of these actions is accessed through a similar set of URLs, generated by mapping a resource in the routes. So a login URL is creating a user session, so the URL would look like example.com/session/new with a POST, and logout would be example.com/session/destroy with a POST.
What exactly is the benefit of standardizing URLs in this fashion? It strikes me as optimizing for machine readability at the expense of human readability. I know that you could then remap in the routes file example.com/login to example.com/session/new but that is just one more step for no apparent gain to me.
Is it considered really bad practice to develop a website that uses traditional routes now?
Furthermore, each of these CRUD actions should be able to respond to requests with whatever type of response the request is looking for. So the same link to, say, example.com/tasks could also be called at example.com/tasks.xml to get an xml representation of the result, or example.com/tasks.json for a json representation.
Is this to say that a RESTful API would just be the usual links on the site but with xml appended? It strikes me as very strange and awkward that a web API would behave in this way, but this seems to be what's implied by everything I've read. I'm more used to seeing an API that has links like example.com/api/tasks to get the list of tasks. What exactly is the advantage of this approach?
Rest provides another chunk of "convention over configuration." For a widely used, limited set of common problems (crud actions against the models as a whole), rest is very useful as an application development convention.
What exactly is the benefit of
standardizing URLs in this fashion?
Programmer efficiency. Less to think about; enables more time to be spent on harder problems, etc. Better maintainability. Easier testing. Etc.
Is it considered really bad practice
to develop a website that uses
traditional routes now?
Yes, for crud actions that are interacting with an entire record of the model.
Furthermore, each of these CRUD
actions should be able to respond to
requests with whatever type of
response the request is looking for.
So the same link to, say,
example.com/tasks could also be called
at example.com/tasks.xml to get an xml
representation of the result, or
example.com/tasks.json for a json
representation.
Is this to say that a RESTful API
would just be the usual links on the
site but with xml appended?
Yes, if your api fits the rest model. I think the big issue is authentication. If you want your api to be stateless, then you'll probably need to include authentication with each call. At that point, if you don't want to use HTTP level authentication, you'd need to decide how to include the credentials.