Sites

Favorite-off Notification-off
17 Thumb-up Thumb-down
Idea by bradley.wagner about 1 year ago Favorite-off - Completed

A Site is a formal collection assets that includes:


- own set of Page Configuration Sets, Content Types, Metadata Sets, Asset Factories, Data Definitions, Publish Sets, Workflow Definitions
- NO targets, but a collection of destinations to which assets publish
- users/groups members of the Site

Sites will allow for:
- Roles that are local to that site

Target properties that will be moved:
- Serialization Type (to the Page Configuration)
- Output Extension (to the Page Configuration)
- CSS Classes/File (to the Site)

8 comments

  • 1 point Thumb-up Thumb-down Favorite-off by clindahl about 1 year ago Permalink
    Yes! This is increasingly important for us due to our expanding number of sites managed via CASCADE. 
  • 1 point Thumb-up Thumb-down Favorite-off by bradley.wagner about 1 year ago Permalink

    We are debating removing Targets altogether in an effort to decouple templates from publish destinations and other output properties such as serialization type and extension. These will likely be relegated to the Page Configuration in the Page Configuration Set.

    • 0 points Thumb-up Thumb-down Favorite-off by natetanr 10 months ago Permalink
      For cascade users that have multiple domains but have common templates it would be great if we could decouple the templates from the publish destinations. This means we wouldn't need to duplicate our template just because they are being published to a different domain.
  • 1 point Thumb-up Thumb-down Favorite-off by srutland about 1 year ago Permalink
    This would be an invaluable change to the Cascade model.  Highly decentralized web environments would benefit from decoupling.  If this means that we could use a centralized template and CSS from which sites are provisioned, then publish this out without the requirement of a base folder, then that would overcome and simplify a major obstacle for us.  How soon can we get this?!  ;-)
  • 0 points Thumb-up Thumb-down Favorite-off by irifkin about 1 year ago Permalink
    This certainly sounds like a compelling idea, but I am wary of how a "site" will be defined. It needs to be flexible enough to allow for the various ways it can be interpreted.
  • 0 points Thumb-up Thumb-down Favorite-off by len.lanphar about 1 year ago Permalink

    I like the idea of defining "site" fairly abstractly. I tend to conceptualize a site as an entity that provides three main things: a hierarchy of assets that share the same URL prefix, a unit of scope for security/policy things like groups and roles, audits, publishing policies, etc. that can't/shouldn't be specified system-wide, and a unit of scope for things like asset factories/content types that should not be available everywhere within the system.  This at least avoids dictating what is done with sites template-wise and all that. Where it gets a bit murky though is when you introduce the concept of sites within sites. We're struggling with that right now.

  • 0 points Thumb-up Thumb-down Favorite-off by srutland about 1 year ago Permalink
    Vote it up!
    From a different perspective, our sites are loosely defined by the sub-domain URL associated with them.  Although many may share the same assets (for example a common template, CSS, and interface graphics), they are still considered unique or separate web sites. Sites can be defined uniquely as http://xyz.calpoly.edu/ or as  http://www.calpoly.edu/~xyz/.  Either could be a stand alone site, uniquely separate from the other.  Maybe our definition is the result of our granular approach to all sites with the enterprise web space.

    For this reason alone, having "sites" decoupled from a common target, yet being  made dependent on a centralized set of assests (without the requirement to publish the base folder) is extremely valuable to us.  I'm sure other's could benefit from this as well.  Let's vote it up!

  • 0 points Thumb-up Thumb-down Favorite-off by natetanr 3 months ago Permalink
    Is it possible to move content from one site to another? If not I think this is a needed feature. The migration and transition to sites is difficult. Not fully understanding the best way to do things. We may need to move several "Sites" into one "Site" but it looks like once assetts are placed in a "Site" they cant be moved out of the "Site" or into another "Site".

No attachments


* Note - To input code samples, click the pencil icon (this will remove the WYSIWYG) then be sure to start and end code sections with @@@ (three '@' signs).  For more information on textile markup, click here.  

Sign in

Follow us on Twitter

Current Category