I presume you mean you have inherited from cm:content not cm
bject and it's the former that has the 'content' property. In this scenario the 'content' property won't be undefined it will be available but set to null. Any attempt to access the content will result in a warning about there being no content. I think this will be OK.
- Yes, I meant cm:content (and have fixed this on the article page). Hbf
You may be able to use the notion of policies to check for the availability, it will really depend on what you want to happen if the resource becomes unavailable.
- I will take a look at this and get back to this point later. Hbf
Adding the other features as aspects is the way to go.
- Okay! Hbf
urlCheckable - You are right with the scheduled actions, this is the best way to implement a 'job' in Alfresco. Have a look in scheduled-jobs-context.xml for examples of built-in jobs. It's fairly easy to run a query to get all the objects with a certain aspect within the job and process them. Yes, having a last check date may be useful for this. Also being Spring configured this would make it easy to provide a custom implementation if desired.
- Aha, you suggest to implement the ability to customize by making the handler Spring-configured. Another approach would be to do the customization at a later stage: We run the query to get all object with the aspect and process them. If one node instance fails the check, we run an configurable action. This makes it easier for coders to customize the action (and still allows the whole task to be replaced by something else). Hbf
- Related to this: Is there a mechanism in Alfesco to provide custom actions? So the user could upload a JavaScript file to a specific subspace of the Data Dictionary space and then Alfresco automatically provides a pop-up to choose the action from? Or some mechanism to abstract tasks from the programming language (so that the coder could give one in JavaScript or Java or ... but I as the coder of the URL type do not have to care about it)? Hbf
urlCachable - I think your first suggested approach is the best. The reason for this is that if you inherit from sys:base then the nodes will not show up in any of our clients as they are looking for subtypes of cm:content!!
- Okay. Hbf
urlMonitorable - Same as checkable, a 'job' could be defined for this. Yes, Alfresco does support the dependent aspects i.e. adding 'cachable' when 'monitorable' is added. As for checking whether the url content has changed, is there a reason why you couldn't use the last modified date of the resource?
- Thanks for the clarification. As to detecting URL content changes, we could use the 'last-modified' header. If it is given (and the URI scheme is 'http:'!), we should use it, good idea. But it seems that it need not be present, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29, so we might be forced to use a cached copy or a hash. Hbf
- Thanks a lot for your feedback. Very helpful to me. Hbf
- Just to back-up what Gav has said policies and bahviours are definatly the way to go to get the 'automatic' behaviour required. It may be worth taking a look at the Records Management AMP where we use similar techniques to deal with things happening in a sceduled way when certain aspects are applied.
- It may also be worth considering creating a base type of 'extenal content' and dropping URL off that. Some of the features you are describing (monitoring/caching/etc) will be specific only to external resources that can be resolved. Physical resources (eg: real documents stored in a wharehouse) may still have a 'path', but obviously can't be resolved and cached in the same way. Creating some sort of base for external content may help when extending this model to cover other types of external content later.
- With the above comment in mind it may be worth considering collapsing the various aspects into one? .. I'm not sure about this but it might be worth a quick think about whether all 3 aspects are all really required .. it usually helps to think about what behaviour you want to attach to which aspects .. this should justify your decision
URL behaviour in properties
Suppose I have an aspect 'visitable' which adds as a property a URL leading to the node's website. (For instance, my node could represent an organization and therefore I add the aspect 'visitable', specifying therein the URL to the organization's website.) I want this website URL to be checked for availability from time to time.
How are we going to handle such a situation? We cannot 'add aspects to aspects' (add the 'urlCheckable' aspect to the 'visitable' aspect). So I see two ways out:
- The original node (the organization in my example) contains a 1-to-1 child-association to a node of type 'URL'. The latter will receive the aspect 'urlCheckable'. This is composition; in particular, if the organization node is deleted, so is the website-URL-node.
- We provide a new type org.alfresco.blabla.ManagedURL that provides the features checkable, etc.
It seems obvious to me that the first approach is the way to go. Do you agree?
The only question I have is about user-friendliness in the GUI. To the user, the 1-to-1 child-association should be hidden (he/she for sure does not want to be bothered with such an implementation detail -- it's composition and should be brought to the user in this way!). Does the current Alfresco Web Client GUI handle this? I guess not!
(My little toe tells me that this is a Alfresco-beginner's question; please excuse me, if this is the case!) Hbf
