In the mean time, we implemented new Core Components which have this
capabilityTabsCarouselI would strongly recommend you to take a look at
those, and reuse as-is if possible. Otherwise, we're happy to get your
feedback through creating issue(s) under adobe/aem-core-wcm-components
Github project.The pattern for achieving such a task (select a
non-visible tab/panel and edit) is reusable.
Unfortunately, I think that's a limitation of the 6.1 extension point,
as written on the documentation page:This feature is optimized for
columns of text fields; for other data types it is possible to overlay
cq/gui/components/siteadmin/admin/listview/columns/analyticscolumnrenderer
in /apps.
Hi,I'm wondering if I missed something from the discussion.What behavior
are we talking about?The message is very general, I'd like to understand
in detail what's happening.
I wouldn't add the ACL on that button itself, but use a render condition
like the one in the code
sample:https://github.com/Adobe-Marketing-Cloud/aem-admin-extension-customize-sites/tree/master/src/main/content/jcr_root/apps/myapp/components/renderconditions/grouphttps://github.com/Adobe-Marketing-Cloud/aem-admin-extension-customize-sites/blob/master/src/main/content/jcr_root/apps/wcm/core/content/sites/.content.xml#L48-L52Put
such a config as a "rendercondition" child node of your button.
Your assumption is correct, and this is also documented.Reason for that
choice was not to interfere with the customer page's DOM anymore, like
it was done in Classic UI. I agree his also has the drawback you
mentioned.In 6.1, we're introducing a keyboard shortcut to easily switch
between the current editing mode (edit, target, etc.) and preview, and
the layout of the header bar is also allowing to save one click, since
the preview option is no more under the menu.Regarding 6.0, you
mention:For e...
Unfortunately, this isn't possible yet, unless you overlay the whole
component.This is a known limitation and will be addressed in AEM 6.2 -
for now, I'd recommend you to add the action to the headerbar using the
corresponding extension point. However, there's an issue with this
extension point in AEM 6.1 GA, internally tracked by CQ-42843. We'll
provide a publicly available fix for it in August through a
Touch-optimized UI Update Package.
Note this is also documented in the AEM documentation, with pointers to
the Github
samples:http://docs.adobe.com/docs/en/aem/6-0/develop/extending/customizing-page-authoring-touch.htmlhttp://docs.adobe.com/docs/en/aem/6-0/develop/extending/customizing-consoles-touch.html
Hi Abhinav,1. Instead of reacting on submit of the dialog box, you
should listen to "dialog-success" event. This works both for Touch UI
dialogs and the ones loaded using classic dialogs within the new page
authoring.2. I'd say that's an expected behaviour. Wasn't this already
the case in Classic UI?Regards,Gilles
Hi Abhinav,Could you elaborate on which listener is not working? Is it
something like "REFRESH_PAGE", etc.?There would be a "number input"
field (sling:resourceType =
granite/ui/components/foundation/form/numberfield)That's true, this is
not possible yet to drag from the side panel into the dialog. But you
can drag on the component itself (without opening the dialog) - for
instance foundation image component.Hope this helps.Regards,Gilles
