@@ -52,9 +52,9 @@ </document>
The only thing that seems potentially wrong to me in the code above is the nested "dir" tags related to the "Logistic Regression" menu entry. It seems to me that it would more naturally lend itself to a <content type="entry"/> tag, but it doesn't really have an action script to go with it.
-[
TF: Actually, there's not one big description.xml defining the entire menu-structure, but rather lots of small description.xml-files, each in their own subdirectory (see below), and each defining only a single menu-entry. So actually, the examples I gave are full examples of description.xml-files. They just don't get any larger than that. I'm not quite sure, how to explain this concept. Maybe you could have a look at the actions.zip-file in CVS. But maybe things get clearer below. Note of course, that all this is up for discussion.]
+{
TF: Actually, there's not one big description.xml defining the entire menu-structure, but rather lots of small description.xml-files, each in their own subdirectory (see below), and each defining only a single menu-entry. So actually, the examples I gave are full examples of description.xml-files. They just don't get any larger than that. I'm not quite sure, how to explain this concept. Maybe you could have a look at the actions.zip-file in CVS. But maybe things get clearer below. Note of course, that all this is up for discussion.}
The other thing I'm really unclear about is what is the nature of the file directory structure that goes with this. Let's assume that obveRsive lives in /usr/local/obversive (or on a windows box in C:\Program Files\obversive). Would the implied directory structure then be:
/usr/local/obversive (C:\Program Files\obversive)
@@ -79,18 +79,18 @@ I understand that this results in complete chaos, so we may require all actions to live in a single directory (say /usr/local/obversive/actions) with the possibility of action authors creating sub-directories under this main actions directory.
If the structure is more along the lines of my first two examples, then the question I have is how is the needed directory structure created? Does an action author need to explicitly create the needed directory structure, or is it created automatically by obveRsive?}
-[
TF: The second example is correct. An each of these subdirectories would have a description.xml-file. For
+{
TF: The second example is correct. An each of these subdirectories would have a description.xml-file. For
/usr/local/obversive/Regression/Logistic
that would contain
<content type="dir"/>
while for
/usr/local/obversive/Regression/Logistic/Probit
it would contain
<content type="entry"/>
-The directory-structure would be explicitely created by the ActionAuthor (that is until some time in the future, we have a super-cool graphical action-editor...). For now all actions have to be placed in the same directory-__structure__ (but __not__ in the same directory). That directory structure may be rooted anywhere you like, however (that is already configurable in current CVS). Note, that my idea would be prospectively, that you may duplicate the branches of interest of this directory structure in your home-directory and place additional actions there. Those would then be integrated with the "default"/distributed action-hierarchy. The advantage would be, that you don't need write access to the common directory-tree.]
+The directory-structure would be explicitely created by the ActionAuthor (that is until some time in the future, we have a super-cool graphical action-editor...). For now all actions have to be placed in the same directory-__structure__ (but __not__ in the same directory). That directory structure may be rooted anywhere you like, however (that is already configurable in current CVS). Note, that my idea would be prospectively, that you may duplicate the branches of interest of this directory structure in your home-directory and place additional actions there. Those would then be integrated with the "default"/distributed action-hierarchy. The advantage would be, that you don't need write access to the common directory-tree.}
!!! B) Defining the Action
So now you have a new Action placed in the obversive menu-structure. Next you'll have to define the action in the file you specified in description.xml. Below is the code of the "Test Action" with explanations in between:
@@ -110,14 +110,14 @@ <code filename="some.file"/>
{DP: So what is the relationship between "some.file", and the file given in the <action filename=""/> tag? Is "some.file" the *.action file or the *.tpt file?}
-[
TF: some.file is the *.tpt-file. Note that the <code>-tag is optional. By default code.tpt will be used. Actually, my reason for introducting the <code>-tag is, that I plan to make it ""possible"" to inline the code in the .action-file. (Something like
+{
TF: some.file is the *.tpt-file. Note that the <code>-tag is optional. By default code.tpt will be used. Actually, my reason for introducting the <code>-tag is, that I plan to make it ""possible"" to inline the code in the .action-file. (Something like
<code><!---
print ("This is pure R-code")
-->
</code>
-). Further, the reason the code-filename is not given in description.xml, but rather in the .action-file, is that I'm trying to reduce memory-usage of actions to a minimum. While not activated (i.e. shown), an action is basically just a single string storing the filename of the .action-file. Only once the action is chosen from the menu, all the further information is parsed and the GUI is created. As soon as you close the dialog, everything except for the string storing the filename is freed again.]
+). Further, the reason the code-filename is not given in description.xml, but rather in the .action-file, is that I'm trying to reduce memory-usage of actions to a minimum. While not activated (i.e. shown), an action is basically just a single string storing the filename of the .action-file. Only once the action is chosen from the menu, all the further information is parsed and the GUI is created. As soon as you close the dialog, everything except for the string storing the filename is freed again.}
By default, the code-template (see below) used will be "code.tpt" in the directory, the action is located. You override this by specifying a different file, here.
<dialog>
@@ -137,11 +137,11 @@ The "varselector"-tag defines a list from which you can select available objects. Besides a label, this element requires an attribute "id", which should be a unique string, by which the varselector can be referenced at other places. Currently no further attributes are supported.
{DP: an earlier data.frame selector will need to be created. I've written code that allows up to query the .R file associated with a particular project for objects of a give type (e.g., it provides a list of only data.frames).}
-[
TF: You're right of course. My idea on how to do that, would be to continue using the <varselector>-tag, but to introduce an additional "filter"-tag like e.g.:
+{
TF: You're right of course. My idea on how to do that, would be to continue using the <varselector>-tag, but to introduce an additional "filter"-tag like e.g.:
<varselector id="frames" label="select table(s)" filter="frames"/>
-That varselector would then only show data.frames. It should also be possible to say, excluded "string"-variables from the varselector, or even to exclude variables, that are not marked as at least ordinal scale level. I'm not entirely sure, how the syntax should be for that, yet.]
+That varselector would then only show data.frames. It should also be possible to say, excluded "string"-variables from the varselector, or even to exclude variables, that are not marked as at least ordinal scale level. I'm not entirely sure, how the syntax should be for that, yet.}
<column>
This is another layouting-element. All direct children of a "column"-tag will be place vertically from top to bottom. Similarily a "row"-tag would arrange its children from left to right (which is the default outside of columns). Using nested "row"- and "column"-tags, you have a good deal of control over the looks of the GUI.
