This project is read-only.

Suggestion: slam.config attribute for ActivationStatus

Apr 7, 2009 at 6:15 PM
I would like to suggest to introduce on
a) Configuration Level
b) List/ContentType Level
c) and Field level
an optional attribute "ActStat" with following values and meaning:
"active" (default) = node is active and will be slammed
"stop" = node is temporarily inactive and will not be slammed till active again
"replaced" = node got (temporarily) replaced by another node (setting the node to active again without inactivation/deletion of the replacing one causes double entries). No slam !
"expired" = node will never be activated again, but still kept on the config for historical reasons. No slam!
"template" = node can be used as a template for "active" nodes. No slam !

Having this attribute would increase our flexibility to switch tables and fields on/off on the fly in a well documented manner. (Of course we could do the same with comments and other tricks - however we feel comments should remain what they are used for and should not be missused, whereas all other forms for exclusion migth fail in future SLAM! versions and last but not least will never properly be handled by an XSD file).

Would be happe if we could have this in version 1.2 already
kind regards
René
Developer
Apr 7, 2009 at 7:07 PM
I think this would be useful but we have not included such a mechanism in 1.2, which will be released later today.  As to your status suggestions, I understand active, stop and expired but would like some clarification on "replaced" and "template".  For replaced I am wondering how to designate what is replacing what?  And for template do you have an example?  In any case, you should add this add a work item under Issue Tracker.  This goes for other suggestions as well, they will be easier to track as work items.

Thanks,
-Brian
Apr 8, 2009 at 8:44 AM
Hi Brian,
Just for keeping things together I will continue on this topic here and will switch to the Issue Tracker on my next suggestions:

Concerning the "replaced" attribute
I see the following scenario:
I have a list entry 
<List Name="ListCurrent" ActivationOrder="1">
  ...CurrentContent...
<List/>

What I want to do is to change the List's fields without loosing the original one. So what I want is to have something like this: 

<List Name="ListCurrent" ActivationOrder="1" ActStat="replaced">
  ...CurrentContent...
<List/>
<List Name="ListCurrent" ActivationOrder="1">
  ...New Content...
<List/>
So only the list with the New content is slammed.
The info about which item is replaced by which other item is when names are equal.
From a SLAM! perspective it is easy: Just ignore Lists with "replaced" status - that's all
Of course, from a mere SLAM! perspective a similar effect could be achieved when we would just use the "inactive" attribute. But from a user's perspective an "inactive" and a "replaced" list are not the same.


2. "template" Attribute
Again - from a mere SLAM! perspective there is nothing else to do than to ignore them!
For slam configurators a "template" attribute provides a way to tell other configurators about best practices on writing XML entries for lists and fields. In my opinion having those instructions as some kind of embedded example code  INSIDE the slam.config does much a better job than describing those examples in separate documents.

Hope this is mroe clear now.

It can be that those things are just personal "nice to haves". So I would understand if they are not implemented.
But what I would really like to suggest is, that
1. everybody could extend his slam.config with additional attributes that, when not know to SLAM! should simply be ignored.
2. we urgently need a mechanism where we can "inactivate" certain parts of the slam.config as currently we spend a lot of time with pyhsical deletion and re-insertion of temporary lists.

Developer
Apr 8, 2009 at 4:19 PM
Thanks for clearing up these statuses.  As for your last points:
1. Everyone can add attributes now if they are to be ignored anyhow.  If you add extra type and field attributes they will definitely be ignored unless you write custom code to access them.
2. It may not be too difficult to allow to deactivation of elements.  We will look into it, or you can for that matter if you are willing.  The changes necessary would exclusively be in the Core project under Configuration in XmlSqlDataMapping.  Just add conditions to ignore elements with an ActivationStatus set as you suggest.

Thanks,
-Brian