Attaching workspace to article
-
At this moment the bindings between articles and workspaces are done automatically, and are not yet configurable. In the future we plan to make this part more flexible to allow e.g. connecting multiple workspaces to article, or multiple articles to a single workspace.
"the bindings between articles and workspaces are done automatically" Well, then there seems to be a bug in this process, because I have an article which describes the code in a workspace, and they have not become connected. The workspace is here: https://workspaces.codeproject.com/ravenspoint/simple-dxf-readerviewer-with-spline-support[^] The article is here: Simple DXF Reader/Viewer with Spline Support[^] Do I have to do something special to register this bug?
-
"the bindings between articles and workspaces are done automatically" Well, then there seems to be a bug in this process, because I have an article which describes the code in a workspace, and they have not become connected. The workspace is here: https://workspaces.codeproject.com/ravenspoint/simple-dxf-readerviewer-with-spline-support[^] The article is here: Simple DXF Reader/Viewer with Spline Support[^] Do I have to do something special to register this bug?
-
" if you manually make a fork of an article, you cannot bind it with any articles" Actually, you did NOT say that. You said: "the bindings between articles and workspaces are done automatically" Please explain the correct procedure so that I can bind my workspace to my article. Is the problem something to do with the fork? Should I start a new workspace?
-
" if you manually make a fork of an article, you cannot bind it with any articles" Actually, you did NOT say that. You said: "the bindings between articles and workspaces are done automatically" Please explain the correct procedure so that I can bind my workspace to my article. Is the problem something to do with the fork? Should I start a new workspace?
Current behavior of the system is very simple: each time an article is created, workspace is created for it as well, and they are bound together. I.e. writes to workspace should be reflected on article page and vice versa. That's it. Any other workspaces, whose creation was not triggered by creation of an article, will remain not attached to any article.
-
Current behavior of the system is very simple: each time an article is created, workspace is created for it as well, and they are bound together. I.e. writes to workspace should be reflected on article page and vice versa. That's it. Any other workspaces, whose creation was not triggered by creation of an article, will remain not attached to any article.
I think I am beginning to understand! The only way to create an article/workspace pair that are connected together is to create the article FIRST. An empty workspace will be created, paired with the new article. Later on, I can add code to the workspace. Is this correct? Have I finally understood this? Comment: This seems backwards to me. Surely the natural way of proceeding would be to write the code first. Once the code is working and tested, then a person might think to write an article describing it. I cannot really imagine a situation where I would write an article before writing the code. The article might, I suppose, be a requirements document and a test plan, but that would be about all - not very interesting. And, of course, the enormous resource available of existing workspaces becaomse significantly less useful if we cannot fork them. Finally: I think you need to document this behavior somewhere prominent, since it is so counter-intuitive
-
I think I am beginning to understand! The only way to create an article/workspace pair that are connected together is to create the article FIRST. An empty workspace will be created, paired with the new article. Later on, I can add code to the workspace. Is this correct? Have I finally understood this? Comment: This seems backwards to me. Surely the natural way of proceeding would be to write the code first. Once the code is working and tested, then a person might think to write an article describing it. I cannot really imagine a situation where I would write an article before writing the code. The article might, I suppose, be a requirements document and a test plan, but that would be about all - not very interesting. And, of course, the enormous resource available of existing workspaces becaomse significantly less useful if we cannot fork them. Finally: I think you need to document this behavior somewhere prominent, since it is so counter-intuitive
Yes, you understood it correctly. Yes, there is a room for improvement ;)
-
Yes, you understood it correctly. Yes, there is a room for improvement ;)
OK, I tried doing it your way. I have created a new article: http://www.codeproject.com/script/Articles/ArticleVersion.aspx?waid=129995&aid=787134[^] Where is the workspace?
-
OK, I tried doing it your way. I have created a new article: http://www.codeproject.com/script/Articles/ArticleVersion.aspx?waid=129995&aid=787134[^] Where is the workspace?
I see that the workspace was not created yet, probably due to the fact that article is still in its draft state. Since Chris is covering the article part of our ecosystem, I'll check with him to see in which moment the workspace is currently created. Most likely we'll adjust the software to create workspace earlier.
-
I see that the workspace was not created yet, probably due to the fact that article is still in its draft state. Since Chris is covering the article part of our ecosystem, I'll check with him to see in which moment the workspace is currently created. Most likely we'll adjust the software to create workspace earlier.
I would appreciate it if you could add the following two use-cases to your design document. 1. A coder creates a workspace ( currently supported ); adds some code to it ( currently supported ); writes an article about the code ( NOT SUPPORTED! ) 2. A coder forks an existing workspace ( currently supported ); adds some code to it ( currently supported ); writes an article about the changed code ( NOT SUPPORTED! ) I would also be curious as to what use-cases you do support. The above two seem to me to be the most obvious from where I sit. You seem to have just the following 3. An old article exists with some code in a zip; a workspace is automagically created containing the zipped code and linked to the existing article; the coder can check in changes to the workspace This ( uses-case #3 ) is a very nice feature, but not the first I would have implemented myself. Surely everybody is most interested in creating new content rather than fiddling around with old articles. Or is that just me?
-
I would appreciate it if you could add the following two use-cases to your design document. 1. A coder creates a workspace ( currently supported ); adds some code to it ( currently supported ); writes an article about the code ( NOT SUPPORTED! ) 2. A coder forks an existing workspace ( currently supported ); adds some code to it ( currently supported ); writes an article about the changed code ( NOT SUPPORTED! ) I would also be curious as to what use-cases you do support. The above two seem to me to be the most obvious from where I sit. You seem to have just the following 3. An old article exists with some code in a zip; a workspace is automagically created containing the zipped code and linked to the existing article; the coder can check in changes to the workspace This ( uses-case #3 ) is a very nice feature, but not the first I would have implemented myself. Surely everybody is most interested in creating new content rather than fiddling around with old articles. Or is that just me?
Thanks for outlining the use cases. Indeed, the items which we have on our todo lists are covering them. The properly understand the reason why the current system works like it does requires to realize that we are actually extending decade-old article engine with the new features, namely workspaces. We had done first step - created workspace for each existing article, which in turn resulted in a workspace for each new article as well. Further steps, to make this more flexible, are in planning stages.
-
Thanks for outlining the use cases. Indeed, the items which we have on our todo lists are covering them. The properly understand the reason why the current system works like it does requires to realize that we are actually extending decade-old article engine with the new features, namely workspaces. We had done first step - created workspace for each existing article, which in turn resulted in a workspace for each new article as well. Further steps, to make this more flexible, are in planning stages.
It is sometimes better to do the planning before taking the first step.