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.
> *
> * @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( List<ValidationError> 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/). 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
>>>> 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 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 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 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 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
