Thanks, but I am familiar with setting the cq:layout to editbar. My
question is specifically about setting the layout to auto. The
documentation describes auto as "The choice is left to the client side
code". I interpret this as meaning that the choice between editbar and
rollover is made at page render time, determined by some client code
documentation for the "client code" that would dictate which layout to
use.EDIT: you beat me ...
I would like to use cq:layout="auto" in my component's edit config.
documentation states that auto allows the client code to determine if it
should be editbar or rollover, but I can't find any documentation or
literature on how to achieve this. Could anybody provide sample code or
links to help? Thanks!
Hello,We have implemented a custom workflow process step to perform an
operation against an integration. The particulars aren't
important.Currently, if an error occurs when we call the integration, we
throw a workflow exception. This causes the step to be retried (10
attempts), after which the workflow is halted and a the exception is
sent to the AEM inbox (/inbox) as a FailureItem.We wish to change this
behaviour so that the process step is tried only once. We wish to make
it a graceful failure...
Thank you again, Kunal. I had already searched for the source of
SlingRequestProcessorImpl for setStatus, and found none; I did, however,
overlook the calls to sendError, which I suppose my wrapper also needs
to implement, in order to set status code. Once again, thank you.
kunal23 wrote... I guess you used the RequestResponseFactory service to
get the dummy request, response objects for sending a request to the
SlingRequestProcessor. The request, response objects this service
creates are just mock objects and they do not have any implementation of
setStatus and getStatus methods. To get the status of the response you
can create your own response class implementing the HTTPServletResponse
interface. In the setStatus method you can set the value passed in the
Happy to help. I've seen several other individuals trip over this before
as well. I'm not sure how it is that the problem is so common, as it
seems to require that a user delete/renames a node that they should not,
but it does seem to happen alarmingly frequently. I'd love to see Adobe
make the Projects and Site Admin interfaces more durable, so they don't
just fail silently under these conditions.