Re: [Stripes-users] CMS Integration with Stripes
Hi,
as a late follow-up, we ended up being like this:
@ValidationMethod
public void validateOnResolution( final ValidationErrors errors ) {
rest().validateFor( GET, new Runnable() {
/** {@inheritDoc} */
@Override public void run() {
if( whateverValidationGoesWrong() ) {
errors.addGlobalError( new SimpleError( only happens
in GET ) );
}
}
}).validateFor( POST, new Runnable() {
/** {@inheritDoc} */
@Override public void run() {
if( whateverValidationGoesWrong2() ) {
errors.addGlobalError( new SimpleError( only happens
in POST ) );
}
}
});
}
@DefaultHandler
public Resolution navigation() {
return rest().get( new Callable Resolution () {
/** {@inheritDoc} */
@Override public Resolution call() {
doSomethingOnGet();
return new MyJsonStreamingResolution( getContext(),
someRandomReturnValue );
}
}).post( new Callable Resolution () {
/** {@inheritDoc} */
@Override public Resolution call() {
doSomethingOnPost();
return new RedirectResolution( /page2.jsp );
}
}).submit();
}
rest() is defined on our rest-parent ActionBean as:
protected RESTDelegate rest() {
return new RESTDelegate( getContext() );
}
(btw, this rest-parent ActionBean also takes care of
handleValidationErrors(ValidationErrors val))
with RESTDelegate being something in the lines of:
public class RESTDelegate {
final ActionBeanContext abc;
Callable Resolution get;
Callable Resolution head;
Callable Resolution put;
Callable Resolution post;
Callable Resolution ... // you get the idea
public RESTDelegate( final ActionBeanContext abc ) {
this.abc = abc;
}
public RESTDelegate validateFor( final String method, final Runnable
validation ) {
if( validation != null method.equalsIgnoreCase(
abc.getRequest().getMethod() ) ) {
validation.run();
}
return this;
}
public RESTDelegate get( final Callable Resolution get ) {
this.get = get;
return this;
}
public RESTDelegate post( final Callable Resolution post ) {
this.post = post;
return this;
} // same for the rest of Callable Resolution
[...]
public Resolution submit() {
switch( HttpMethod.of( abc.getRequest().getMethod() ) ) {
case GET : return process( get );
case HEAD: return process( head );
case POST: return process( post );
case PUT : return process( put );
case DELETE : return process( delete );
case OPTIONS : return process( options );
case TRACE : return process( trace );
case CONNECT : return process( connect );
case PATCH : return process( patch );
default : return process( null );
}
}
Resolution process( final Callable Resolution rest ) {
Resolution r = null;
if( rest != null ) {
try {
r = rest.call();
} catch( final Exception e ) {
throw new RuntimeException( e.getMessage(), e );
}
}
return r == null ? methodNotAllowedResolution() : r;
}
}
We went with Callable/Runnable above b/c the will allow easy lambda
substitution once we go with java 8.
In the end, we were so obsessed with adding rest support as a stripes'
feature that we didn't see the elephant in the room. As this approach plays
real nice and doesn't require to heavily modify Stripes internals, we'll
stick with it. Thanks for the insights!
br,
juan pablo
On Sat, Feb 28, 2015 at 2:17 PM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but we
basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since this
is an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST, obj
);
}
/**
* Turns a ValidationErrors document into JSON.
*
*
Re: [Stripes-users] CMS Integration with Stripes
Supporting Apache Shiro (which I highly recommend; it’s really good) in any
Stripes app is pretty easy:
http://www.ecyrd.com/ButtUgly/wiki/Main_blogentry_100910_1
You can then e.g. have your own Interceptor or actionbean superclass which does
Subject.login() based on e.g. OAuth headers or cookies or whatever you fancy.
We use something like this:
@Before(stages=LifecycleStage.BindingAndValidation)
public void resolveAccessToken()
{
String bearer = getContext().getRequest().getHeader( Authorization );
String at = getContext().getRequest().getParameter(access_token);
if( bearer != null )
{
at = bearer.substring( AUTH_BEARER.length() ).trim();
}
/* some validation omitted due to brevity */
if( at != null )
{
try
{
AccessToken token = new AccessToken(at);
SecurityUtils.getSubject().login( token );
}
catch( Exception e )
{
/* some code here */
}
}
}
/Janne
On 3 Mar 2015, at 00:35, Nestor Hernandez ilu...@gmail.com wrote:
One option could be Standard Servlet security offers Basic auth, SSL and
other goodies. Configure your web.xml pointing to an actionbean url
El mar 2, 2015 4:38 PM, Joaquin Valdez joaquinfval...@gmail.com escribió:
Thanks Rick! Off topic a bit, but how are login credentials handled with
this framework when calling a rest method?
Thanks
Joaquin
On Feb 28, 2015, at 7:13 AM, Rick Grashel rgras...@gmail.com wrote:
Hi guys,
I also had similar issues writing REST services with Stripes. I absolutely
did not want to get rid of Stripes, so I had to write a REST ActionBean
framework for Stripes which supported all of Stripes validation and binding.
If you are interested, you can download it here:
https://github.com/rgrashel/stripes-rest
I can help anybody out with implementation of a REST service if they need
it. But for this library, full Stripes validation is supported. It uses
the same convention approach that Stripes uses, so you write get(),
post(), delete(), head(), put() methods and they will be automatically
called. It also uses Stripes' own internal Javascript builder and has a new
JsonResolution to create JSON-based responses.
Give it a look if you are interested. I have been using it in production
for quite awhile and it works well.
Thanks.
-- Rick
On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but we
basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since this
is an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST, obj );
}
/**
* Turns a ValidationErrors document into JSON.
*
* @param errors
* @return
*/
private Object constructErrorObject( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
if( !errors.hasFieldErrors() )
{
if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, errors.get(
ValidationErrors.GLOBAL_ERROR ).get( 0 ).getMessage(
getContext().getLocale() ) );
}
}
else
{
for( ListValidationError list : errors.values() )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, list.get(0).getFieldName() + : +
list.get( 0 ).getMessage( getContext().getLocale() ) );
}
}
obj.put(status, 400);
return obj;
}
JSONResolution is a custom class which has this in its heart:
protected static ObjectMapper c_mapper = new ObjectMapper();
protected static ObjectMapper c_prettyMapper = new ObjectMapper();
static
{
c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT, true );
}
@Override
public void
Re: [Stripes-users] CMS Integration with Stripes
Joaquin,
Since there are so many different ways people do
authentication/authorization, I didn't build any kind of authentication
into it for those reasons.
I've personally done it a couple of different ways using this REST
framework. One was BASIC auth and another way was actually writing an
AuthenticateRestActionBean which performs a custom token-based
authentication. Folks could do authentication using their own interceptor,
a filter, JAAS or whatever they want.
-- Rick
On Mon, Mar 2, 2015 at 3:36 PM, Joaquin Valdez joaquinfval...@gmail.com
wrote:
Thanks Rick! Off topic a bit, but how are login credentials handled with
this framework when calling a rest method?
Thanks
Joaquin
On Feb 28, 2015, at 7:13 AM, Rick Grashel rgras...@gmail.com wrote:
Hi guys,
I also had similar issues writing REST services with Stripes. I
absolutely did not want to get rid of Stripes, so I had to write a REST
ActionBean framework for Stripes which supported all of Stripes validation
and binding. If you are interested, you can download it here:
https://github.com/rgrashel/stripes-rest
I can help anybody out with implementation of a REST service if they need
it. But for this library, full Stripes validation is supported. It uses
the same convention approach that Stripes uses, so you write get(),
post(), delete(), head(), put() methods and they will be automatically
called. It also uses Stripes' own internal Javascript builder and has a
new JsonResolution to create JSON-based responses.
Give it a look if you are interested. I have been using it in production
for quite awhile and it works well.
Thanks.
-- Rick
On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but
we basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since
this is an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST,
obj );
}
/**
* Turns a ValidationErrors document into JSON.
*
* @param errors
* @return
*/
private Object constructErrorObject( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
if( !errors.hasFieldErrors() )
{
if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, errors.get( ValidationErrors.
GLOBAL_ERROR ).get( 0 ).getMessage( getContext().getLocale() ) );
}
}
else
{
for( ListValidationError list : errors.values() )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, list.get(0).getFieldName() + : +
list.get( 0 ).getMessage( getContext().getLocale() ) );
}
}
obj.put(status, 400);
return obj;
}
JSONResolution is a custom class which has this in its heart:
protected static ObjectMapper c_mapper = new ObjectMapper();
protected static ObjectMapper c_prettyMapper = new ObjectMapper();
static
{
c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT,
true );
}
@Override
public void execute( HttpServletRequest request, HttpServletResponse
response ) throws Exception
{
response.setStatus( m_status );
response.setContentType( m_contentType );
response.setCharacterEncoding( UTF-8 );
if( true.equals(request.getParameter( pretty )) )
c_prettyMapper.writeValue( response.getOutputStream(),
m_object );
else
c_mapper.writeValue( response.getOutputStream(), m_object );
response.getOutputStream().flush();
}
This btw lets you just get nice JSON back from any API call by adding
“pretty=true” to the request URL. This has proven to be invaluable while
debugging.
One important caveat is that to protect against CSRF attacks you will
want to make sure that every single one of your API endpoints handles GET
requests properly. Since Stripe does not really differentiate between GET
and POST, you might accidentally allow people to make changes to your DB
using a GET
Re: [Stripes-users] CMS Integration with Stripes
Thanks Rick! Off topic a bit, but how are login credentials handled with this
framework when calling a rest method?
Thanks
Joaquin
On Feb 28, 2015, at 7:13 AM, Rick Grashel rgras...@gmail.com wrote:
Hi guys,
I also had similar issues writing REST services with Stripes. I absolutely
did not want to get rid of Stripes, so I had to write a REST ActionBean
framework for Stripes which supported all of Stripes validation and binding.
If you are interested, you can download it here:
https://github.com/rgrashel/stripes-rest
I can help anybody out with implementation of a REST service if they need it.
But for this library, full Stripes validation is supported. It uses the
same convention approach that Stripes uses, so you write get(), post(),
delete(), head(), put() methods and they will be automatically called. It
also uses Stripes' own internal Javascript builder and has a new
JsonResolution to create JSON-based responses.
Give it a look if you are interested. I have been using it in production for
quite awhile and it works well.
Thanks.
-- Rick
On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but we
basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since this
is an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST, obj );
}
/**
* Turns a ValidationErrors document into JSON.
*
* @param errors
* @return
*/
private Object constructErrorObject( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
if( !errors.hasFieldErrors() )
{
if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, errors.get(
ValidationErrors.GLOBAL_ERROR ).get( 0 ).getMessage(
getContext().getLocale() ) );
}
}
else
{
for( ListValidationError list : errors.values() )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, list.get(0).getFieldName() + : +
list.get( 0 ).getMessage( getContext().getLocale() ) );
}
}
obj.put(status, 400);
return obj;
}
JSONResolution is a custom class which has this in its heart:
protected static ObjectMapper c_mapper = new ObjectMapper();
protected static ObjectMapper c_prettyMapper = new ObjectMapper();
static
{
c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT, true );
}
@Override
public void execute( HttpServletRequest request, HttpServletResponse
response ) throws Exception
{
response.setStatus( m_status );
response.setContentType( m_contentType );
response.setCharacterEncoding( UTF-8 );
if( true.equals(request.getParameter( pretty )) )
c_prettyMapper.writeValue( response.getOutputStream(), m_object
);
else
c_mapper.writeValue( response.getOutputStream(), m_object );
response.getOutputStream().flush();
}
This btw lets you just get nice JSON back from any API call by adding
“pretty=true” to the request URL. This has proven to be invaluable while
debugging.
One important caveat is that to protect against CSRF attacks you will want
to make sure that every single one of your API endpoints handles GET
requests properly. Since Stripe does not really differentiate between GET
and POST, you might accidentally allow people to make changes to your DB
using a GET method. We just limit the allowable methods via an annotation
and an interceptor.
Stripe is OK for REST API development; more modern frameworks like
Dropwizard do make some things a bit easier though (btw, Dropwizard+Guice
has a lot of the same feel as Stripe for development - though Stripe’s
templating system is still pretty darned powerful and I haven’t really found
an equivalent).
/Janne
On 28
Re: [Stripes-users] CMS Integration with Stripes
One option could be Standard Servlet security offers Basic auth, SSL and
other goodies. Configure your web.xml pointing to an actionbean url
El mar 2, 2015 4:38 PM, Joaquin Valdez joaquinfval...@gmail.com
escribió:
Thanks Rick! Off topic a bit, but how are login credentials handled with
this framework when calling a rest method?
Thanks
Joaquin
On Feb 28, 2015, at 7:13 AM, Rick Grashel rgras...@gmail.com wrote:
Hi guys,
I also had similar issues writing REST services with Stripes. I
absolutely did not want to get rid of Stripes, so I had to write a REST
ActionBean framework for Stripes which supported all of Stripes validation
and binding. If you are interested, you can download it here:
https://github.com/rgrashel/stripes-rest
I can help anybody out with implementation of a REST service if they need
it. But for this library, full Stripes validation is supported. It uses
the same convention approach that Stripes uses, so you write get(),
post(), delete(), head(), put() methods and they will be automatically
called. It also uses Stripes' own internal Javascript builder and has a
new JsonResolution to create JSON-based responses.
Give it a look if you are interested. I have been using it in production
for quite awhile and it works well.
Thanks.
-- Rick
On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but
we basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since
this is an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST,
obj );
}
/**
* Turns a ValidationErrors document into JSON.
*
* @param errors
* @return
*/
private Object constructErrorObject( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
if( !errors.hasFieldErrors() )
{
if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, errors.get( ValidationErrors.
GLOBAL_ERROR ).get( 0 ).getMessage( getContext().getLocale() ) );
}
}
else
{
for( ListValidationError list : errors.values() )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, list.get(0).getFieldName() + : +
list.get( 0 ).getMessage( getContext().getLocale() ) );
}
}
obj.put(status, 400);
return obj;
}
JSONResolution is a custom class which has this in its heart:
protected static ObjectMapper c_mapper = new ObjectMapper();
protected static ObjectMapper c_prettyMapper = new ObjectMapper();
static
{
c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT,
true );
}
@Override
public void execute( HttpServletRequest request, HttpServletResponse
response ) throws Exception
{
response.setStatus( m_status );
response.setContentType( m_contentType );
response.setCharacterEncoding( UTF-8 );
if( true.equals(request.getParameter( pretty )) )
c_prettyMapper.writeValue( response.getOutputStream(),
m_object );
else
c_mapper.writeValue( response.getOutputStream(), m_object );
response.getOutputStream().flush();
}
This btw lets you just get nice JSON back from any API call by adding
“pretty=true” to the request URL. This has proven to be invaluable while
debugging.
One important caveat is that to protect against CSRF attacks you will
want to make sure that every single one of your API endpoints handles GET
requests properly. Since Stripe does not really differentiate between GET
and POST, you might accidentally allow people to make changes to your DB
using a GET method. We just limit the allowable methods via an annotation
and an interceptor.
Stripe is OK for REST API development; more modern frameworks like
Dropwizard do make some things a bit easier though (btw, Dropwizard+Guice
has a lot of the same feel as Stripe for development - though Stripe’s
templating system is still pretty darned powerful and
Re: [Stripes-users] CMS Integration with Stripes
Hi, we've been in the same situation, and we've used the same double approach described by Remi: facing public, CMS-heavy sites using REST-like services provided by Stripes, whereas transactional applications are invoking CMS's services via its REST services. The only downside with this approach is that modern js frameworks are more prepared to use true/full/complete/you-name-it REST services (= a post on an URL is not the same as a GET), which is complex to achieve if using Stripes, as you'd have to make your ActionBeans aware of the http verb (maybe extending @URLBinding, @HandleEvent, etc. maybe with a new @Verb), and write your ActionBeanResolver, so it can understand all the previous. We felt we were going to modify too much Stripes internals, so we chose instead to make calls to some URLs managed by Stripes' apps which return some JSON. Btw, we'd love to hear if someone has tried any other approach to serve true REST services with Stripes. Lastly, another approach you could use is to try portofino ( http://portofino.manydesigns.com/). It has CMS capabilities, it's Stripes-based, has user/roles, different kind of support service. The downsides: it's not widely known (we came across it looking for a CRUD generator). Note that we haven't used it on any real project yet, so we don't really know how it behaves, you'll have to try it for yourself and see if it fits your needs. hth, juan pablo On Sat, Feb 28, 2015 at 12:36 PM, VANKEISBELCK Remi r...@rvkb.com wrote: Btw, I've done something similar on a small app : we allow the site owner to change some of the pages using MCE or something. We also allow to upload images and reference them in those pages. It does the job for us and for what it's cost, didn't take long to hack. But it's pretty ugly, and we quickly fell into pretty complex layout issues and the like. The regular html tags (and the WYSIWYG over them) ain't powerful as what you'll find in some CMSs with templating etc. In short, the home-brew solution works for very simple pages in terms of formatting, or maybe for only fragments of a page that is laid out by an actual web designer :) Cheers Rémi 2015-02-28 12:27 GMT+01:00 VANKEISBELCK Remi r...@rvkb.com: Hi, Interesting question :) I guess a fundamental indicator is the complexity of the CMS vs your own code. I mean, will the public facing website include only a small part of customization (a few new forms here and there, a few pages...) and most of the hits will be actually handled by the CMS ? Or is it the inverse ? Are your Stripes pages the main focus, and expose more features than the CMS ? Rewriting a full-blown CMS ain't easy, but I guess rewriting your app isn't either :P Apart from your 3 options, have you considered client-side, mashup-style integration ? I mean, I guess most of those CMSs provide ways to integrate 3rd party stuff within their UI, via plugins or the like. It depends on the architecture (authentication, cross-domain etc) but maybe you can integrate your heterogeneous apps via widgets that you put in your CMS and that access your Stripes services. I don't know Wordpress, but I'm pretty sure it has such capability. It certainly provides REST APIs that you can call from the browser in order to get the data you need from the CMS. Now you only need your Stripes app to do the same : expose REST-like services so that you can mix cross-apps widgets in the same page(s). Like display a GUI that is backed by a Stripes app inside a Wordpress page. Quick googling, and, as expected, it's plugin-based at its core : http://codex.wordpress.org/Writing_a_Plugin Ok, it's php, but it can definitely invoke your Stripes stuff, either directly from your Wordpress instance in php (server-to-server), or via Cross-Domain JS (browser-to-server). The second option involves only very little php : your plugin only has to include the JS you need from the Stripes app, and let it do the magic... You can also mix the two websites in some circumstances. Say you now have a Shop link in the CMS nav bar : this link can point to a Stripes app, provided you manage authentication. Tell us how it goes ! Cheers Rémi 2015-02-28 11:08 GMT+01:00 Paul Carter-Brown paul.carter-br...@smilecoms.com: Hi, We have been using Stripes for the last 5 years and love the framework. The sites we have used it on are all transactional (think CRM) with back-end integration to other systems for customer profile management, account management etc. We also have a fairly static public facing web site using wordpress CMS that was created by our marketing agency. We now have a need to add a lot more transactional functionality to the public facing site for customers to buy goods and services, manage their accounts etc and the marketing team want to keep their ability to manage and change content on the site as they see fit without code/JSP changes. We now have to make a call on these
Re: [Stripes-users] CMS Integration with Stripes
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but we
basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since this is
an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST, obj );
}
/**
* Turns a ValidationErrors document into JSON.
*
* @param errors
* @return
*/
private Object constructErrorObject( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
if( !errors.hasFieldErrors() )
{
if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, errors.get(
ValidationErrors.GLOBAL_ERROR ).get( 0 ).getMessage( getContext().getLocale() )
);
}
}
else
{
for( ListValidationError list : errors.values() )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, list.get(0).getFieldName() + : +
list.get( 0 ).getMessage( getContext().getLocale() ) );
}
}
obj.put(status, 400);
return obj;
}
JSONResolution is a custom class which has this in its heart:
protected static ObjectMapper c_mapper = new ObjectMapper();
protected static ObjectMapper c_prettyMapper = new ObjectMapper();
static
{
c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT, true );
}
@Override
public void execute( HttpServletRequest request, HttpServletResponse
response ) throws Exception
{
response.setStatus( m_status );
response.setContentType( m_contentType );
response.setCharacterEncoding( UTF-8 );
if( true.equals(request.getParameter( pretty )) )
c_prettyMapper.writeValue( response.getOutputStream(), m_object );
else
c_mapper.writeValue( response.getOutputStream(), m_object );
response.getOutputStream().flush();
}
This btw lets you just get nice JSON back from any API call by adding
“pretty=true” to the request URL. This has proven to be invaluable while
debugging.
One important caveat is that to protect against CSRF attacks you will want to
make sure that every single one of your API endpoints handles GET requests
properly. Since Stripe does not really differentiate between GET and POST, you
might accidentally allow people to make changes to your DB using a GET method.
We just limit the allowable methods via an annotation and an interceptor.
Stripe is OK for REST API development; more modern frameworks like Dropwizard
do make some things a bit easier though (btw, Dropwizard+Guice has a lot of the
same feel as Stripe for development - though Stripe’s templating system is
still pretty darned powerful and I haven’t really found an equivalent).
/Janne
On 28 Feb 2015, at 14:56 , Juan Pablo Santos Rodríguez
juanpablo.san...@gmail.com wrote:
Hi,
we've been in the same situation, and we've used the same double approach
described by Remi: facing public, CMS-heavy sites using REST-like services
provided by Stripes, whereas transactional applications are invoking CMS's
services via its REST services.
The only downside with this approach is that modern js frameworks are more
prepared to use true/full/complete/you-name-it REST services (= a post on an
URL is not the same as a GET), which is complex to achieve if using Stripes,
as you'd have to make your ActionBeans aware of the http verb (maybe
extending @URLBinding, @HandleEvent, etc. maybe with a new @Verb), and write
your ActionBeanResolver, so it can understand all the previous. We felt we
were going to modify too much Stripes internals, so we chose instead to make
calls to some URLs managed by Stripes' apps which return some JSON.
Btw, we'd love to hear if someone has tried any other approach to serve true
REST services with Stripes.
Lastly, another approach you could use is to try portofino
(http://portofino.manydesigns.com/ http://portofino.manydesigns.com/). It
has CMS capabilities, it's Stripes-based, has user/roles, different kind of
Re: [Stripes-users] CMS Integration with Stripes
Hi guys,
I also had similar issues writing REST services with Stripes. I absolutely
did not want to get rid of Stripes, so I had to write a REST ActionBean
framework for Stripes which supported all of Stripes validation and
binding. If you are interested, you can download it here:
https://github.com/rgrashel/stripes-rest
I can help anybody out with implementation of a REST service if they need
it. But for this library, full Stripes validation is supported. It uses
the same convention approach that Stripes uses, so you write get(),
post(), delete(), head(), put() methods and they will be automatically
called. It also uses Stripes' own internal Javascript builder and has a
new JsonResolution to create JSON-based responses.
Give it a look if you are interested. I have been using it in production
for quite awhile and it works well.
Thanks.
-- Rick
On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but we
basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since this
is an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST, obj
);
}
/**
* Turns a ValidationErrors document into JSON.
*
* @param errors
* @return
*/
private Object constructErrorObject( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
if( !errors.hasFieldErrors() )
{
if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, errors.get( ValidationErrors.
GLOBAL_ERROR ).get( 0 ).getMessage( getContext().getLocale() ) );
}
}
else
{
for( ListValidationError list : errors.values() )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, list.get(0).getFieldName() + : +
list.get( 0 ).getMessage( getContext().getLocale() ) );
}
}
obj.put(status, 400);
return obj;
}
JSONResolution is a custom class which has this in its heart:
protected static ObjectMapper c_mapper = new ObjectMapper();
protected static ObjectMapper c_prettyMapper = new ObjectMapper();
static
{
c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT, true
);
}
@Override
public void execute( HttpServletRequest request, HttpServletResponse
response ) throws Exception
{
response.setStatus( m_status );
response.setContentType( m_contentType );
response.setCharacterEncoding( UTF-8 );
if( true.equals(request.getParameter( pretty )) )
c_prettyMapper.writeValue( response.getOutputStream(),
m_object );
else
c_mapper.writeValue( response.getOutputStream(), m_object );
response.getOutputStream().flush();
}
This btw lets you just get nice JSON back from any API call by adding
“pretty=true” to the request URL. This has proven to be invaluable while
debugging.
One important caveat is that to protect against CSRF attacks you will want
to make sure that every single one of your API endpoints handles GET
requests properly. Since Stripe does not really differentiate between GET
and POST, you might accidentally allow people to make changes to your DB
using a GET method. We just limit the allowable methods via an annotation
and an interceptor.
Stripe is OK for REST API development; more modern frameworks like
Dropwizard do make some things a bit easier though (btw, Dropwizard+Guice
has a lot of the same feel as Stripe for development - though Stripe’s
templating system is still pretty darned powerful and I haven’t really
found an equivalent).
/Janne
On 28 Feb 2015, at 14:56 , Juan Pablo Santos Rodríguez
juanpablo.san...@gmail.com wrote:
Hi,
we've been in the same situation, and we've used the same double approach
described by Remi: facing public, CMS-heavy sites using REST-like services
provided by Stripes, whereas transactional applications are invoking CMS's
services via its REST services.
The only downside with this
Re: [Stripes-users] CMS Integration with Stripes
Absolutely, there are many ways to implement pure HTTP backends with
Stripes. The verbs are not mandatory, you can stick to GET and POST it
works just fine. I never understood why everyone went that crazy with PUT
and DELETE. I think that Stripes shines at HTTP services implementation
(binding etc).
Many people have baked their own framework for that and are happy with it.
In Woko (Stripes based, with 'RPC' support) you'd just do :
GET /view/Product/123?isRpc=true = JSON product
POST /save/Product/123?isRpc=trueobject.price=10 = updates product and
returns JSON
POST /delete/Product/123?isRpc=trueconfirm
and so forth... (remove the isRpc param, and you get the HTML version for
humans :P).
As for the client side, you can also provide a more explicit API that
encapsulates your HTTP calls, so that the user doesn't even know what's
going on under the hood :
myApiClient.loadProduct(123, function(p) { ... });
with :
myApiClient.loadProduct = function(id, callback) {
$.get('/product/123', function(p) {
callback.apply(this, [p]);
}
};
It's also a good place to factor out your client-side validation, error
handling code and other stuff.
HTH
Rémi
2015-02-28 15:13 GMT+01:00 Rick Grashel rgras...@gmail.com:
Hi guys,
I also had similar issues writing REST services with Stripes. I
absolutely did not want to get rid of Stripes, so I had to write a REST
ActionBean framework for Stripes which supported all of Stripes validation
and binding. If you are interested, you can download it here:
https://github.com/rgrashel/stripes-rest
I can help anybody out with implementation of a REST service if they need
it. But for this library, full Stripes validation is supported. It uses
the same convention approach that Stripes uses, so you write get(),
post(), delete(), head(), put() methods and they will be automatically
called. It also uses Stripes' own internal Javascript builder and has a
new JsonResolution to create JSON-based responses.
Give it a look if you are interested. I have been using it in production
for quite awhile and it works well.
Thanks.
-- Rick
On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
default:
return new ErrorResolution( … );
}
}
What’s a bit more difficult is to incorporate validation into this, but
we basically have a superclass which has something like this:
/**
* Normally Stripes turns validation errors into HTML, but since
this is an API,
* we turn it into JSON. Returns a JSON resolution with a single
* field error which then contains a number of errors.
*/
@Override
public Resolution handleValidationErrors( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
obj.put( error, constructErrorObject(errors) );
return new JSONResolution( HttpServletResponse.SC_BAD_REQUEST,
obj );
}
/**
* Turns a ValidationErrors document into JSON.
*
* @param errors
* @return
*/
private Object constructErrorObject( ValidationErrors errors )
{
JSONObject obj = new JSONObject();
if( !errors.hasFieldErrors() )
{
if( errors.containsKey( ValidationErrors.GLOBAL_ERROR ) )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, errors.get( ValidationErrors.
GLOBAL_ERROR ).get( 0 ).getMessage( getContext().getLocale() ) );
}
}
else
{
for( ListValidationError list : errors.values() )
{
obj.put( code, ERR_VALIDATION );
obj.put( description, list.get(0).getFieldName() + : +
list.get( 0 ).getMessage( getContext().getLocale() ) );
}
}
obj.put(status, 400);
return obj;
}
JSONResolution is a custom class which has this in its heart:
protected static ObjectMapper c_mapper = new ObjectMapper();
protected static ObjectMapper c_prettyMapper = new ObjectMapper();
static
{
c_prettyMapper.configure( SerializationFeature.INDENT_OUTPUT,
true );
}
@Override
public void execute( HttpServletRequest request, HttpServletResponse
response ) throws Exception
{
response.setStatus( m_status );
response.setContentType( m_contentType );
response.setCharacterEncoding( UTF-8 );
if( true.equals(request.getParameter( pretty )) )
c_prettyMapper.writeValue( response.getOutputStream(),
m_object );
else
c_mapper.writeValue( response.getOutputStream(), m_object );
response.getOutputStream().flush();
}
This btw lets
Re: [Stripes-users] CMS Integration with Stripes
Btw, I've done something similar on a small app : we allow the site owner to change some of the pages using MCE or something. We also allow to upload images and reference them in those pages. It does the job for us and for what it's cost, didn't take long to hack. But it's pretty ugly, and we quickly fell into pretty complex layout issues and the like. The regular html tags (and the WYSIWYG over them) ain't powerful as what you'll find in some CMSs with templating etc. In short, the home-brew solution works for very simple pages in terms of formatting, or maybe for only fragments of a page that is laid out by an actual web designer :) Cheers Rémi 2015-02-28 12:27 GMT+01:00 VANKEISBELCK Remi r...@rvkb.com: Hi, Interesting question :) I guess a fundamental indicator is the complexity of the CMS vs your own code. I mean, will the public facing website include only a small part of customization (a few new forms here and there, a few pages...) and most of the hits will be actually handled by the CMS ? Or is it the inverse ? Are your Stripes pages the main focus, and expose more features than the CMS ? Rewriting a full-blown CMS ain't easy, but I guess rewriting your app isn't either :P Apart from your 3 options, have you considered client-side, mashup-style integration ? I mean, I guess most of those CMSs provide ways to integrate 3rd party stuff within their UI, via plugins or the like. It depends on the architecture (authentication, cross-domain etc) but maybe you can integrate your heterogeneous apps via widgets that you put in your CMS and that access your Stripes services. I don't know Wordpress, but I'm pretty sure it has such capability. It certainly provides REST APIs that you can call from the browser in order to get the data you need from the CMS. Now you only need your Stripes app to do the same : expose REST-like services so that you can mix cross-apps widgets in the same page(s). Like display a GUI that is backed by a Stripes app inside a Wordpress page. Quick googling, and, as expected, it's plugin-based at its core : http://codex.wordpress.org/Writing_a_Plugin Ok, it's php, but it can definitely invoke your Stripes stuff, either directly from your Wordpress instance in php (server-to-server), or via Cross-Domain JS (browser-to-server). The second option involves only very little php : your plugin only has to include the JS you need from the Stripes app, and let it do the magic... You can also mix the two websites in some circumstances. Say you now have a Shop link in the CMS nav bar : this link can point to a Stripes app, provided you manage authentication. Tell us how it goes ! Cheers Rémi 2015-02-28 11:08 GMT+01:00 Paul Carter-Brown paul.carter-br...@smilecoms.com: Hi, We have been using Stripes for the last 5 years and love the framework. The sites we have used it on are all transactional (think CRM) with back-end integration to other systems for customer profile management, account management etc. We also have a fairly static public facing web site using wordpress CMS that was created by our marketing agency. We now have a need to add a lot more transactional functionality to the public facing site for customers to buy goods and services, manage their accounts etc and the marketing team want to keep their ability to manage and change content on the site as they see fit without code/JSP changes. We now have to make a call on these possible options: 1) Try and use PHP/Wordpress to do what we are so good at doing in Stripes. We are a Java shop and have lots of boiler plate code and framework around Stripes so thinking of now doing this all over again in PHP is scary 2) Use a completely new Java web framework with a CMS and then find a way of adding our back end integration etc into that web framework. Thinking here of things like Drupal, HippoCMS, dotCMS etc 3) Find a CMS with a tag library or similar that can be used on Stripes JSP's to pull in content served from the CMS to supplement whats being resented by the JSP. We then get to use Stripes and have all the integration done already (e.g. binding into domain models). We also get the benefit of giving marketing areas of the site where they are free to change images, text etc etc in a CMS with approval processes and ability to publish changes without any need for redeploys etc I really really want to find a good CMS for option (3). I'm sure my requirement is not unique (power of Stripes for transactional web sites but with a CMS for marketing to update parts of the site they control). Anyone out there with any suggestions? Thanks so much This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ http://www.smilecoms.com/disclaimer -- Dive into the World of Parallel Programming The Go Parallel Website,
Re: [Stripes-users] CMS Integration with Stripes
Hi, Interesting question :) I guess a fundamental indicator is the complexity of the CMS vs your own code. I mean, will the public facing website include only a small part of customization (a few new forms here and there, a few pages...) and most of the hits will be actually handled by the CMS ? Or is it the inverse ? Are your Stripes pages the main focus, and expose more features than the CMS ? Rewriting a full-blown CMS ain't easy, but I guess rewriting your app isn't either :P Apart from your 3 options, have you considered client-side, mashup-style integration ? I mean, I guess most of those CMSs provide ways to integrate 3rd party stuff within their UI, via plugins or the like. It depends on the architecture (authentication, cross-domain etc) but maybe you can integrate your heterogeneous apps via widgets that you put in your CMS and that access your Stripes services. I don't know Wordpress, but I'm pretty sure it has such capability. It certainly provides REST APIs that you can call from the browser in order to get the data you need from the CMS. Now you only need your Stripes app to do the same : expose REST-like services so that you can mix cross-apps widgets in the same page(s). Like display a GUI that is backed by a Stripes app inside a Wordpress page. Quick googling, and, as expected, it's plugin-based at its core : http://codex.wordpress.org/Writing_a_Plugin Ok, it's php, but it can definitely invoke your Stripes stuff, either directly from your Wordpress instance in php (server-to-server), or via Cross-Domain JS (browser-to-server). The second option involves only very little php : your plugin only has to include the JS you need from the Stripes app, and let it do the magic... You can also mix the two websites in some circumstances. Say you now have a Shop link in the CMS nav bar : this link can point to a Stripes app, provided you manage authentication. Tell us how it goes ! Cheers Rémi 2015-02-28 11:08 GMT+01:00 Paul Carter-Brown paul.carter-br...@smilecoms.com: Hi, We have been using Stripes for the last 5 years and love the framework. The sites we have used it on are all transactional (think CRM) with back-end integration to other systems for customer profile management, account management etc. We also have a fairly static public facing web site using wordpress CMS that was created by our marketing agency. We now have a need to add a lot more transactional functionality to the public facing site for customers to buy goods and services, manage their accounts etc and the marketing team want to keep their ability to manage and change content on the site as they see fit without code/JSP changes. We now have to make a call on these possible options: 1) Try and use PHP/Wordpress to do what we are so good at doing in Stripes. We are a Java shop and have lots of boiler plate code and framework around Stripes so thinking of now doing this all over again in PHP is scary 2) Use a completely new Java web framework with a CMS and then find a way of adding our back end integration etc into that web framework. Thinking here of things like Drupal, HippoCMS, dotCMS etc 3) Find a CMS with a tag library or similar that can be used on Stripes JSP's to pull in content served from the CMS to supplement whats being resented by the JSP. We then get to use Stripes and have all the integration done already (e.g. binding into domain models). We also get the benefit of giving marketing areas of the site where they are free to change images, text etc etc in a CMS with approval processes and ability to publish changes without any need for redeploys etc I really really want to find a good CMS for option (3). I'm sure my requirement is not unique (power of Stripes for transactional web sites but with a CMS for marketing to update parts of the site they control). Anyone out there with any suggestions? Thanks so much This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ http://www.smilecoms.com/disclaimer -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from
