Skip to main content

Home/ SoftwareEngineering/ Group items tagged generation

Rss Feed Group items tagged

kuni katsuya

3. Gas3 Template Language - Confluence - 0 views

kuni katsuya

GraniteDS: Gas3 template for complex enums | Javalobby - 0 views

  • GraniteDS: Gas3 template for complex enums
  • changed enum.gsp from class:org/granite/generator/template/enum.gsp
  • I posted  a new version on github (master-branch) that
  • ...3 more annotations...
  • works with GraniteDS 3.0.0. 
  • https://github.com/graniteds/graniteds_builder 
  • fixed and committed to github
kuni katsuya

jsonschema2pojo - 0 views

  • Generate Plain Old Java Objects from JSON or JSON-Schema.
kuni katsuya

Access Tokens and Types - Facebook Developers - 0 views

  • Access Tokens and Types
  • Access Tokens
  • random string that provides temporary, secure access to Facebook APIs
  • ...27 more annotations...
  • token identifies a User, App or Page session and provides information about granted permissions
  • Types
  • User Access
  • generated in the login flow when a
  • Facebook Pages
  • on behalf of a user
  • use this token to perform API calls
  • Page Access
  • used to
  • manage
  • user grants permissions to an app
  • user who is the
  • App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app
  • must grant an extended permission called
  • manage_pages
  • use this type of token to make API calls
  • on behalf of a page
  • unique to each page, admin and app
  • App Access
  • useful to modify app settings, create and manage test users or read App Insights data
  • use app tokens to publish or delete content
  • on behalf of a user
  • unique to each app
  • Security Best Practices
  • extremely important that an App Secret is not compromised
  • Page admin
  • App Access Tokens should only be used directly from your app's servers in order to provide the best security
kuni katsuya

agorava/agorava-core · GitHub - 0 views

  • agorava / agorava-core
  • Agorava Core
  • CDI Beans and extensions to interact with major social media (SM)
  • ...6 more annotations...
  • SN independent services like
  • OAuth connectors
  • generic Authentication and user profile
  • portable between Java EE 6
  • independent of CDI implementation
  • build on top of scribe-java
kuni katsuya

TH03-EP01-US001 - Media Management, Media Upload, Media Item Fields (Groomed BE21, FE8)... - 0 views

  • Media Management,
  • upload a new media item
  • syndication and encoding - not part of this user story
  • ...26 more annotations...
  • definition
    • kuni katsuya
       
      ie. attach the following metadata to the uploaded media item
  • Owner
  • Rights of owner
    • kuni katsuya
       
      dependent on implementation of licensing/rights management system which is tbd, so these will be best guess stubs for now
  • Rights expiry date
    • kuni katsuya
       
      dependent on implementation of licensing/rights management system which is tbd, so these will be best guess stubs for now
  • Syndication
    • kuni katsuya
       
      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
  • Caption
  • Category
    • kuni katsuya
       
      ota category assumed
  • Seasonality display rules
    • kuni katsuya
       
      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()
  • Short description
  • Long description
  • Search keywords
  • Associated with
    • kuni katsuya
       
      huh?
  • in the media library
  • can be viewed by users
    • kuni katsuya
       
      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
  • Uploaded by
  • Date uploaded
  • Date modified
  • Last modified by
  • Status
    • kuni katsuya
       
      TO DO: for new domain model, should define explicit content life cycle with state diagram
  • File type
  • Media type
  • Dimensions
  • Aspect ratio
    • kuni katsuya
       
      aspect ratio doesn't need to be stored in db as metadata, since it can be calculated cheaply based on the dimensions
  • File size
    • kuni katsuya
       
      units: bytes
  • File name
    • kuni katsuya
       
      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
  • Media units consumed
    • kuni katsuya
       
      calculated/cached value pull from legacy system in future sprints, could start to build phased shell of the marketing xxx system 1. getMediaUnits()
    • kuni katsuya
       
      TODO: confirm with david and/or henry.wu where/how to obtain 'media units consumed' for a media item
kuni katsuya

Chapter 2. Mapping Entities - 0 views

  • 2.2.3.&nbsp;Mapping identifier properties
  • @Id annotation lets you define which property is the identifier of your entity
  • can be set by the application itself
  • ...1 more annotation...
  • or be generated by Hibernate (preferred)
kuni katsuya

A proper way for JPA entities instantiation « Paul Szulc's Blog - 0 views

  • A proper way for JPA entities&nbsp;instantiation
  • creating the entities I would like to focus in this post
  • JPA2.0 entities
  • ...31 more annotations...
  • UserService
  • UserDao
  • FacebookWS
  • User u
  • UserService uses UserDAO and FacebookWS
  • 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
  • protected access level
  • protected
kuni katsuya

Java Persistence/Mapping - Wikibooks, open books for an open world - 0 views

  • Access Type
  • field
  • get method
  • ...21 more annotations...
  • FIELD
  • PROPERTY
  • Either all annotations must be on the fields, or all annotations on the get methods, but not both (unless the @AccessType annotation is used)
  • if placed on a get method, then the class is using PROPERTY access
  • For FIELD access the class field value will be accessed directly to store and load the value from the database
  • field can be private or any other access type
  • FIELD is normally safer, as it avoids any unwanted side-affect code that may occur in the application get/set methods
  • For PROPERTY access the class get and set methods will be used to store and load the value from the database
  • PROPERTY has the advantage of allowing the application to perform conversion of the database value when storing it in the object
  • be careful to not put any side-affects in the get/set methods that could interfere with persistence
  • Common Problems
  • Odd behavior
  • One common issue that can cause odd behavior is
  • using property access and putting side effects in your get or set methods
  • For this reason it is generally recommended to
  • use field access in mapping, i.e. putting your annotations on your variables not your get methods
  • causing duplicate inserts, missed updates, or a corrupt object model
  • if you are going to use property access, ensure your property methods are free of side effects
  • Access Type
  • Access Type
  • Access Type
  •  
    "Access Type"
