Major problems preventing Content Apps from being JCR-agnostic
- Action Executor API. We don't debate whether
ActionExecutor
should or should not be responsible for primary action availability checking , but it shouldn't do it _exclusively_ forjavax.jcr.Items
.- Should work over Vaadin Items. Being used in both Browser and Detail sub-apps of Content App it is probably the most severe blocker for the task.
- Availability rules are all affected, but easy to fix, because those that depend on JCR can simply cast to
JcrItemAdapter
/JcrNodeAdapter
. - Still not quite clear what to do with JCR logic inside AbstractActionExecutor itself.
- Serialization/de-serialization of item ids in to strings (basically - URL fragments).
The snippets like the one below are not only JCR-dependent, but also cluttered and hard to understand. What is more - the similar pieces of code are common on all the levels of Content App presenters, sometimes maybe even not once.
URL Fragment to Item Id Transformation in Browser Sub-AppString itemId = null; try { itemId = JcrItemUtil.getItemId(SessionUtil.getNode(workspaceName, path)); // item might have not been found if path doesn't exist if (itemId == null) { itemId = JcrItemUtil.getItemId(SessionUtil.getNode(workspaceName, workbenchRoot)); BrowserLocation newLocation = getCurrentLocation(); newLocation.updateNodePath("/"); getAppContext().updateSubAppLocation(getSubAppContext(), newLocation); } } catch (RepositoryException e) { log.warn("Could not retrieve item at path {} in workspace {}", path, workspaceName); }
Instead we could simply always delegate fragment to id translation (and vice versa) to the component which is specialised on that.
How the same logic should be probably doneObject actualItemId = dataSourceManager.deserializeItemId(urlFragmentPath); // item might have not been found if path doesn't exist if (dataSourceManager.itemExists(actualItemId)) { actualItemId = dataSourceManager.getRootItemId(); BrowserLocation newLocation = getCurrentLocation(); newLocation.updateNodePath("/"); getAppContext().updateSubAppLocation(getSubAppContext(), newLocation); } return actualItemId;
- Mixed signatures of methods in Content App related presenters and events
- Some operate over Vaadin Items, some - over the
JcrItemAdapters
, some, like aforementioned, - over JCR Items themselves. It sometimes leads to ItemId <-> Item conversion several times during delegation.- As a solution - only Item Ids should be used as a transferable during components/apps/sub-apps communication.
- Only workbench knows how to transform Item Id into a Vaadin Item. Ideally - that should be a job of a separate datasource manager component as such functionality is need in various places (e.g. Detail Sub-apps).
- Strings as Item ids everywhere - Object should be used instead ().
- Some operate over Vaadin Items, some - over the
Overview
Content Tools