I had assumed that you have an exporter associated with your resource
type, but it seems you do not, and that is the issue.To understand this
better, please refer to:
is also an excellent resource on how to build exporters with
I'm not sure this is actually related to the SPA editor, it could be a
number of things.To make this easier for us to debug and help. could you
create a simple empty component, maybe in we-retail project, with a
sample dialog that does not provide you the desired model.json output,
then package that component?We can then install that sample component
and play with it locally to determine the issue you are seeing.Thanks!
This is an interesting topic, I have not implemented a solution for
this, but if I did, here are my 2 cents:Some assumptions to start
with:1. The JSON structure is the same for every instance of your
component that's already authored2. You already use a Sling Model or Use
class to get data from JSONMy suggested solution:1. Rewrite your dialog
to use CoralUI3 multifield2. Rewrite the backing Sling model/Use class
to use the nodestore instead of JSON. You should NOT need to change the
yes, of course, minutes are acceptable. I think Akamai's is 5 minutes or
something close to that. But that is significantly lower than 30 minutes
or an hour. and would allow clients to have much longer TTLs.
Ah ok. Yeah, I agree with you on that. But it's hard to get a client to
adopt that. Clients typically want an instantaneous experience and want
their content live, as soon as they hit publish. Which is not a bad
expectation, if the code and APIs support it without complications.
Thanks for the insights!
@Jörg, I am no Akamai expert, but I assume what you mean is that cached
pages in Akamai will only be refreshed from origin after the TTL has
elapsed, correct? so if you have a long TTL, say an hour, this means
there will be at most one hour where there are stale pages?
I ran into the same issue. in order to resolve Tags, they must exists
under `/content/cq:tags/your/tag` or `/etc/tags` (legacy).The
Page#getTags implementation makes a call to TagManager#getTags which in
turn tries to resolve the actual tag resource in the repo. Since you are
testing in an AEM context, you have to load these tags in the
appropriate location for the MockTagManager to resolve them.What this
means is that you need to load your tags into the AEM test context just
like you've loaded ...
oh, I see it now, it's a little button with a "cog" icon on the top
right corner of
Still my concern remains.. it is not documented.
kautuksahniSo I'm looking at the documentation for creating Experience
Fragments And I want to create a fragment from a custom template; the
same way the we-retail sample project does.So I go about creating a
template, they try to create my fragment from that template only to find
that my template does not show up as one of the options... ok.. I look
into how we-retail did it and I copy the web variation template to my
own directory under /conf.. still not working..At this point, I do a