kuni katsuya

BlazeDS Developer Guide - 0 views

  • Serializing between ActionScript and Java
  • java.util.Date (formatted for Coordinated Universal Time (UTC))
  • java.util.Date, java.util.Calendar, java.sql.Timestamp, java.sql.Time, java.sql.Date
  • ...19 more annotations...
  • Object (generic)
  • java.util.Map
  • Array (dense)
  • java.util.List
  • 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
kuni katsuya

Google Groups - 0 views

  • new ArrayCollection();
  • new ArrayCollection();
  • new ArrayCollection();
  • ...6 more annotations...
  • new ArrayCollection();
  • new ArrayCollection();
  • You cannot serialize ListCollectionView instances directly. Use ArrayCollection instead in your constructor :
  • new ArrayCollection();
  • ListCollectionView to List&lt;E&gt; conversion
  • send a ListCollectionView object to a java method that accepts a java.util.List, I get a NoSuchMethodException.
kuni katsuya

Adobe Community: Updated Groovy template for GraniteDS Builder (gas3) - 0 views

  • 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
  • ...3 more annotations...
  • two versions
  • for Managed entities:
  • meant for non managed entities:
kuni katsuya

Java Persistence/ManyToMany - Wikibooks, open books for an open world - 0 views

  • Bi-directional Many to Many
  • object model can choose if it will be mapped in both directions
  • in which direction it will be mapped
  • ...9 more annotations...
  • one direction must be defined as the owner and the other must use the mappedBy attribute to define its mapping
  • you will end up getting duplicate rows
  • If the mappedBy is not used, then the persistence provider will assume there are two independent relationships
  • As with all bi-directional relationships it is your object model's and application's responsibility to maintain the relationship in both direction
  • Mapping a Join Table with Additional Columns
  • solution is to create a class that models the join table
  • requires a composite primary key
  • To make your life simpler, I would recommend adding a generated Id attribute to the association class
  • Another usage is if you have a Map relationship between two objects, with a third unrelated object or data representing the Map key
    • kuni katsuya
       
      eg. map key = AuthorizationContext, map value = {Subject,Role}
kuni katsuya

Java Persistence/Relationships - Wikibooks, open books for an open world - 0 views

  • Map Key Columns (JPA 2.0)
  • Nested Collections, Maps and Matrices
  • List of Lists
  • ...58 more annotations...
  • Map of Maps,
  • Map of Lists
  • JPA does not support nested collection relationships
  • One solution is to create an object that wraps the nested collection.
  • Map&lt;String, List&lt;Project&gt;&gt;
  • Example nested collection model (original)
  • Example nested collection model (modified)
  • Map&lt;String, ProjectType&gt;
  • @MapKey(name="type")
  • mappedBy="employee"
  • employee
  • type;
  • List&lt;Project&gt;
  • ProjectType
    • kuni katsuya
       
      ProjectType wraps the original map value type List>
  • Maps J
  • JPA allows a Map to be used for any collection mapping including, OneToMany, ManyToMany and ElementCollection
  • @MapKey annotation
  • used to define a map relationship
  • @MapKey(name="type")
  • Map&lt;String, PhoneNumber&gt;
  • type;
  • mappedBy="owner"
  • owner
  • Map Key Columns (JPA 2.0)
  • Map Key Columns (JPA 2.0)
  • JPA 2.0 allows for a Map where the key is not part of the target object to be persisted. The Map key can be any of the following:
  • A Basic value, stored in the target's table or join table.
  • An Embedded object, stored in the target's table or join table.
  • A foreign key to another Entity, stored in the target's table or join table.
  • if the value is a Basic but the key is an Entity a
  • ElementCollection
  • mapping is used.
  • if the key is a Basic but the value is an Entity a
  • OneToMany
  • mapping is still used
  • a three way join table, can be mapped using a
  • ManyToMany with a MapKeyJoinColumn for the third foreign key
  • @MapKeyJoinColumn
  • used to define a map relationship where the
  • key is an Entity value
  • can also be used with this for composite foreign keys
  • @MapKeyClass
  • can be used when the key is an Embeddable
  • if generics are not used
  • @MapKeyColumn
  • Map&lt;String, Phone&gt;
  • mappedBy="owner"
  • owner
  • @MapKeyJoinColumn
  • PHONE_TYPE_ID
  • PHONE_TYPE_ID
  • Map&lt;PhoneType, Phone&gt;
  • mappedBy="owner"
  • owner
  • @MapKeyClass(PhoneType.class)
  • @Embeddable
  • PhoneType
  • Map&lt;PhoneType, Phone&gt;
  •  
    "Map Key Columns (JPA 2.0)"
kuni katsuya

Chapter 11. Client-Side Validation API (JSR 303) - 0 views

  • Client-Side Validation API (JSR 303)
  • 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
« First ‹ Previous 41 - 60 of 86 Next › Last »
Showing 20 items per page