dumbed down, feature parity implementation is just a list of idss allowed distribution (i believe)
use existing legacy infrastructure?
ultimate syndication system will depend on:
- licensing
- explicit list of syndication channels (much like legacy)
- rule-based routing
this is one (simple) example of rule-based syndication:
rule type: temporal (which could include: time range, recurrence, end time, etc)
rule: syndicate while startDate>=now() and endDate<=now()
not only new ecm users, but legacy viewers as well
ie. content uploaded via ecm must be available for display in legacy viewers, at least until legacy system is replaced and shutdown for good
is this the original name of the file that was uploaded?
if not, and it supposed to be the medlib file name, imho, should not be exposed. the medlib file name should be immaterial to the ecm user and generally, vfml should treat them as opaque to allow future changes without customer dependencies
the only time an ecm user should care about a 'file name' is when they're uploading or downloading.
but...
once the file is uploaded, who cares what the original file name was? it will be recorded, but should be inconsequential to anything since it would never, ever be referred to again
on download, (save as...) the original file name *could* be used, but any file name is just as good, since the downloader would also be given the option to rename the file
Granite Data Services provides a messaging feature, code name Gravity, implemented as a
Comet-like service with AMF3 data polling over HTTP
(producer/consumer based architecture)
GraniteDS messaging relies on two main AS3 components on the Flex side: org.granite.gravity.Consumer
and org.granite.gravity.Producer
6.3. Common Configuration
There are three main steps to configure Gravity in an application:
Declare the Gravity servlet implementation for your target server in web.xml
Declare a messaging service and destination in services-config.xml, mapped to a specific channel
definition of type GravityChannel
instead of, say, attaching validation 'behavior' directly on, but still decoupled from domain classes themselves (eg. validation rule annotations on jpa entity beans)
Modes define what SQL syntax MySQL should support and what kind of
data validation checks it should perform
Server SQL Modes
When working with InnoDB tables using the
InnoDB Plugin, consider also the
innodb_strict_mode configuration
option. It enables additional error checks for
InnoDB tables, as listed in
InnoDB Strict Mode
An implementation of this interface must be thread safe
If authorization fails, either because the user is not logged in or because it doesn't have required rights, it must throw an appropriate
org.granite.messaging.service.security.SecurityServiceException.
Writing a Security Service
SecurityService interface
nothing to do with a true Flex destination
only one instance of this service is used in the entire web-app
and will be called by concurrent threads
configure
login
This method is called upon each and every service method call invocations (RemoteObject)
or subscribe/publish actions (Consumer/Producer). When used with RemoteObjects,
the authorize method is responsible for checking security, calling the service method, and returning the corresponding result.
authorize
logout
handleSecurityException
default implementation of this method in AbstractSecurityService is to do nothing
security services
are not exposed to outside calls
"Bean Validation" specification (aka JSR-303) standardizes an annotation-based validation framework for Java
Flex doesn't provide by itself such framework. The standard way of processing validation is to use Validator subclasses and to bind each validator to each user input (see Validating data). This method is at least time consuming for the developer, source of inconsistancies between the client-side and the server-side validation processes, and source of redundancies in your MXML code.
GraniteDS introduces an ActionsScript3 implementation of the Bean Validation specification and provides code generation tools integration so that your Java constraint annotations are reproduced in your AS3 beans
GraniteDS validation framework provides a set of standard constraints
Constraint
Description
AssertFalse
The annotated element must be false
AssertTrue
The annotated element must be true
DecimalMax
The annotated element must be a number whose value must be lower or equal to the specified maximum
DecimalMin
The annotated element must be a number whose value must be greater or equal to the specified minimum
Digits
The annotated element must be a number whithin accepted range
Future
The annotated element must be a date in the future
Max
The annotated element must be a number whose value must be lower or equal to the specified maximum
Min
The annotated element must be a number whose value must be greater or equal to the specified minimum
NotNull
The annotated element must not be null
Null
The annotated element must be null
Past
The annotated element must be a date in the past
Pattern
The annotated String must match the supplied regular expression
Size
The annotated element size must be between the specified boundaries (included)
Constraint annotations must be placed on public properties, either public variables or public accessors