cancel
Showing results for 
Search instead for 
Did you mean: 
resplin
Elite Collaborator
Elite Collaborator

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com



Community Contribution IdeasDesign DiscussionsContent Modeling
This page contains work-in-progress for a new content type to hold a URL-linked file. Feel free to join the discussion and add your wishes, suggestions, and criticism.

Note: So far, the content of this page has been written by community members and may therefore contain mistakes or misconceptions.


Goals


Alfresco currently provides content types to hold documents but does not
offer a feature-rich content type to represent external documents, such as
PDF-files referenced via a URL.

Such a type should in its most basic form hold the URL path. Several
additional features and properties may be present if needed and
applicable.


  1. Availability check: Check whether the referenced resource is available. For URLs with the URI scheme 'http:', for instance, it can [always?]  be   checked whether the resource is available. If not (case of a 404, etc.),     some customizable action can be executed.
  2. Periodical availability checks: Perform 1. at regular intervals.
  3. Maintain a local copy of the resource described by the URL.   For files (like ;http://example.com/file.pdf') a copy of it is     cached. For the URL 'http://www.google.com' the HTML page would be kept     (not including images and other files referenced therein).     Initially, only the URI scheme 'http:' will be supported; some schemes     might not allow this sort of caching (like 'mailto:') and for others,     support might be added later (like RealPlayer streams).
  4. Change check: Check whether the resource at the URL changed.     For files (like 'http://example.com/file.pdf') this should amount to     checking whether the external file changed.    If a change is observed, some customizable action can be executed.
  5. Periodical change check: Perform 4. at regular intervals.

Proposed implementation



2.1. The content type URL

 The content type, called 'URL', inherits from cm:content and carries an
additional property called 'url' (of type string) that holds the
URL. Initially, the inherited property 'content' is null, so any attempt to
access the content will result in a warning about there being no content.

Only feature (1.1) (Availability check) is implemented for this most basic
form of URLs. [(1.1) might require additional properties to keep track of
which action to perform?]  All additional features are implemented via
aspects and aspect behaviours.  In the Web Client there is an action 'Check
availability' for feature (1.1).

[Relation to Links Management?]


2.2  Aspects

 The following aspects can be applied to an instance of content type URL:
[Please revise the names of the aspects; any better-sounding names?]

1. 'periodically-checkable', implementing feature (1.2).

    Property 'interval; [in minutes, or whatever -- does Alfresco have
    something like this?] and a repeatedly executed check with a customizable
    action as the behaviour.  [What is the mechanism in Alfresco to attach
    customizable actions?]  [Should we add date of last check as a property?]

    [Should we do this via http://wiki.alfresco.com/wiki/Scheduled_Actions?]

2. 'cachable', implementing feature (1.3).

    No properties, but behaviour sets the 'content' property (inherited by
    cm:content) to the resource at the URL at creation and update time.

    [Or should we implement URL as a subclass of sys:base and give aspect
    'cachable' a property 'content'?]

3. 'monitorable', implementing features (1.4) and (1.5).

    Property 'interval' and a repeatedly executed update check with a
    customizable action as the behaviour.

    In order to implement this, it would probably be easiest to always
    enforce aspect 'cachable' whenever 'monitorable' is applied [can this be
    done in Alfresco?].  In this way, a 'change check' amounts to comparing
    the resource to the currently cached copy. Otherwise, we would have to
    ressort to a solution in which only a hash of the resource is stored, as
    an aspect property. (Then, however, we might miss some changes in case
    the new, updated resource happens to have the same hash as the previous
    one.)

  We should provide a default action for aspect 'monitorable' that, when
  exectuted due to a successful change check, updates the cached version (in
  case aspect 'cachable' is present).