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
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();
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:
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
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
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
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 ?
