generally speaking, there can be a few independent but overlapping mechanism that will control who is allowed to do what with content:
1. any subject's access to the content itself can be controlled via authorization rules (ie. required vs granted permissions) enforced via system-wide resource-based access control
2. content licensors (~content owners) can restrict the usage of their content by:
* whom - ie. content licensee (legally/commercially represented by an organization)
* how - eg. reuse as unmodified, create derivatives, composite, redistribute, etc
* where - ie. distribution channels their content can be used (eg. only on hotel's vbrochure site, but not in any ids/gds channels)
* when - temporal restrictions may limit scope of content license grant by: start, end, duration, season, etc
3. content licensees can further filter or funnel content available to them (resulting from a combination of license granted to them and access control) based on their own criteria (eg. generate a templated hotel presentation only if: at least 1 textual description, 5 photos and 1 video for a hotel is available with a license to combine them (composite content)
if ecm/vfml is to manage content licensing as a third party between organizations (content licensors & licensees) shouldn't ecm *know* if the user('s organization) has rights to use the content in question?
is this question posed to the user (with required explicit acknowledgement) purely to absolve vfml from liability issues that may result from licensing disagreements?
this being the user's (organization's) 'version'or 'view'of the hotel, since this user normally wouldn't/shouldn't be granted permissions to replace content for a hotel on a different organization's 'view'or 'version' of the same hotel
this implies that *at least* one version of such (temporarily) replaceable content needs to be managed/maintaned to allow reverting
what if, deliberately, ignorantly or maliciously, a user replaces the same piece of--textual or any type, really--content for this hotel n times? will all n versions be required to be managed as an undo history?
the user's ''original content'' might have been version 1, but equally might have been 1 mean:
- previous version of the content, regardless of which user
- initial version of that content attached to the hotel regardless of which user created/updated it and ignoring which organization owns it?, or,
-
inner class Builder is in charge of creating Customer instances
mandatory fields – either primitive (e.g. id) or annotated with @NotNull (e.g. lastName) – are part of the builder's constructor
all optional fields setter methods on the builder are provided
newly created Customer instance is validated using the Validator#validate() method
impossible to retrieve an invalid Customer instance
extract the validation routine into a base class:
abstract class AbstractBuilder<T>
T build() throws ConstraintViolationException
protected abstract T buildInternal();
private static Validator validator
Concrete builder classes have to
extend AbstractBuilder
must implement the buildInternal() method:
Builder extends AbstractBuilder<Customer>
@Override
protected Customer buildInternal()
Implementing the Builder Pattern using the Bean Validation API
variation of the Builder design pattern for instantiating objects with multiple optional attributes.
this pattern frees you from providing multiple constructors with the different optional attributes as parameters (hard to maintain and hard to read for clients)
or providing setter methods for the optional attributes
(require objects to be mutable, can leave objects in inconsistent state)
Especially in the context of pagination, where the data is mostly retrieved for read-only purposes, database views are the easier and more efficient alternative. Instead of implementing a lot of plumbing on the “Java-side” all the work could be easily done in the database
GraniteDS have added support for Bean Validation into their project and hence Bean Validation is usable by all Flex users
Because they do not run on the JVM, they basically have reimplemented the full specification in Flex:
you can annotate your ActionScript3 objects with constraints: it supports all the standard constraints and you can write your own constraints
you can execute the validation logic and retrieve the error report
you can make use of most of the feature including advanced ones like groups, group sequence etc
for GraniteDS users keeping their Java domain model and ActionScript3 domain model in sync via Gas3, the constraints are kept in sync
a couple of gotchas to be aware of
the constraint implementation is in the same class as the constraint declaration (not a problem in a dynamic language)
@Pattern has a sightly different semantic because the regexp engine in Flex is a bit different.
instead of the features provided by ConstraintValidatorContext, you can define a properties attribute in your constraints to make it belong to several sub-properties. not as flexible but good enough in many cases.