Thanks for the encouragement! 
I'll dig into the docs for a moment:
http://community.southpawtech.com/docs/d...-concepts/
Quote: "In TACTIC, each sObject is represented as a table in the database."
That sounds weird. Isn't it that each sType corresponds to a table in the database and an sObject is represented as a row in the table specified by its sType? Just asking!
Quote: "sObject can be uniquely identified by two parameters: a search type and a search ID. Often these two parameters are combined into a "search key" defined as <search_type>|<search_id>"
I kind of figured that. I read you might combine databases and sync content between these. How does Tactic provide for unique search-ids for each search-type?
Quote: "Checkin/checkout is the framework for filesystem interaction. All interaction within the checkin/checkout framework is done through the SObjects themselves so that they can determine their own checkin/checkout conditions and mechanisms. The checkin framework creates a 'snapshot' SObject that is related to the original SObject through a search_id. It assigns a unique file ID for every transaction, and creates snapshot attributes for the SObjects."
Ok that's interesting. I suspect policies for naming files apply here. Will need to have a look how this representation on the filesystem works but it should be powerful. From what I understand TACTIC uses the filesystem as a storage for files and not as a bidirectional interface. Correct?
Some time ago I thought about maybe one could use git as a natural CMS backend. Might be too complicated. Anybody tried something like that based on tactic?
Quote: "Engineering requirements for a particular application must be gathered and translated into widgets, including definitions of the widgets' relationships to each other.:
I see. My understanding is that commercial Tactic provides prebuilt stuff to use for various domains of requirements. Is there some example that one might study as a blueprint of how to do that. Are there building blocks in the free version to be considered?
Quote: "Directories and file naming are handled slightly differently. TACTIC builds file names procedurally and then stores them in the database. On the other hand, TACTIC never stores directory names directly in the database, but always builds them up procedurally. This additional level of abstraction provides the opportunity to reorganize your asset structure as needed"
Not hard coding the directory structure is an interesting take. Makes me think about directory structures based on e.g. tags or keywords. There will be the time when you want to reorganise your tagging scheme. If you do you might have the filesystem structure adapt to the new structure. Well, that definitely is a topic for a later date.
Quote: "This is a service within TACTIC that enables specified folders to be “watched”. Any file dropped into a registered folder will be checked in.
Currently the implementation will create an entry per file. Subsequent drops of a file with the same name will be checked in as a new version. It is designed for high volume ingestions."
I like that a lot!
Enough for now. Need to get some sleep...
Ok, one some questions keep buzzing, so I should get it out before going to sleep...
Considering my simplistic BlogPost Example from above. My idea was to have several metadata fields defined like blogidea, blogtitle, blogoutline, etc. I also wanted to provide some image as a header. That would be a file associated with the sObject obviously.
Now consider the BlogPost should contain more images, maybe for illustration purposes or the like. Is there some concept to define additional slots where other files should be placed. Those slots might be present, to be filled later on, eg. when a certain step in some workflow has been reached.
Is this
A) a common idea implemented in the framework or
B) less common but has been implemented by someone or
C) uncommon and should be avided as a not-tactic-like pattern better solved with <insert-favorite-suggestion> here
D) cool but has never been tried?
BR
I'll dig into the docs for a moment:
http://community.southpawtech.com/docs/d...-concepts/
Quote: "In TACTIC, each sObject is represented as a table in the database."
That sounds weird. Isn't it that each sType corresponds to a table in the database and an sObject is represented as a row in the table specified by its sType? Just asking!
Quote: "sObject can be uniquely identified by two parameters: a search type and a search ID. Often these two parameters are combined into a "search key" defined as <search_type>|<search_id>"
I kind of figured that. I read you might combine databases and sync content between these. How does Tactic provide for unique search-ids for each search-type?
Quote: "Checkin/checkout is the framework for filesystem interaction. All interaction within the checkin/checkout framework is done through the SObjects themselves so that they can determine their own checkin/checkout conditions and mechanisms. The checkin framework creates a 'snapshot' SObject that is related to the original SObject through a search_id. It assigns a unique file ID for every transaction, and creates snapshot attributes for the SObjects."
Ok that's interesting. I suspect policies for naming files apply here. Will need to have a look how this representation on the filesystem works but it should be powerful. From what I understand TACTIC uses the filesystem as a storage for files and not as a bidirectional interface. Correct?
Some time ago I thought about maybe one could use git as a natural CMS backend. Might be too complicated. Anybody tried something like that based on tactic?
Quote: "Engineering requirements for a particular application must be gathered and translated into widgets, including definitions of the widgets' relationships to each other.:
I see. My understanding is that commercial Tactic provides prebuilt stuff to use for various domains of requirements. Is there some example that one might study as a blueprint of how to do that. Are there building blocks in the free version to be considered?
Quote: "Directories and file naming are handled slightly differently. TACTIC builds file names procedurally and then stores them in the database. On the other hand, TACTIC never stores directory names directly in the database, but always builds them up procedurally. This additional level of abstraction provides the opportunity to reorganize your asset structure as needed"
Not hard coding the directory structure is an interesting take. Makes me think about directory structures based on e.g. tags or keywords. There will be the time when you want to reorganise your tagging scheme. If you do you might have the filesystem structure adapt to the new structure. Well, that definitely is a topic for a later date.
Quote: "This is a service within TACTIC that enables specified folders to be “watched”. Any file dropped into a registered folder will be checked in.
Currently the implementation will create an entry per file. Subsequent drops of a file with the same name will be checked in as a new version. It is designed for high volume ingestions."
I like that a lot!
Enough for now. Need to get some sleep...
Ok, one some questions keep buzzing, so I should get it out before going to sleep...
Considering my simplistic BlogPost Example from above. My idea was to have several metadata fields defined like blogidea, blogtitle, blogoutline, etc. I also wanted to provide some image as a header. That would be a file associated with the sObject obviously.
Now consider the BlogPost should contain more images, maybe for illustration purposes or the like. Is there some concept to define additional slots where other files should be placed. Those slots might be present, to be filled later on, eg. when a certain step in some workflow has been reached.
Is this
A) a common idea implemented in the framework or
B) less common but has been implemented by someone or
C) uncommon and should be avided as a not-tactic-like pattern better solved with <insert-favorite-suggestion> here
D) cool but has never been tried?
BR