It sounds like you need to set one property based on the value of another. You have several options for how to do this.
If you need the property to be set regardless of how the "toBePublished" property gets set (i.e., regardless of client, API, etc.), then the best bet is probably a behavior. A behavior is Java code that gets bound to your gs
ublishable aspect (you can use server-side JavaScript based behaviors but they are less common). When properties are updated, the behavior can check to see if the flag is true, and if it is, set the publish date.
Here is a tutorial on behaviors: http://ecmarchitect.com/images/articles/alfresco-behavior/behavior-article.pdf
Next, if you are using an action to set the toBePublished flag you can set the publish date property at that time. Actions are handy because they can be called from workflows, rules, from an API call, and from the user interface (either explorer or Share). Unlike the behavior, the integrity of your publish date field would only be guaranteed if the action is used consistently. If someone uses an API call to set the flag instead of your action, the date won't get set.
Here is a tutorial on actions: http://www.ecmarchitect.com/images/articles/alfresco-actions/actions-article.pdf
Actually, in my book, Alfresco Developer Guide, I show a custom UI action in Explorer called "Publish to Web" that may be doing something similar to what you are trying to do. It sets a flag and a publish date. My unpublish action sets the flag back to false. The source code for the book is freely-available here: http://code.google.com/p/alfresco-developer-guide/. I have ported this to a Share-based example, but haven't published that code yet. If you need it, let me know.
Finally, you could handle this completely through the client-side. If you are using Share as your UI, for example, you could write a custom control that would use client-side JavaScript to set the date field if the publish flag was changed. I don't have any good examples of this approach. It obviously has the drawback that if someone uses Explorer or an API call to change your flag, the date won't get set.
I suppose you could also use a form filter. Form filters intercept data before and after Share forms are rendered. So in your form filter you could look at the flag and then set the date. This has the same drawbacks as the client-side JavaScript approach.
I hope this has given you some options to consider and that you'll be able to determine which is best for your specific situation.
Jeff
If you need the property to be set regardless of how the "toBePublished" property gets set (i.e., regardless of client, API, etc.), then the best bet is probably a behavior. A behavior is Java code that gets bound to your gs
ublishable aspect (you can use server-side JavaScript based behaviors but they are less common). When properties are updated, the behavior can check to see if the flag is true, and if it is, set the publish date.Here is a tutorial on behaviors: http://ecmarchitect.com/images/articles/alfresco-behavior/behavior-article.pdf
Next, if you are using an action to set the toBePublished flag you can set the publish date property at that time. Actions are handy because they can be called from workflows, rules, from an API call, and from the user interface (either explorer or Share). Unlike the behavior, the integrity of your publish date field would only be guaranteed if the action is used consistently. If someone uses an API call to set the flag instead of your action, the date won't get set.
Here is a tutorial on actions: http://www.ecmarchitect.com/images/articles/alfresco-actions/actions-article.pdf
Actually, in my book, Alfresco Developer Guide, I show a custom UI action in Explorer called "Publish to Web" that may be doing something similar to what you are trying to do. It sets a flag and a publish date. My unpublish action sets the flag back to false. The source code for the book is freely-available here: http://code.google.com/p/alfresco-developer-guide/. I have ported this to a Share-based example, but haven't published that code yet. If you need it, let me know.
Finally, you could handle this completely through the client-side. If you are using Share as your UI, for example, you could write a custom control that would use client-side JavaScript to set the date field if the publish flag was changed. I don't have any good examples of this approach. It obviously has the drawback that if someone uses Explorer or an API call to change your flag, the date won't get set.
I suppose you could also use a form filter. Form filters intercept data before and after Share forms are rendered. So in your form filter you could look at the flag and then set the date. This has the same drawbacks as the client-side JavaScript approach.
I hope this has given you some options to consider and that you'll be able to determine which is best for your specific situation.
Jeff
