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
but don’t know how those dependencies are instantiated
And you shouldn’t really care, all that is important is that UserService depends on dao and webservice object.
BDD template given-when-then) tests are easy to read
@Entity
public class User
calling new User(“someName”,”somePassowrd”, “someOtherName”, “someOtherPassword”) becomes hardly readable and maintainable
code duplication
Maintaining this code would turn into a nightmare in no time
running the code above will throw an exception by the JPA provider,
since not-nullable password field was never set.
Joshua Blooch gives fine example of builder pattern.
Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object. Then the client calls setter-like methods on the builder object to set each optional parameter of interest. Finally, the client calls a parameterless build method to generate the object, which is immutable. The builder is a static member class of the class it builds.
Coffee
public static class Builder
Builder(CoffeeType type, int cupSize)
Builder withMilk()
Coffee build()
Coffee(this)
private Coffee(Builder builder)
Coffee coffee = new Coffee.Builder(CoffeeType.Expresso, 3).withMilk().build();2}
especially if most of those parameters are optional.
For all entity attributes I create private fields
those that are obligatory become parameters for the public constructor
parameter-less constructor, I create one, but I give him
List becomes ArrayList
SortedSet becomes TreeSet
Set becomes HashSet
Collection becomes ArrayList
Array (sparse)
java.util.Map
java.util.Map
java.util.Map
If a Map interface is specified, creates a new java.util.HashMap for java.util.Map and a new java.util.TreeMap for java.util.SortedMap.
BlazeDS passes an instance of java.util.ArrayList to parameters typed with the java.util.List interface and any other interface that extends java.util.Collection. Then these types are
sent back to the client as mx.collections.ArrayCollection instances
If you require normal ActionScript Arrays sent back to the client, you must set the legacy-collection element to true in the serialization section of a channel-definition's properties; for more information, see Configuring AMF serialization on a channel.
legacy-collection
Default value is false. When true, instances of
java.util.Collection
are returned as
ActionScript Arrays
legacy-map
Default value is false. When true, java.util.Map instances are serialized as an ECMA Array or associative array instead of an anonymous Object.
A typical reason to use custom serialization is to avoid passing all of the properties of either the client-side or server-side representation of an object across the network tier.
standard serialization scheme, all public properties are passed back and forth between the client and the server.
Explicitly mapping ActionScript and Java objects
Private properties, constants, static properties, and read-only properties, and so on, are not serialized
Updated Groovy template for GraniteDS Builder (gas3)
also stripped out the specialized GraniteDS datatypes in favor of the LCDS serialization convention that Adobe uses (i.e. a Java map should translate to an 'Object' type, a Java enum should translate to a 'String', and Java collections should always serialize as 'ArrayCollection')
didn't do a 'base' version and a version that doesnt get touched by the code generator, but you could easily do so by modifying this template
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