- availability depends on JCR Item
- OpenCreateDialogAction creates JcrNewNodeAdapter
- OpenEditDialogAction, SaveDialogAction all deal with JcrAdapter
- SaveDialogAction relies on adapter applying its own changes
- Requires a generic hook for saving?
- JcrSaveAction implicitly configured for all forms?
- Actions on items from external data sources require their own actions
- default set of actions with a different implementation catalogs?
- configure save action on openDialog/Form action
- should not perform JCR operations
- should be stupid readonly representations of JCR Item as Vaadin Item
- BasicTransformer (root impl of all) relies on DefaultPropertyUtil, that is implicitely on JCR propertyTypes
- As is, all containers should be replaced for all content views
- Consider getting workbench unified container onboard so that users don't need to configure n containers
- Or chances are that they would be smarter than us and use a single one, configured in multiple locations
- Components / Presenters
- Workbench / BrowserSubApp / ContentPresenters / Events
SubApp / JCR split
See the child page referenced below for the details of prototyping/research made in order to estimate/clarify the effort of making content apps JCR agnostic.
Meeting notes 2014.03.04
- ContentConnector gets green light
- Events, JcrItemId get green light
- ContentPresenters are OK with minimal changes
- ImageProvider is OK with minimal changes
Action availability is critical
- No definition should perform business logic
- We need to be very careful about using Voters
- We need to guarantee permissions are generally set the same way for apps, app groups, actions, etc.
- We may well differentiate permission availability from UI state based availability
- DetailSubApp needs more understanding
- Actions with specific set of parameters
- Transformers, Fields
- we should guarantee detail view works for basic fields (text, checkbox)
- we may try plugin in a SQL database although practically it would be very similar to the filesystem app use case.